VA Sexual Harassment Reporting
The Challenge
Veterans Affairs(VA) is working to stop sexual harassment to help make the facilities and services safer for all. As part of these efforts, VA is exploring mobile applications as a resource to make it easier for veterans and visitors to safely report sexual harassment incidents at a VA facility.
This is an effort to prevent such incidents, improve accountability, track and address allegations, and comply with the congressional mandate.[1]
My Role
I collaborated with Chakakhon Lea, who serves at the Office of Veterans Experience and is also a fellow graduate student in the User-Centered Design program at Brandeis University.
- User Research
- Conduct Ideation Workshop
- UX Design Concept
- Prototypes
- Usability Testing
Duration: 10 weeks
Team Size: 2
The Approach
User Interviews
Ideation Workshop
Scenario Mapping
Sketching
Storyboarding
Paper Prototype
Annotated Wireframes
Userflow and Wireflow
High Fidelity Prototype
Low Fidelity Protoype
The Discovery
Where to Report?
A VA employee didn’t know where to report if she was sexually harassed. She didn’t know where the patient advocate offices are within the facility.
Reluctance to Report
A participant didn’t want to report unless she was assaulted like someone touched or grabbed a body part.
Reporting Preference
There was a mixed preference between reporting in person and reporting with a mobile or web-based form.
Mobile App
A participant preferred an app because it would allow her to report at her leisure when she’s ready and feels safe.
Proof of Filed Report
Participants wanted a copy of their report and the incident number.
Confirmation Call
Participants wanted a confirmation call from someone acknowledging it has been received and the case is in progress.
Retelling the Story
A participant mentioned she does not want to retell and relive her story again and again. So she would like proof of what she submitted so that she can submit it again if she needs to.
Have you or your friend ever been harassed at VA?
"I get catcalls all the time."
Defining the Design Problem
Based on our findings participants either preferred in-person reporting or mobile form reporting. So we formed a “How Might We” question to anchor the ideation session.
How might we help anyone report sexual harassment incidents that occurred at a VA facility?
-
In-person
-
Mobile based form
Ideation
Reason of use
I planned and facilitated the ideation workshop with my project partner to lay the foundation for design decisions and generate ideas.
Learning
- Thorough planning is essential for ensuring a smooth workshop experience.
- To maintain accuracy and efficiency, it is crucial to separate the roles of keeper, scheduler, moderator, questioner, and contributor. Attempting to juggle multiple roles by a single person significantly increases the likelihood of errors.
During this workshop, we made an Empathy Map and brainstormed ideas.
UX Design Concept
Scenario Map
To further ideate based on specific scenarios and consider the context of use, I decided to make a scenario map in which the user is sexually harassed at a VA facility and wants to report off-site with a mobile-based app when they felt safe and ready.
I took ownership to design the mobile app functionality that allowed the user to fill out a form when they felt safe and ready.
10x 10 Sketches
Reason of use
- To quickly visualize ideas for mobile screens.
- To share the sketches with peers for feedback.
Storyboards
Reason for use
To understand what the user would experience chronologically while using the application, I created 3 storyboards in which the user reports typing the incident description, recording the audio description, and recording the video.
Learning
- Z may not feel comfortable or safe capturing a picture of the harasser during the incident.
- The report should be emailed separately due to its potential length, while the incident number can be provided on the mobile screen along with the confirmation message.
In this scenario, persona Z
- is sexually harassed at a VA facility while heading to an appointment
- curses, and takes a picture of the harasser before moving on.
- heads back home after the appointment
- fills and submits the incident report
- receives a copy of the report and incident number
- receives a confirmation call
- tracks her case status
- receives a status update call
Prototype, Test, & Iteration
Paper Prototype
Reason of use
I utilized paper prototypes to rapidly test my ideas. It provided the flexibility to make the missing features and functionalities during the testing session.
Challenge
It was challenging to conduct the test remotely during the pandemic lockdowns.
- Questions of age and sex in the form were thought to be irrelevant in reporting context.
- A participant mentioned she would have liked to have the option to pick the method of contact.
- A participant wanted to see the incident description section next to where she mentioned the date and time of the incident rather than on a different mobile screen, later in the process.
- A participant was confused by the “X” button as it was not consistently placed on different screens. Similarly, the back button wasn’t present on all screens.
- A participant was confused about two text fields for description and couldn’t distinguish between harasser and incident description.
- A participant liked the audio recording feature and also liked being able to use both text and audio for description.
- A participant wasn’t sure if she could re-record the audio.
- A participant would have liked to see a review page before submitting her information.
- A participant wanted to see the timestamp of when the confirmation email was sent to her under the “Tracking Case Status” screen.
• Information architecture was reviewed and changed for the “Incident Description” section.
• Age and sex fields were removed.
• The option to pick the method of contact was added.
• The harasser and incident description was more clearly separated by using section headers.
• A review screen was added before submission.
• The “X” buttons and back buttons were placed consistently on all screens.
Low-Fidelity Prototype
Reason of use
I utilized low-fidelity prototypes to test user flows at a broad level, without being worried about functional details and UI.
- A participant was confused about what the next and back arrow buttons would do.
- After the submission participant expected to see when someone would contact her.
- A participant expected the system to ask for her incident number in the track case status screen before seeing the status.
- A participant was confused about why there were two text fields for description.
• Labels for the next and back arrow buttons were added.
• After submission, the timeframe was displayed on when the user would be contacted.
• To track the case, the participant was required to enter the incident number in case a user would have multiple incidents reported.
• Shaded backgrounds were added to the harasser’s description and incident description to clearly separate the sections.
Iteration
Reason of use
I made updates to conduct detailed testing of features and functions for “Report an Incident” and “Track Case Status” user flows.
- In the record audio screen, the participants while recording, expected to see the play, pause, and trash options along with the pause.
- A participant was happy to see the confirmation of the recording uploaded but wanted to see an “X” button to exit. The green check icon wasn’t intuitive for her to click to go to the next screen.
- In the “Time of Incident” field participant mentioned in an actual scenario, she might not have clear memory and would want to see an “Approximate Time” label instead.
- A participant was confused about what to enter in the “Location of the Incident” field.
- Both participants noticed the uploaded photo attached right away.
- Both participants mentioned they wouldn’t use the record a video option.
- A participant mentioned it would be good to know the time limit if there is one. She also mentioned the time limit would make her nervous and encourage her to rush.
- A participant mentioned if she wanted to re-record, she would like to have the option to record a new one or overwrite parts of the current one, before trashing it.
- A participant was surprised when she saw the “recording uploaded” message after selecting the next button. She expected it to take her back to the form.
- A participant thought it would be a nerve-wracking process to report a sexual harassment incident and she wouldn’t want surprises.
- “It would be a nerve-wracking process to report a sexual harassment incident and I wouldn’t want surprises while filling out the form.”
• The label for “Time of incident” changed to “Approximate Time of Incident
• The label for “Location of Incident” changed to “VA Facility Location”
• Play, pause, and trash buttons were added to the “Record Audio” screen.
Annotated Screens
Reason of use
I annotated the screens to enhance viewer understanding during my absence. I included clear explanations of elements, functionality, and purpose in the document.
Next Steps
- Conduct further prototype testing using various scenarios with a diverse group of users to evaluate the usefulness of features such as video recording.
- Ensure design consistency and predictability to minimize user surprises, considering their potential stress due to harassment incident.
Result
During the project, we introduced features and concepts that were previously unexplored by the extensive team of Design Consultants at VA. For instance, we incorporated a voice recording feature for reporting. By adopting a user-centered design approach, we empathized with the users and generated simple and intuitive design solutions.
