Hopelink Transportation Case Study
With my team at Leapfrog Technology, we worked with Hopelink to automate their manual paper-based vehicle and driver inspection process to a mobile application.
Hopelink is a nonprofit, located in King and Snohomish counties, that provides services to low income families, children, seniors, and those with disabilities.
Role: UX Researcher
Location: Seattle, WA
Skills: User Research, interviews, process Improvement, wireframing
Research Method
We began with the Brown Paper Method, which is what my team used as our primary user research tool. Using this method helps surface an organization’s process inefficiencies and works with the clients’ key stakeholders to design an enhanced process.
The steps of the brown paper method are:
Conduct in-depth contextual inquiry interviews with each member of the team
Identity their actions, roles, documents, and other players they interact with
Identify their key pain points
Map gathered information into a current state documentation
The detailed current state workflow mapping each team member shows the full system end to end including responsibilities by role, supporting documentation, and pain points. This documentation is used as a map to begin iterating solutions.
Key Pain Points
Our method uncovered the following pain points that we hoped to directly address with our new designs.
-
Inspections recorded on paper and scanned into Salesforce
-
Redundant and outdated legacy data in Salesforce
-
Lack of organization in documents and file management including contracts and applications
-
Inability to be notified about overdue audits, failed inspections, or driver suspensions
-
Difficulty in visualizing issues such as infractions or failed audits
Design Sprints
I created a series of preliminary wireframes of the new system and created a prototype in Invision to use for testing. I drafted a basic usability test to see if the Partner Relations could complete the core functionality we uncovered during our Brown Paper exercise.
initial wireframe
Some feedback I received was:
-
Restructure page hierarchy to make content easier to digest for low vision and blind users
-
Stop users from leaving certain fields blank
-
Create notification system to alert team about overdue audits
After the first round of tests I implemented the feedback and updated the workflows. We repeated the testing process and went through a few rounds of iterations before everyone was comfortable locking down the designs.
Outcomes
Ultimately we built a Powerapps solution that enables Hopelink to manage Service Partners, drivers, and inspections. We enabled our client to utilize a new mobile-enabled platform that reduced their data-entry input hours as well as auditing hours by at least 5-10 hours per week.
Our successful engagement with this project led us to work on other large scale Powerapps and Dynamics solutions with Hopelink.
Takeaways
Always prioritize inclusive design from project beginning
Understanding the accessibility requirements for a project from the beginning makes the design process more innovative. Because we were solving for some users who had low vision, I was able to learn in real time how to make these features better for different users beyond the basic necessities of WCAG accessibility compliance. Moving forward, I was able to apply these accessible design ideas even when not explicitly required by the client. I learned the importance of always centering accessibility in a project because it makes a robust product overall.
