Full Case Study



  • Project - Create solution for challenges in dining experience due to restrictions and preferences 

  • Target Users - Eaters with unique taste preferences, food restrictions, and specialized diets
  • Problem - Dining experience for eaters with limited food options is challenging, frustrating, and poses potential health risks. Solutions in the market are inadequate and this target market is underserved
  • Goal - Understand core user pains, and propose a product solution to address them, and proved a safe and enjoyable dining experience
  • Role - Founder, UX Designer & Researcher, Strategist
  • Team - Strategic advisors



Threek is a mobile app that optimizes dining experience for eaters with unique taste preferences, food restrictions, and specialized diets. In this solo project I planned and executed all aspects of design and strategy discussed here.



Dining experience for eaters with limited food options is challenging, frustrating, and poses potential health risks. The impact on an experience for these folks can vary from mild disappointment to a trip to the ER. It hurts restaurants and their patrons, and the market has done little to address the needs of this sizable target group.



As an eater with a number of food restrictions, this challenge is something I personally identify with. However, with any user centered product development process, hunches are good starting points but not proof of product-market-fit. My approach has been to talk to as many potential users, restaurant owners and staff, and food-focused entrepreneurs as possible to fully understand the pain points of stakeholders at all points in the dining and eating experience.

Research & Discovery

My goal for research and discovery was to understand common threads across user subgroups, gain new insights aut users' hopes and pain points, and get to know the way people talk about the range of restaurant experiences they've had.

Click to view live survey

Click to view live survey

User Validation Survey

Early on I needed to reach out to as large a group as I could in order to validate whether there are pain points in the dining experience that potential users identify with. I prepared a brief 10 question survey and sent it out to 200 people in my network. 71 responded, which was far better than I expected. 

Of these 71, 50 expressed negative comments about menu experience in particular, especially those with dietary restrictions. They felt it complicates choices, doesn't include relevant information, and is boring and impersonal. 

User Interviews

Throughout the discovery phase I spoke to as many potential users as I could get my hands on. Whether they were gluten-free or bread addicts, vegans or meat lovers, dieters or exploratory foodies; everyone had interesting perspectives on the dining experience and what they found to be challenging given their food interests and needs. A recurring demographic I didn't consider deeply were people with allergies, and parents of kids with allergies. Their pain points in the dining experience are beyond inconvenient—they're dangerous.



Interviews have their immense value for the UX discovery process. I wanted to find something deeper to really understand my users deeply. I created a participant questionnaire that users would complete either while dining out, or immediately after. It asked them specific experiential questions about their time out, and aimed to better articulate just what goes through their minds when searching for a dish to eat. Rather than a very wide net, as I did in the survey, I selected individuals I knew dealt with significant food restrictions. This allowed me to understand the target user group intimately.

Competitors on Dining Experience Timeline

Competitors on Dining Experience Timeline

Competitive Analysis

For the competitive analysis process, I chose to blend it with an idea of the Dining Experience Timeline I developed in this phase. It breaks down the dining experience into 7 parts, from restaurant discovery to when an eater leaves a review. I analyzed 14 competitor apps in the food space. 

Nearly every app focused on (or at the minimum includes functionality for) restaurant discovery. This aspect of the Dining Experience Timeline is saturated, and likely risky to enter into. However, it also shows user needs for solutions around this.  If Threek includes restaurant discovery in it's flow, it will need a unique approach.


User Personas

The culmination of this above discovery and research process are the user personas. Thanks to the conversations, feedback, insights, and ideas of interviewees and survey respondents, I had plenty of data in-hand to generate compelling personas to guide product design. I created personas not only for various user profiles, but also for the restaurant stakeholders (owners, managers, chefs, waitstaff, etc) that are very much intertwined with the app's success. 


Structure, Flows, & IA

We're now ready to bring the ideas and understanding of user needs into a concrete structure, flow, and user interface. We've mixed the building materials, and now we're setting the foundation and putting up the frame for what will be a solid product.

Dining Experience Flow Sketch - Click for detail


In working through the experience mapping process, my aim was to map the entire dining experience, from deciding to go out all the way to putting up a review online. This experience flow is sketched out in the image here in a basic form. Threek does not claim to be an app for the full dining experience from start to finish, but this process helped to think about which areas of the experience our competitors are active in, and how Threek may either compliment their existing offerings, or provide a much needed solution to a gap in the overall experience. 

Below are two images showing the result of the experience map exercise where we mapped out customer objectives, behaviors, and positive/negative experiences, all tied to the seven stages of the Dining Experience Timeline mentioned above.


