Dine Rite — a UX case study
What’s the problem?
In Salt Lake City, Utah, restaurants are not required to publish health inspection reports. Nicholas Rupp, a communications coordinator for the Salt Lake Health Department, said it is because the reports can be misleading.
They are not displayed on the windowsills or behind the counter. These reports can only be found online through the health department’s website.
The department is currently looking into implementing a system where a patron can use their smartphone to quickly view a restaurant’s latest inspection report. Rupp said “We prefer people looking at a full inspection report, so they can see for themselves what types of violations are there.”
Project goals
Salt Lake citizens should be able to conveniently access this data and know that where they are dining is considered safe or a hazard to their health.
Our goal as a team was to create a native iOS application allowing users to easily find inspection reports on local restaurants. We want to make them feel at ease about their dining experience and knowing they are making a safe choice for themselves and for their friends and family.
Design Process
My role and team:
- Research
- Persona
- User Story Map
- Wireframes
- Information Architecture
- Visual Design
- Prototyping
The team consisted of three UX designers, including myself, three iOS developers, and a project manager.
Research
Assumptions
We began our research with our assumptions on health reports and how we thought the public viewed those reports :
- There’s no such thing as a perfectly clean restaurant
- Restaurants are breaking health code violations that the public does not know about
- People actually care about health reports
- Users would want a way to review the restaurant
Surveys & Interviews
We prepared our survey and interview questions with these assumptions in mind. As a team, we wanted to focus on questions that gave us an idea on what people look for when going out to eat — specifically Salt Lake citizens.
Our online survey was posted to a Reddit page called ‘Salt Lake City’. This gave us the opportunity to see how local residents viewed the current health code policy. We asked questions such as:
- What do you look for in a restaurant?
- Do you look for health ratings before going to a restaurant? Why/why not?
- How likely do reviews/ratings influence where you eat?
- Do you trust official health food scores?
From our results, we learned that:
- Many residents look for the health code scores but can’t locate them
- People tend to trust the reviews made by others — whether by word of mouth or on social media
- Many said it was too inconvenient for them to find the scores and would only do so if the scores were located in Yelp or a similar app
Persona
What kind of person will use Dine Rite?
After gathering data from our in-person interviews and online survey we created our persona — Sadie Clark. Sadie embodied the traits of the targeted audience and helped us understand our users, their goals and their frustrations. Having this persona also aided the developers in knowing what problems we as a group were trying to solve.
Primary motivations of the user
- I want an efficient and accurate way to access official health code scores — I don’t want to search for the data.
- When I go out to a restaurant, I want validation that it is a safe and healthy place to eat.
User Story Map
Once the team had a better understanding of our persona, we created a user story map. The main goals of our user were:
- To stay safe
- Make a healthy decision of where to eat
- Help others make good decisions
From these three goals, we formed narratives and tasks the user would complete when using Dine Rite. During this process, we decided to incorporate API’s from Yelp and Google. Having those API’s would solve the issue of having to toggle back and forth between apps — giving our user the opportunity to not only search for a restaurant’s health inspection results, but to also read the restaurant reviews from Yelp and Google.
Our research showed us that the opinions of others largely influences a users decision on where to eat. Having the reviews would give the user further validation on if a certain restaurant is a safe and healthy option.
Planning
Ideate
Once we completed our user story map, we were able to easily form ideas on what we thought the application should look like and what it should offer to our user. As a team, we decided to have the user search for a restaurant via map view. Having this feature would give a sense of familiarity — since many other food related applications present information this way.
After searching for a restaurant and selecting the correct one, the user would be brought to a restaurant profile page. The profile page would give detailed information on recent food inspection results, along with customer reviews from Yelp/Google, hours of operation, address, and phone number.
Educate
We wanted our application to educate users on restaurant inspection reports. If we did not display detailed information explaining how the report was broken down, the user would be confused and would not be able to read the inspection reports correctly.
To solve this issue, we decided to have an about page on the app that provided the needed information about the inspection reports. This page would walk the user through a mock-up inspection result — explaining the differences between a critical and a non-critical violations.
Sketching
The design team took these ideas and began to sketch out wireframes. After sketching out our individual versions of each screen, we sat down and collaborated together on each page — making sure that we shared a common understanding of how the application would work. We discussed what layouts would work best to display our data and what inspection information we needed to include.
I focused on designing the search results page and the restaurant profile page. I knew that I wanted to include a map view with the search results, so the user could easily navigate and see more detail on the restaurant location. I thought the overall inspection score should be displayed on both pages — making it easier to view critical information without having to navigate through the inspection results page.
Mid-Fidelity
We collaborated as a team to create our mid-fidelity wireframes. The design team had daily meetings with the iOS developers to discuss the progress of each team member and making sure the developers were able to create the design features.
I continued to design the search results page and restaurant profile page — referring back to my original sketches.
Prototype
Once we decided on what layouts worked best for each screen and what information we needed to include, we started to develop a consistent visual theme.
We had to change a number of small features that were included on our mid-fidelity wireframes. We created features, such as button type and tab bar, based on material design and some visual design references. However, because we were working on a native iOS app with iOS developers, these material design features were not supported by the iOS guidelines.
Coming soon
We are currently awaiting release of our test flight version of Dine Rite. Once our developers turn the demo over to us, we will begin testing and further iterations of our app.
Thank you for taking the time to read my work and please check back soon! Feel free to connect with me on LinkedIn.
