Understanding Our Users

User Research

When tackling a new design challenge for the first time, it’s always best to take stock of the existing ecosystem you’re entering - who are the key stakeholders? What are their needs? What internal/external factors are influencing their decision making and their desires?

Understanding this contextual information now will make a big difference in how clearly we will be able to define our user’s problems and allow us to avoid making mistakes (or leaving things out) early in the design process. There are lots of different ways to gather this information from your target users but given the specificity of this tool and the small size of the primary user group, I started off with individual interviews with key members of OHDOT staff that would be interacting with the finished product.

Roadway revenue mechanisms were something that was completely new to me at the time, so we spent a lot of effort clearly defining the problems that we were trying to solve and the best ways to present information that made sense to both experienced users (like the department heads) and inexperienced users (like new hires). 

Identifying User Pain Points

As part of our initial research efforts, I sat down with 5 members of OHDOT staff that would become our primary user group for the finished tool. This included the members of the finance department, subject matter experts, and department heads for the DOT. After the study, we were able to create a list of some of the main problems that our users are facing. The 3 main pain points we identified were as follows:

Complex Policies

Revenue collection happens differently for each different policy type. This made it uniquely difficult to compare plans across a single metric. To create a system that is easy to understand and use, we were tasked with imagining a way to view each policy in a standardized format so certain elements of the policy could be tweaked, and the differences in output could be clearly understood.

Diverse Demographics

the policies being simulated in our software were going to impact the entire state containing many different demographic, psychographic and socioeconomic groups. This presented us with the unique challenge of not only understanding how each group would be affected by specific policies but also presenting the impacts of each policy decision across each sector of the population.

No Historical Comparisons

In their current processes, users struggled to understand how new policies would augment their existing rate of collection. This was one of the main motivators for the creation of this revenue system and factored heavily into the presentation of information in the final dashboard design.

Creating User Personas

The original purpose of the revenue policy tool is to “simulate the effects of economic policies implemented by the DOT”. This sounds simple enough, however, the user groups we are supporting in this software extend beyond the people actually using the tool. This software will exist as a single step in a much longer process of attaining legal approval for the selected policies.

Our primary users will be interacting with the software to create their own custom revenue policies, but they will be sharing the policies with members of the state legislature as well as other members of the DOT. This distribution of information means that we must support the consumption & interpretation of the information by other groups outside of our primary users. 

Those other groups were labelled as “secondary users”, and personas were created for them as well to ensure that we considered their needs while designing the user experience and interface. There were 3 main perspectives among our primary and secondary users:

• Government/Fiscal: This viewpoint is representative of the heads of each department and the state-wide planners. They are interested in gaining a high-level understanding of whether a certain revenue policy will generate enough money for the department and sufficiently replace gas taxes.
• Transportation Department: This group consists of our primary users and is focused on how the policy will be put into action and the effect that it will have on the DOT. They are concerned with impacts that certain policies will have on resource allocation, collection methodologies, and if the department will be able to support them once implemented. 
• Taxpayers: While the individual taxpayer may not be a user of this software, there are legislators and lawmakers tasked with voting for the best interests of each taxpayer within their districts, so keeping information about the impacts of each policy on the general public (which demographics pay the most, for example) is an important piece of information that will support equitable decision making in the future. 

Each of our primary and secondary user groups shared one or more of these perspectives, and through creating those categories we were more easily able to tailor each interface to the specific use case. 

The example persona for our Transportation Department Finance Director - they represent the person who will be using the revenue mechanism tool the most, and training their subordinates on how to use it in the future

Ideation & Sketching

Now that I had a strong foundation of background information and a good understanding of the needs of our users, I was able to start my favorite part of the process: ideation. During this phase of the project, I like to take a “no idea is a bad idea” approach as I lead the rest of the design team through exercises like Crazy 8’s, creating “how might we” statements, and lightning demos to start coming up with solutions to our user’s pain points that we identified in the last step.

This step involved a lot of learning, since there are a lot of complexities built into the state-wide revenue mechanisms that we were trying to simplify for the tool. For example, answering questions like “how might we allow users to set incremental rate changes over a window of time?” was not such a simple task; it actually ended up sending me down a rabbit hole of policy jargon and led to the unique timeline-based input interface that we use in the final version of the tool!

Low-Fidelity Wireframes

Thanks to all the effort we put in defining the problems we were setting out to solve, empathizing with our user’s needs, and coming up with a lot of ideas during ideation, the low-fidelity wireframing process for this project was very smooth.

The main challenge during the wireframing process was defining some of the more complex user flows, mainly the flow for creating new Mileage Based Usage Fee (MBUF) policies. These policies are based on how much drivers use their cars, and the rates for these policies will be different for each person as their rate is set depending on the type of engine their car has (gas/electric/hybrid), the age of their vehicle, and their miles per gallon (mpg) rating. Because of this added complexity we couldn’t present MBUF policies the same way that we would present other simpler policies in the software.

To find a solution to this challenge, I hosted multiple information gathering sessions with ODOT team members to understand exactly what kinds of information we’d need to include for all MBUF policies, talk through logical flows, and design a custom wizard walkthrough for users to enter when designing a new MBUF policy in our software. (add examples of low-fi flows for MBUF here)

Policy Dashboard v.1

New Policy Selection v.1

High Fidelity Mockups

After conducting usability studies and interviews with the client, I implemented their feedback in the designs to alleviate the pain points we observed during testing. In response to the results of testing, I made the following changes:

• Redesigned the display for policies on the homepage, focusing on clarifying the existing rates, and reducing the visual clutter for new policies by creating collapsible cards for each new policy
• Created a custom view for all MBUF policies, breaking them out into their own page when viewed
• Organizing revenue mechanisms by policy type in the first step of the policy creation workflow

Before Testing

After Testing

Before Testing

After Testing

Before Testing

After Testing

These modifications to the design helped alleviate the pain points our users were experiencing during testing, and led to some additional improvements in efficiency. Here are some things we noticed after re-testing designs with our users after modification:

• Time-on-Task (ToT) was reduced by 25% for new policy creation from our low fidelity designs to our high-fidelity designs
• Observed a 1.2 point increase on average CSAT rating among tested participants in round 2 (results were measured on a scale from 1 to 10)