Pictured here are two versions of user journey sketches for Threek. One is the most basic journey from login to placing an order, including the minimal number of steps needed to complete the task. 

This basic journey however doesn't account for areas in the user's experience that will likely take more time and thought. In the second more detailed sketch, notice the area between the smart menu and the dish detail. This area of the experience is essentially where the user could spend a significant of time. The better the app can suggest dishes (thanks to Threek knowing a user intimately from their taste and mood profiles) the faster the user will select a perfect dish and order.

The third image here takes the essential user journey and describes each step in more detail, specifically related to it's functional purpose (why this page/action exists) and experience considerations (what experience the page/action aims to create for the user). 

Organization Structure

The organization structure is precisely what it says it is, and is similar to a site map when designing the information architecture of a website. In our case, it lays out the complete organization of information within the application.

Given that the app is not highly complex, the organization structure is also quite straightforward. In my process, I prefer to begin rough sketches of the structure from early on. Shown here is a final, more refined version that encompasses the current structure of the app. It will be key in this phase in order to finalize user journeys, navigation design, and final wireframes. 




Sketching is one of the greatest tools for ideating on interface structure, functionalities, navigation, information architecture, and even some basic visual design elements. It can answer questions, or in many cases create many new product questions that need to be answered in order to proceed. Below is a basic sketch flow including all app pages. This was the structure that laid out the UI up to the prototyping phase. 



Sketching is an ideal time to iterate and make adjustments to the user interface. It's the time to play with ways to organize information and desired user actions to meet the needs of the product. Here are some other sketches I did to quickly ideate on everything from layout to interaction. 



Our wireframe sketches above, coupled with the user journey and site map, have led to this low fidelity wireframe and user flow document below. Though it carried over many of the elements of those final sketches, we found new aspects of the product previously overlooked, and developed solutions for them. 

It's at this point the project is beginning to really take shape and become something tangible. By sacrificing fidelity we're able to focus on the essentials of usability, navigation, hierarchy, structure, and content. Often in the wireframe stage, especially when put into a clickable prototype, we come up with new questions, solutions, and product insights we hadn't seen before.


Requirements Documentation

With the project taking shape, I began talking to developers with specific goals in mind. As a non-technical designer, developers are an excellent resource to understand the technological needs to build a product in depth. Speaking to multiple developers gave me new insights about potential back-end challenges we'll face, as well as new product opportunities.

I drafted a detailed requirements document which was the basis for these discussions. It included page by page requirements, including page purpose, design styles, structure and taxonomy, interactions, terminology, and current wireframes. 


User Testing & Prototyping

The prototyping and user testing phase is the point in the process where UX value becomes the most clearly pronounced. It's when all the assumptions of structure and design come together and are put in front of the people who will judge your work by using it, or not. The rubber meets the road here, and this is where products come to thrive or fade away. 

Low Fi Prototype

We've come a long way from that first survey. What I thought I knew at the start has changed, as it so often does (and should!). I took our wireframes and put quickly put together this simple prototype in InVision. The video clip to here shows me clicking through it, from login to order.

The purpose of this prototype is to test the basic structure and navigation of the product. I starting the testing with myself,  spending focused time in the shoes of users to consider what they could be hoping to accomplish here or there. Cross referencing this with user profiles, the Dining Experience Timeline, survey responses, as well as design patterns and styles that could help work out the kinks.


User Testing & Interviews

In interest of speed, I moved forward testing this low fi clickable prototype with 10 users. Testing with such a prototype does present challenges, since people are not used to navigating a product made up of text and a bunch of empty boxes. This meant that I played more of a role in guiding the users through the product, or at a minimum being a resource for them to ask questions. 

This situation did limit the learning from the testing phase, as opposed to observing a user interact and figure it out all on their own. Regardless, I did gain important insights from this method. It was extremely valuable when comparing it to the user interviews I conducted at the start of the project. Now, combining the test with interviews I was able to have conversations that went beyond their general feelings of a challenging dining experience, and begin to pull back the curtain on a solution to their problem.

Though still basic in visual aesthetics, it this something they would use? Does it have the potential to meet a need in their lives? What are some of the challenges using a product like this would create for them? Is there something I missed completely in the structure or flow of the product? I went into the testing and interviews with these questions in mind.

What I learned is helping me to revise the product, and create hi fidelity mock ups, and creating a life like prototype that will be more familiar to users in subsequent testing.


This project is still active, and the summaries above are a taste of my process thus far. No design projects are ever done, but they can all be complete enough to put in front of users, and continue learning and iterating. If you're interested to talk about this project or other similar work you're doing in more depth, please contact me. It's become a minor obsession for me so I'd love to talk about it with you!