WHISTLEBLOWER RETALIATION FORM EXPLORATION - 2018
CONTRIBUTIONS: INTERACTION DESIGN | UX DESIGN | INFORMATION ARCHITECTURE
PLATFORM: MOBILE
TIMELINE: 2 MONTHS
*I was one of three designers on this project. I worked with a Product Design Lead and a Senior UX Designer in addition to a team of business analysts, team of developers, and a product manager.
BACKGROUND
The Department of Health and Human Services’ Office of Inspector General (HHS OIG) has a hotline that allows users to file complaints for any fraud claims. The Digital Services team focused on digitizing the issue of whistleblower retaliation into a form to start.
*You can read more about whistleblower retaliation and report fraud here.
Our problem we were trying to solve was:
How might we implement the interaction design for a Whistleblower Retaliation Form?
DISCOVERY: WHAT PROBLEM WAS HHS OIG TRYING TO SOLVE?
During my Coding it Forward Fellowship with HHS OIG, the Digital Services team found that people experiencing report fraud had to call into a physical hotline to file a complaint. The process was time consuming for both groups: the people making the calls to make their fraud claims and the people manning the phone lines.
The process can be seen below:
Testing Assumptions and Defining Goals
We broke down what users’ goals and assumptions were for draft usability tests.
Users’ Goals:
An overview of the process
Expected results of submitting a complaint
Information required to submit
Assumptions
Users are unlikely to read paragraphs of text
Users are motivated to complete their task with the goal of seeking relief from whistleblower retaliation
Why an Electronic Form?
Electronic forms are:
Easy to fill out on a mobile phone
Able to collect large amounts of data in a short amount of time
Secure (especially important for whistleblowers!)
What were other alternatives? And why wouldn’t they work?
A separate micro application - this would require users to sign up for another application with a possible username and login feature that would have to be integrated. This could be more secure but would be less accessible for the public as they would have to log in to fill out the report. Plus, having a login and username to log back in would not make sense for a one time whistleblower, which was most often the case.
Phone report - as documented above, a lot of information would get lost in the back and forth conversations. We considered giving the hotline a script to follow but ultimately decided that this would still leave a lot of gaps in information.
Paper Forms - this would not only be inefficient on the whistleblower’s end but on the analyst’s end. Papers can get mishandled, information not properly filled out, and progress can be difficult to track due to the possibility of the loss of information.
RESEARCH: WHAT WERE OTHER FEDERAL AGENCIES DOING?
Now that we saw what HHS OIG was doing as a whole, we decided to a comparative audit analysis of other federal agencies including:
The United States Department of State (DoS)
The Consumer Financial Protection Bureau (CFPB)
The United States Department of Defense (DoD)
The United States Department of Labor (DoL)
How did we measure other agencies’ success?
We did a comparative audit of whether or not each agency contained features, contents, or fields that are listed on the U.S Web Design Standards.
Look at all that yummy data!
Which agencies measured up?
The CFPB had the cleanest experience with:
A beautiful UI - the interface is clean and modern as well as follows the U.S. Web Design System
Ease in usability
Checked yes for more categories than other agencies
Below is a comparison of the CFPB Complaint form and DoD’s Whistleblower Form.
What a difference!
IDEATION: WHAT COULD WE TRY?
With our findings from the comparative agency audit, the Digital Services team decided to focus on a form experience that was easy to understand and a simple form to fill out. For the sake of accessibility (users often came to the website through their phones), we focused on a mobile experience.
The Visual Identity - Working within a Design System
The visual identity of the form was taken from the U.S. Web Design System with slight changes to the header font (using Aleo as opposed to Merriweather for its sleeker, more readable look on digital platforms).
For the form experience, we focused on various UI components. Below are some of our explorations.
1. Toggle Switches
One of our first considerations was having a feature to switch between English and Spanish to include our Spanish speaking users. One idea we came up with was a toggle switch between the languages!
Why a Toggle Switch?
A toggle switch is a simple shifting of the thumb between languages. It is an easier option for mobile than a user trying to zoom in and click a link on a tab or within the space of the page (where on desktop one might be able to use a Google’s translate option if they are browsing in Google Chrome).
2. Context through Accordions
The accordion menu is a way to collapse information that only needs to be read in certain contexts and can be used as an empty state to start the form with. It functions similarly to a hamburger menu, whose purpose is to also symbolically show a site menu without taking too much room. If the information is laid out for each question, it would be an overwhelming block of text, which in our assumptions, we wrote that our users would not want to reach huge blocks of texts.
We included accordions to give context to each question a user is asked during their journey through the form. They access the information if and when they need it.
We also considered placing this information at the beginning of the form as a disclaimer. However, this also runs into the issue of being a block of text users would not read when they are in a hurry to complete the form.
3. Progressive Disclosure
A user should only have to answer questions that are relevant to them. For this reason, we made the form responsive to user inputs and hid questions they didn't have to answer.
Why use Progressive Disclosure?
During our inquiries about the hotline we found that users tended to get frustrated when asked questions over the phone about who was reporting on their behalf when they had already stated that they were reporting on their own behalf. We ourselves asked why? Rather than having a user answer a redundant question, we proposed that they only see the information that was relevant to them. This reduces clutter within the form experience and cognitive overload for the user.
4. Form Validation
When a user incorrectly fills out a form field and hits the next button, the form validates their result in red with a reminder to fill out the field correctly. The red border only appears when the user hits enter so as not to disrupt their flow as they are filling out the form field.
Why have Form Validation versus No Validation?
Form validation provides feedback on missed fields or incorrect formatting. When filling out government forms on mobile, users tended to accidentally skip fields. The form validation gives users visual markers for what they might have missed.
5. No Next for Empty States
The next button appears when the user has selected an option whether it be on a checklist, multiple choice, or fill in the blank questions.
Why not give users an option to proceed? What was a better option?
This feature would ensure that users would fill out the form field before proceeding.
However, after a few tests, we found that users actually found it more valuable to be able to proceed and come back to a question later if they did not have the needed information on hand.
6. Getting Experimental
Below we thought it would be interesting to come up with a concept that would use toggle switches for the user to proceed to the next screen. We did not end up using this in the final prototype but it was worth experimenting with regardless!
PROTOTYPING: BUILDING A USER FLOW FOR WHISTLEBLOWER RETALIATION
After ideating different micro interactions, we began to build out our flow of the new form.
Below is the high fidelity prototype of the retaliation form.
EVALUATION: REFLECTION, FEEDBACK, AND FUTURE ITERATIONS
So what did we learn?
Experimentation, while not always successful, is important!
Familiarity can trump novelty. Sticking to industry standards for certain interactions can be better than coming up with the newest idea.
What improvements can still be made?
The option to “skip for now” and come back to a question later so as not to force the user to be stuck on the form question.
An assurance of confidentiality. Whistleblowing is risky so security is likely appreciated.
Reconsidering the micro interactions in context to Android. We mostly designed the form with iOS in mind.
BONUS*
I presented about this solution as well as a few other projects with my fellowship for HHS Demo Day! You can find the presentation here.