Lunch Hunt: A UX case study

Lunch hunt was created for the explorers. We wanted to make an app that would take people away from common and frequented restaurants. Here you can find all the local and hidden destinations that will create a more authentic experience through your taste buds.

Background

Lunch hunt was a project that I completed for school. I worked in a group of two UX designers, three iOS developers, and three QA engineers. We had 5 weeks to design and ship the product into the app store. Some of the requirements we had were

• Know travel destinations
• User-generated travel
• Alternative destinations

With those requirements in mind, we were able to design our app. We allowed users to search for local restaurants that would be considered “whole in the walls.” If you find something through your travels that isn’t in our system then you can add it for others viewing needs.

Research

The first step in starting research was conducting interviews and making surveys. We wanted to gather more information on the users and their needs. Once we were done with interviews and surveys we were able to create a persona. When we sort our the goals we were able to take them and turned them into a user story map. We laid out the goals of: in the moment travel, Avoiding big crowds, and experience the culture of where you are. We then listed out features that would make it so that he can accomplish those goals. Our main features are

• Quick searches with filter and sort to customize searches.
• Add destinations to share with others.
• Leave comments.

Problems and solutions

Problem: Concept to Reality

When we were first pitched the idea by our mentors they introduced it as “Paris, more like embarrass?” thinking that it would recommend different destinations to go. With that in mind, we knew that we had to create some sort of travel app at the bare minimum. Our developers had it in mind that the pitch was the product. We had to remind them that the direction we went was in the apps best interest and would create a better product.

Solution: Research and User Testing

We found that the best solution for the problem was to conduct interviews and make surveys. We needed the research to back up the decisions we were making. After conducting research we found that there wasn’t enough data to support, recommending different destinations. Research showed that if someone has a destination in mind they plan around that. The only thing that people left to chance was food. Most users don’t plan out where they are going to eat. They would much rather decide long the way.

Problem: API

Early on our developers brought up the concern they had of API. Our first question from them was, “What is an API?” they proceded to tell us that an API is a site’s database. It housed all their information and would allow us to pull the information to use on our site. They didn’t have the time or knowledge of what a hole in the wall was. Without the info, we wouldn’t be able to filter the API.

Solution: Research, trial, and error

In order to help them our we stepped up to the plate and help with the API. We took a day or two finding hole in the wall destinations and find common threads that most had. With that information, we were able to test out the filter on different sites to see if they worked. After testing, we were able to give the devs our filters and they picked the right API. Choosing to go with Yelps.com API because it had a good database to start with that we could filter to get the info we needed.

Problem: Inclusive Color Scheme

When it was finally time to design we wanted to find the right color scheme. When we first started we found colors that looked good together and was the right aesthetic. When one of our mentors brought up contrast we didn’t have any answers for them. We decided that it was something worth looking into. Along the way we also found some other tools that would help make it an even more inclusive color scheme.

Solution: User Testing Trial and error

When we started testing the contrast of our app and edited them down. Once we were done looking at contrast we also started looking at other things suck as colorblind. We decided that we wanted something that would work for the impaired as well. We tested it out with the stark plugin and were finally able to choose a color scheme that worked for both. We made it so that no matter what color impairment you had had enough contrast.

learned

One of the biggest growing experiences was my leadership skills. In my group, we had a lot of talented individuals but most of us were not comfortable with taking control. In the early stages of the project, I had to step up to the plate and take charge. I asking the questions that needed to be asked and made sure everyone was on the same page.

Something else I learned was to know your limitations. Know what you can achieve and let people know. More important than your limitations were limitations for the user. We had times when the devs would suggest something for the app that would “ Be a cool feature if…” but we had no research to support it. We had to say “no and here’s why.” or “let me look into that.” Eventually, the developers got that everything we implement has to be supported. Being able to help them with that helped it got through my head as well though. In the end, we are designing for the user, not for us or the developers.

The place I grew the most was working with developers. There were a lot of requirements that I needed to meet in order for them to be able to do their job. I was able to grow in my design ability and my knowledge of my tools. I was also able to learn more developer terms that will help me in later projects.