Data Visualization for Improving Health and Public Safety
Tools Used: Sketch, InVision, Paper and Pen
Skills Used: Research, Competitive Analysis, User Interviews, Usability Testing, Data Visualization, Prototyping, Wireframing, Client Management
Improving Efficiency and Effectiveness of Health Inspections
My design partner and I worked with Open Data Nation, a local start up and certified B Corp. Open Data Nation provides open data consulting services to city governments. We were asked to design a dashboard for health inspector managers to view and organize data from the FIVAR application.
Using Open Data Nation's existing user interviews, I completed research analysis, and developed user task flows and personas. Along with my design partner, I created sketches and wireframes, built a prototype in Invision, and completed rapid validation of designs with users.
A web application that helps health inspector managers prioritize work, evaluate performance, and predict health code violations.
The FIVAR Application prototype has been built by Open Data Nation for five cities and will be included in a GIS mapping software suite available to 100+ cities. I am currently working with Open Data Nation to apply similar technology to predict traffic accidents and prioritize interventions.
Predict and Prioritize
The FIVAR application uses open data such as 311 calls, Yelp data, and previous inspection reports to prioritize restaurant inspections based on the probability of finding a health code violation. Open Data Nation piloted the product in Montgomery County, Maryland, and the application found 27% more violations 3 days sooner for an estimated labor cost savings of $2 million.
Open Data Nation came to us with existing formative research including notes from 60 interviews. Because of the tight timeline of the project, I picked up where they left off. My design partner and I took their notes and completed an analysis to define the problem statement and user pain points.
When looking at user pain points and defining a problem, I like to look at the whole environment. I like to examine what is happening in activities, outputs, and outcomes.
1. At the activity level- What are people doing?
2. At the output level- What effect is this having?
3. At the outcome level- How does this effect the system as a whole?
Understanding the Context
In addition to analyzing the notes from formative interviews, I spoke to health inspectors, data visualization experts, and joined webinars for city officials using open data. I wanted to understand the context and get up to speed on the current trends in open data and data visualization.
A System-Wide challenge
Once we looked at pain points and their effect on the system, we were able to define the problem.
System and budget constraints result in less accurate, less effective inspections measured by quantity, not quality.
A 2- Way Design Solution
Designing the Solution
A user-centered solution needed to address all pain points within the system, including improving efficiencies in budgeting and staffing, increasing engagement of both managers and inspectors and improving consistency in employee evaluation. The solution needed to include a feedback loop between inspectors and managers.
Incorporating Business Requirements
The solution we identified based on our user-centered design analysis did not meet the current business requirements. The ongoing proposal required a one-way data dashboard for managers to view prioritized restaurants and inspector performance. Based on our user interviews, we anticipated future clients would ask for the features we identified, and we agreed with our client to start with a Minimum Viable Product that could be expanded and modified based on client needs.
Designing the MVP
My teammate and I were working closely together to sketch, ideate, and prototype the initial screens.
(Click the images below to expand.)
Rapid Validation with User Testing
After we built the MVP, we met with a health inspector manager at a local Department of Health and Human Services. We traveled to his office for a user interview and usability test. Many of our solutions fit his pain points, and he was impressed by the prototype. However, we completely missed the mark on designing for his work flow for scheduling inspection assignments. While we had designed the tool for managers to set schedules and push them to inspectors, his department let inspectors set their own schedules.
During our trip to the Department of Health and Human Services, I led a usability test. I quickly realized that testing in the field is challenging. It is important to consider things like access to wifi and your user's familiarity with the technology you are testing with before you arrive.
Designing A Scalable Solution
Based on our user interviews and research, my teammate felt strongly that the FIVAR dashboard needed to include two way communication between the manager and the inspectors. Because the algorithm needs to be tailored to a city specific to their open data resources, I saw an opportunity for the FIVAR dashboard to be scalable based on the client. We decided to produce the necessary designs to build a system that could be built for both a short-term solution and a long-term change management tool.
Making the Pitch
We presented our work to the client by starting with the MVP and then moving back to the initial problem statement and our view of the best possible design solution. We packaged all of the materials as a scalable product that could be flexible and change based on user needs.
Our final prototype was presented at DC Tech's Women in Tech Meetup. It was great seeing the full product presented on the big screen.
FIVAR has been developed internally for 5 cities and is soon to be offered in a suite of GIS software available to 100+ cities. I am currently working with Open Data Nation to expand the idea for private sector applications and to expand into adjacent spaces.
This project was an incredible learning experience for me. Not only did I learn more about restaurant inspections than I ever needed to know, but I was exposed to a whole new world of open data. I grew leaps and bounds in terms of personal and professional growth by working on such a challenging project.
Here's what I learned:
- Be Organized. I learned just how many documents you accumulate working on a client project. In order to work effectively, it is absolutely essential to have an established file structure and have intuitive naming conventions. It essential for effective and efficient handoff to have your Sketch files grouped and labeled meticulously and your wireframes annotated.
- Design with your developers in mind. We met with our client after our presentation, and she requested a handful of changes to the design with the justification, "it will be hard to code." As designers, it is easy to want to design elements that are graphic and beautiful. It is important to remember that your original design might not be worth the extra hours it will take for someone to build it.
- You will not always have user research. As a user experience designer, I want to start every project by talking to users. Frequently, timelines and constraints will prevent you from doing this. It is important to try your best to complete user research, but there is also a wealth of information to be found via outside sources and expert interviews.
- Your designs are not your own. Do not get attached. It is easy to become attached to something you've spent days designing, but it is important to put your work in front of others and allow them to be critical. If you can't strongly defend a design choice by explaining its utility, you need to let it go. Design is just as much about what you didn't include.
- When working with a difficult client, they are the head and you are the neck. When you've discovered a solution that is contradictory to your client's ask, you need to direct their attention and walk them through your findings. By presenting your process, research, and analysis and showing them the same information you used to come to a conclusion, you are more likely to turn their head in the direction the product needs to go.