The Design to SLC Health Codes — Case Study

Informing residents on the cleanliness of restaurants

Published in

Kay Rawson

8 min readJul 26, 2018

Overview

Every restaurant has certain safety standards they must abide by in order to keep running. The government does routine inspections and then provides a restaurant with a grade. In most states the health code is required to be posted, but not in Salt Lake City. We decided to create a native IOS app that allows people to see the health code inspections of restaurants in an efficient way.

Meet the Team

The Designers
Nick Major // Bailey Le // Kaitlan Rawson

The Devs
Caston Boyd // Dallin McConnell // Landon McKell

My Role
UX Designer

Tools
Sketch, InVision, SurveyMonkey, DropBox, GoogleDocs

The Beginning

The beginning is the most important part of the work
-Plato

I chose this design process because I feel that the best place to start is through empathy. In order to design for our users, we need to empathize with them. The health department has a lot of content and being able to understand the frustrations and goals of the users would help us figure out how to manage all of the content.

We started by contacting Nick Rupp, the communications coordinator for the Salt Lake Health Department. While waiting to hear back from Nick, we made assumptions about our users which influenced our decisions about the app, such as restricting it to the Salt Lake City Area.

Research and Expert Interview
Nick got back to us quickly and was able to meet us in person for an interview. In the interview he provided some great insight to the inner workings of the entire process of restaurant inspections and their internal grading scale.

The biggest takeaway from the interview was that we were unable to use more conventional ways of displaying the information such as a letter grade or star rating, as it was said to be misleading. Instead, they like to show the number of violations that the restaurant has accumulated.

Critical violations are violations that pose an immediate risk to public health while non-critical violations are violations that if not corrected may lead to problems in an establishment over time.

User research showed that the actual labels critical and non-critical were confusing and threatening. The decision was made to change them to major and minor violations.

After our interview with Nick, we decided to conduct smaller interviews and an online survey. The survey results were very helpful and actually surprised us. We were surprised at the amount of people who said “no” to our first question posted below.

Persona
After we gathered our data, we created our persona, user story map, and user story flow. When we created Thomas he was someone who had a job that allowed him to eat out regularly, as most people from our research dined out multiple times a week (45.45% from survey alone). We also decided to have him move from a location where health codes were posted to a location where they were not readily available, as this represented those who knew that health codes were available to the public.

After we made our persona we went forward with creating our user story map and user story flow. This proved to be a lot easier than in my previous project. Our user flow was also pretty simple, as we all had pretty much the same idea of what type of information would be displayed and where.

The Middle

We then separated and did wireframes and low-fidelity mockups. The following were some of the wireframes I did.

There were a few aspects and ideas that we knew were important to us that we wanted to keep in mind throughout the design process which are listed below:

The major/minor violations should be shown as we can’t have a rating listed
The most important thing that needed to be displayed on the restaurant overview were the violations
Major violations are very important, and so they must stand out
The app must be informational only so our users can make determinations on their own
There should be an image of the restaurant as to break up the amount of text and to bring more personality

Iterations of the restaurant overview page

In the initial design we placed the major and minor violations next to each other, which provided us with some problems

It was difficult to choose colors that didn’t downplay the major violations
It was difficult to alert users that the violations were clickable
Attempted to put in a “>” sign to show violations were clickable, but those took up too much space and crowded the boxes

The solution was found through stacking the major and minor violations on top of each other. This provided visual hierarchy by displaying major violations above the minor violations while also allowing us to indicate that it linked to another page with more information.

A decision was made to switch to a dark theme because the color that was chosen to represent major violations contrasted better with the dark theme rather than the light theme. The dark theme was well-received.

We handed off the dark theme to the IOS developers with a sigh of relief that we had finally had a design that we felt met the goals of the user. As anyone else would know, it’s impossible to have a project be smooth sailing the entire way.

Our devs approached us with a problem regarding the graph that displayed the total amount of violations over time. The graph was very difficult and time consuming to create. We decided that the graph would not be a possibility or part of our MVP at this time, as it was not something that we felt our user really needed to see. However, our team is definitely hoping to have it as a feature we would implement in the future.

We went back to the drawing board and played around with layouts and what information we wanted to display on the page. We also received some great feedback regarding the way the major violations, minor violations and past inspections sections were displayed. With the current design the past inspections section was both the same style and color as the minor violations section. This gave both sections the same weight and made it seem like they were the same thing. This was fixed this by changing the style of the past inspections section by listing out the past inspections instead of having it be a section you can click into.

We received some great feedback from a mentor regarding the amount of content we had on our front page. The user was consuming so much information at one time and this could potentially lose them. This was also information that we felt was not the most important in terms of what users needed to see first. We decided to divide the content into several cards that can be swiped through, this way the user wasn’t getting overloaded and could discover more if they wanted.

There came some problems when displaying major violations in the double digits on top of a single digit number. We designed several iterations but decided the center-aligned was the best. This would be hard for the devs to implement but we eventually found a solution. We put the numbers within a box and center aligned them to that box.

We then sent the devs a new version of the app. Hopefully there wouldn’t be any more huge design problems. Right?

Oh how wrong we were!

A problem came up regarding the API that provides the description for the restaurant, and ultimately we were unable to get the descriptions. Our page now looked unbalanced and there were issues with the spacing between the cards and the restaurant information.

We designed some more iterations and decided to put the restaurant information on a card by itself and make the image much larger. But sometimes by fixing one problem, you create another.

With the image in the middle we felt that there was an abundance of white space on the sides which made it feel unbalanced, so we added in signifiers to allow scrolling through a gallery of images of the restaurant. But now we had to figure out where to place the buttons for favoriting a restaurant and reporting a restaurant and whether to leave them as icons or as buttons.