The edible live streaming community





I wanted to take a product from conception to handoff while incorporating more UX research and testing into my design process. I seized on an idea a friend had for a streaming service focused on food.


I was the sole person working on this project. I was lucky to have a number of people to discuss, test, receive feedback from.

In creating my first Android mobile app, it was both a help and a hinderance to be limited to adhering to Google’s Material Design guidelines. Additionally, I lacked an Android phone to test my work with.

I didn’t have a budget for this project, so I was constrained to the software I already have, trials of new software, and testing on my own. In the end, I found that UX testing software, expensive and limited as it is, wasn’t necessary for a project of my scope.

Without a developer on the team, I tried to follow best practices to make potential development easier in the future. I started from the smallest widely-used android viewport and followed an 8px grid, 4dp baseline grid, 2 column layout, and a logical layer structure and style guide.

Using a host of partially-compatible design software for this project, a lot of technical challenges arose. I enjoyed testing new software, but next time I would try to use a comprehensive tool that encompassed the ability to wireframe, design, protoype, and animate all in one.




March - April 2019 (2 months)


Research, Branding, Design, Animation


Persona, Journey Map, Sitemap, User Flow, Style Guide, App Screens, Interactive Animated Prototype



Food is big business. Food choices and niche consumers (vegan, craft, etc.) are growing. Users, restaurants, and companies all want a space to interact. Users want to learn from professional chefs, but current cooking shows are slow and lack interaction and live streaming services don’t focus on food content. Restaurants want to connect with new customers, but rely on word-of-mouth and unpredictable reviews. Where can one watch, learn, and interact with chefs live? Where can a restaurant showcase their kitchen, talent, and menu?



To address this lack of interactive food service, CHEW was conceptualized as a ‘mobile food cinema’. This new platform allows for users and restaurants to connect live over food. Users are entertained while learning about local restaurants and new recipes. Restaurants can reach new clientele by showcasing their location, kitchen, talent, and menu.

Over the course of the project, my ideal solution shifted from a platform where anybody could stream their food content to a community where restaurants streamed their kitchens while users watched and interacted with them. By making CHEW more exclusive, I hoped to raise the overall quality of content on the platform, thereby attract more users. To facilitate this, I added a verification process where your identity as a restaurant is checked before being allowed to stream. Those verified accounts get a restaurant profile and everyone else gets a user profile.

The business model for CHEW was similar to that of the Twitch streaming service. The platform would be free to use, but profit would be earned from users paying for ‘question credits’ and restaurants/companies paying to advertise.


I defined success for this personal project largely in terms of our data-backed persona, Tia, and her main task: making a reservation. While testing, I rated the ease by which users accomplished this main task and other central tasks with the interface. By comparing these ratings across different prototype stages, I could assess how well the app could help Tia or other potential users accomplish their goals.






I surveyed 21 friends and strangers on Facebook and Slack with a 31-questions about technology, food, and my product concept. Overall, I found a pattern of health-conscious, tech-savvy people expressing interested in a food streaming service. Based on these responses, I defined a persona and main use case.

On average, the respondents were:

  • in their late 20s

  • located internationally

  • tech-savvy

  • interested in Italian, Japanese, Asian, and Arabic cuisine


The respondents enjoyed watching cooking, but didn’t use food-related websites or apps often. They learned about new restaurants and recipes from web searches, social media, and friends. They weren’t keen to open a cookbook and follow a recipe the old-fashioned way. Although the respondents were only somewhat interested in a food streaming platform, they sought to interact with content they did consume. Ultimately, they stressed that a difficult product or recipe would deter them.

“I wouldn't be really motivated to try a new recipe that requires unusual ingredients/kitchen equipment/super advanced skills.”

“I wouldn’t use [this app] because I like to cook with efficiency, I feel like videos and livestreams would slow me down. I just want to go through the recipe and be done.”

“I'd rather interact with people I'm cooking with in the room”



The main competitors to a product like CHEW in the live streaming space are Facebook Live, YouTube Cooking, Twitch Food, Periscope, and Livestream.

The most prominent live streaming platform is Twitch, which does have a ‘Food & Drink’ section. However, there are very few active streams here because most of the Twitch audience is young male gamers; not the type to watch cooking. Facebook & Youtube’s live sections are, of course, very popular, but not specifically focused on food. I found that these generic live streaming platforms contained mostly companion content to cable shows, without much original food content.

The Twitch, Periscope, and Livestream mobile apps were particularly useful for inspiration during the initial design process.



CHEW users could be anyone who enjoys watching cooking. However, survey responses suggested that our target audience is a younger, tech savvy foodies who eat out often. The responses from my survey suggested that our audience would largely be young, health-conscious, tech-savvy foodies who eat out often. We would provide this target audience with a community to learn recipes, about local restaurants, and to directly interact with chefs. This resulted in our persona for this project, Tia.



To better understand what an average experience with our product might be, we mapped Tia’s flow trying CHEW for the first time, setting a stream reminder, asking a question live, and making a reservation (the main use case).



A basic information architecture was conducted resulting in a sitemap to provide a list of essential screens and flow logic for the design process.



A visual representation of the path my persona user, Tia, would follow to accomplish our main task: making a reservation at a restaurant. This user flow diagram helped me to reflect and receive feedback on the internal logic and requirements of the product





The CHEW logo focuses on our mascot, a goofy-looking boy with bulging cheeks who is chewing on the food content viewed in the app.

The CHEW tagline, “The edible live streaming community”, indicates that the the platform is more than just a service. It’s a community where customers, chefs, and companies all can interact, share, and learn about food together.



I utilized Google’s Material Design color palette to choose dark purple and turquoise for this product. My central aesthetic idea for the app was of a fine-dining ‘food cinema’. A cinema interior uses dark colors to focus attention to the media playing. For this reason, dark purple was chosen as the primary color for this purpose, while being more quirky and characteristic than black. An analogous bright turquoise was chosen as a secondary color to match the primary purple while still standing out.



Futura was chosen for the header and body font as it’s a common web font with many weights that is readable at many sizes on many platforms. Additionally, Phosphate Solid was chosen for the CHEW logo text to give it a thick, almost ‘chewable’ quality like a large steak.



I used Google’s Material Design elevation system to create a design hierarchy of manipulatable elements: e.g. buttons, cards, etc.



I chose to use Google’s Material Design two-tone icon set to fit with the quirky aesthetic of the CHEW app.



Sketch -> low-fiedlity -> high-fiedlity

I started my design exploration by sketching paper wireframes with inspiration from material design guidelines, other food apps, and styles/patterns I had noticed around around the web (Medium, Dribbble, etc.). The branding had largely been decided on previously for a mock web landing page for CHEW. From here, I moved to Figma where I designed low-fidelity screens without any copy or assets, and finally 49 high-fidelity screens ready to export for animation.




3 rounds: 1-2 about screen logic and features, 3 about design and aesthetic elements

I created a task list that my persona and use case would need to accomplish, and ranked (1-3, 1 being worst, 3 being best) how each tester completed the task. Had 1 unstructured testing for each round. Then I focused on specifics issues that were mentioned/repeated with each tester and I focused on tasks that scored low (high difficulty) overall.





Issues navigating to certain pages.

  • Reservation

What did you learn from the tests? What surprised you about the results?

  • It surprised me how quickly users moved through the wireframe (which was so simple and poorly drawn). They understood the basic logic of a mobile app and of material design’s look. The key here was to not to stray too far from these tried-and-tested looks for the sake of creativity at the cost of the user’s ease of experience. 

  • Also, people just liked to click around a mobile app without really thinking… even without a goal in mind… and especially when they didn’t know where to go. They just liked to explore.

  • It surprised me how hard it was to find certain features and pages that I thought were obvious. This is where having an outside perspective on something you spent hours designing and staring at is really useful.

Flow logic

  • People really like to just click, click, click, click without thinking about what they are clicking. Especially if they are confused and don’t know what to do. They do this especially when they first enter an app to explore. It’s almost like a dog sniffing out his territory before he relaxes. It’s human nature to explore mindlessly I think.

  • I have each prototype (InVision, Figma, InVision, Prtotopie) along the way. Link each one? Showcase selected screens from each prototype? Have GIFs showing changes for selected screens?

Check if aligns with UX research and persona

The Nielsen Norman group recommend testing with no more than five users at any one time. Multiple tests with <5 users are ideal. There are diminishing returns with larger numbers of users.

Unstructured test and task test

Write out list of tasks, actions, use cases, user flows.

  • Ask user to perform each task.

    • If the user can perform them quickly and with no trouble, mark it a 3.

    • If the user can perform it but has some struggles, mark it a 2.

    • If the user can’t perform it, mark it a 1.

  • Ask 5 different users to perform these tasks, add up the numbers, and start working on the lowest scoring behaviors first.

Sit down with prototype next to user

  • Give them brief introduction and show them the product

    • Explain to them that you are going to show them a product and you want them to use it and speak aloud what’s going through their mind at all times.

  • Ask them:

    • What’s going through your head as you look at this?

    • What do you think you can do on this page?

    • How would you do that?

    • What are you thinking?

    • What do you think would happen?

Tasks (5)

  • *Check your Profile

  • *Watch a Stream

  • *Make a reservation at a restaurant

  • *Send a message to a friend

  • *Change a setting

  • Message a Friend

  • Check Notifications

  • Sign Up

  • Filter Stream options

  • Message person hosting live stream

Unstructured Test

  • Introduction 

    • I will show you food live streaming app. 

    • I want you to walk me through how you would use it by speaking and clicking.

  • Questions

    • What are you thinking?

    • What do you think would happen?

    • What do you think you can do on this page?

    • How would you do that?

Task Completion Test

  • Introduction 

    • I will show you food live streaming app. 

    • I will give you tasks to complete.

    • I want you to walk me through how you would do it by speaking and clicking.

  • Tasks

    • Change your profile picture

    • Watch a stream

    • Make a reservation at a restaurant

    • Send a message to a friend

    • Change your settings

    • Filter the streams by Japanese food

    • Pick a restaurant from the map

    • View a restaurant’s profile

    • Create your own stream

    • Find a restaurant’s recipe

    • View your reservations

  • Rating

    • If the user can perform them quickly and with no trouble, mark it a 3.

    • If the user can perform it but has some struggles, mark it a 2.

    • If the user can’t perform it, mark it a 1.

Are the user’s goals being met?

  • Are actions available for user?

  • Are the user’s frustrations dealt with?




Use Figma’s smallest default “Android” dartboard (360 x 640)

4dp baseline grid

8px grid

48px x 48px tap targets

  • 40px between adjacent tap targets

  • 65 characters per line (65 cal) is ideal length of text

  • Minimum mobile body (reading) text: 16px size / 1.2em line height

  • Magic number is 8 (elements sizes, spacing, fonts, etc.)





What features are most important to have.

  • Difference between friends, following, followers?

  • GO LIVE button. Reserve button. Recipe button.

  • Question credit

  • Reminder button

  • View recipe

  • Go LIVE verification process

  • Make on boarding pages simpler

Major features

  • What is the best way for a user to ask a direct question to the chef without being lost in all the comments and noise?

    • A credit system where you get 1 question credit per day (unless you pay for more) to ask a direct question to the streamer. It bypasses all the other comments and stands out for the streamer. Is it a separate list (comments and questions) or does it just visually jump out on the screen? I think it needs to be on a separate list so that if the streamer is cooking and comes back to the screen they see it and can address it.

  • How will a user get recipe details? Sure they can watch a stream… but what if the streamer didn’t detail their recipe or go into measurements.

    • The streamer could attach a recipe document to a stream before or once completed (shows up under restaurant profile for past videos). There our user could open and use it while referring to the stream while cooking.

  • Rating is attached to the user or profile. Connected to how many “thumbs up” or lets call them Michelin or CHEW stars you receive on your live streams. So nobody is poorly rated, there is just higher and lower rated people based on stars.

  • Section at top of discover page to recommend the latest or newest restaurant. Featured or recommended section/tile based on newest restaurant or what you selected to be recommended.

  • How to show an upcoming stream vs a current stream vs an old stream

  • Button to save/follow/remind you about upcoming streams

There is a social aspect where you can follow users or restaurants. You can talk to other users. You can ask questions of restaurants with credits on their stream.





Scroll, drag, active state, error state, button tap, screen transition, pop ups, loader, splash screen

What is most important?

  • Big blue fab buttons.

  • Play button on stream cards

  • Buttons (purple or blue) to click on each page

  • How do the layers work?

    • Menu page is on top.

    • Everything within the menu slides out on top of home plane.

    • Top right filter button pages are on top.

    • Video and content comes from bottom. 

    • Messages and following are on same plane as home.

  • What is my brand’s expression?

    • Exotic, quick-paced, quirky.

Add loading time/animation to when you input your stream verification information

  • Explain in case study that providing fake loading time makes a user feel that the app is working better.










What was the final result? How did it get made? How did you measure its efficacy? Did you measure success?

  • The final result was 49 mobile screens created in Figma that were organized/named and ready to be handed off to a developer. Additionally, I had an animated interactive prototype made in Protopie to share to illustrate the intended animation and flow of the screens. And lastly, a branding guide and tentative tablet and web screens if the app was to be fully designed and developed for other platforms.

We’re success metrics reached?

  • 1-3 rating for users completing tasks went up over the course of testing different prototypes


How did the problem shift as you worked through the project?

  • Realized that a food streaming app wasn’t viable. Shifted to focusing on following through on the entire design process for a concept.

  • Shifted to focusing on creating a Twitch replica where anybody could stream their food content to a community where restaurants streamed their kitchens while consumers watched, followed their recipes, reserved seats with them, awarded them stars, or asked questions with credits. I thought allowing just anybody to stream cooking would lower the quality of the platform, so instead there is a verification process whereby we check if you’re an actual restaurant before you can stream. You get a restaurant profile, everyone else gets a user profile.

  • There is a social aspect where you can follow users or restaurants. You can talk to other users. You can ask questions of restaurants with credits on their stream.

  • We focused on our persona, Tia, and her main task: making a reservation.

What problems arose?

  • How to export design from Figma to software that can animate and embed an interactive prototype on the web.

    • Tried InVision, InVision Studio, Adobe XD, Principle, Figma, and finally Protopie.

    • Protopie-Figma integration was in beta, so there were lots of import issues to adjust.

    • Custom HTML/CSS had to be used to embed a presentable prototype.

  • Doubts about product idea and business model. 

    • Business model and product (Nom) has already been created and failed (2016-2018). It was well funded, organized, and launched with support from many celebrities and chefs. Founded by cofounder of YouTube.

    • Young people who watch streams don’t watch cooking.

    • Learning cooking while watching too difficult.

      • Dirty/wet hands from cooking while handling technology

      • Watching entire stream too slow; people want just the food or recipe.

    • Do technology and food really fit together? 

      • Let’s say a chef is cooking. If he is streaming from his phone with the back camera of his phone. How will he know what’s going on with his viewers? What questions they are asking? He would have to stop cooking and go around to the front of the phone to respond. Doesn’t make sense. I had this same thought early on in the market research process: technology and kitchens don’t mix. You don’t want to be using your phone/computer/camera around water, fire, food. Stopping to wipe your hands off to type of fix something on your computer wouldn’t make sense while being focused on cooking.

    • People want quick recipes and entertainment, not watching the whole cooking process on a stream. Don’t want the hassle. Would rather interact with people IRL. They weren’t crazy about the idea of food streaming.

    • Why use this service instead of Twitch, Facebook, Youtube, etc?

How did the problem change as you learned more? How did you adapt (iterate, refine, pivot) the solution as you learned? Which of your most precious ideas did you kill off in the process?

  • I changed the main concept of the app from a streaming service for all to a streaming service for only restaurants. I added major features (recipe, reservation, question credits) to align with this. I had a lot of feedback on changing the color and the font, but after much testing… I decided to stick with my gut feeling. 

  • Simplified onboarding process.

How did you decide you were finished? Was it a clear marker, or did you have to make a tough call?

  • You can keep iterating, fixing, changing, and adding forever. You definitely have to do your due diligence with regards to testing, iterating, and then call it when it feels right. I wanted to call it when I was done with my animation, but realized if I was going to test every other stage of my project, then I had to test the animation as well.

How did you feel at different parts of the project? When were you most excited? When were you most frustrated?

  • I enjoyed the user testing (enjoyed talking to people and watching them “unbox” the product and run into issues and make note of them) and animation (fun, great to see everything finally come together into a realistic product).

  • I disliked starting the project (hard to get rolling and know where/how to begin) and being stuck with so many options/iterations/issues deep into the design step.


Survey was too long, too many questions. Didn’t give great data. In-depth interviews would’ve been better.

Over the course of the project, I realized that a food streaming app wasn’t market viable. Instead, I shifted to focusing on following through on the entire design process for a concept. Nom failed

Being confined to Material Design and android, which I hadn’t designed for before. I didn’t even have an android phone to test my designs in real life on along the way. That was a major mistake that I would change next time.

Dealing with designer’s block

This is the longest design process for a product that I’ve yet tackled. Throughout that process, there were days where I really hit a “block”. Where I got lost in the minutiae of the present problems and variables and lost sight of the big picture. This especially happened during the initial research phase. I’m primarily a designer, so I often would get frustrated with trying to write about the product, business model, or user needs and think––I should just jump to the design stage. What am I doing wasting my time here if the point of this entire exercise is to design an app.

This is where starting with a clear sense of overall direction/goals/purpose really helped. I could glance back at my outline of my workflow and know that my current predicament had a purpose in the grand scheme. That the process was a marathon, not a sprint. A night of sleep or a new user would give me a fresh perspective that would allow me to find a solution to the problem and push forward to the next task. Additionally, having the focus of one persona (average user) and one journey/task (average goal) during the design phase was key. There is a laundry list of potential features, pages, solutions that could be added to the app, but framing these in the context of what would be best for my persona helped me strip away the crap and design only the essentials well.

What would do differently?

  • She suggested it was better to start with 5 qualitative user interviews then do user surveys then create a persona based on this information. I shouldn’t rely too much on information from surveys because these person are really motivated and enthusiastic about the product/idea or about helping you. Not an average user.

  • “How do you choose to do interviews or a survey first?” It depends on the product. On a startup, in a new field, its better to start with qualitative interviews. On a more well known product/field, a survey is better. Ultimately though, you will have fans of your product filling out the surveys, which can bias it. People will talk more in an interview than in a survey, which can allow you to get more in-depth data and insights. Offline, in-person interviews are better to gauge feelings, emotions, and problems. Easier to design for someone you really know. You don’t “feel” or “see” the pain points with a product from a survey response.

  • “How do you pick your users to interview?”

  • She decides who to interviews through a “screening” process.  Check your competitors and see who is using those products. Or based on rough picture in your mind, ask on Facebook or some group if anyone is interested in your idea or for an interview. You build potential users for the future when your product is complete.

  • I didn’t even have an android phone to test my designs in real life on along the way. That was a major mistake that I would change next time.

Should you have spent more time talking to users?

  • Not overall. I tested and surveyed users well. However, I should’ve started the entire research process with a couple of in-depth user interviews (see Anika’s suggestions).

Should you have spent more time exploring concepts?

  • I could’ve done some A/B testing on certain pages instead of just relying on my judgment. However, this is a brand new product… a/b testing is better for established products where a small change can make a big difference to a large user base.

  • I could’ve explored more branding concepts initially (colors, fonts, logos) instead just going with my purple landing page. By the time I got feedback to change those colors in the 3rd stage of testing, I was already too invested in them and couldn’t see changing them to anything else.

Did you stumble in setting expectations or communicating with your team?

  • No communication problems. I did a great job user testing. My surveys could’ve been simpler and had more specific questions.

  • I wasn’t sure about how to set goals and success metrics and measure success at the end. How do I do this on personal project that isn’t developed or sent to real users? My goal was to create a portfolio piece… any other “goal” was really more of my solution to the problem. I felt “successful” in the end because I completed it at all, and it was a long project, and was happy with how it looked.

Throughout a successful project, you’re going to have to prioritize. This means saying “no” many more times than you say “yes”. Recall those decisions, and pinpoint where you would have gone next if you had more time or resources.

  • Future pages and features that I said no too.

  • Including more animations that aren’t possible in protopie (button flash) and I didn’t have time for (keyboards popping up, active/error states, input layers).

  • Thoroughly designing an entire tablet and web product.

  • Designing for iOS mobile and tablet.

Not all projects are successful; this is ok. The team can fall apart, the project can fail to get traction, the client can run out of time or cash, you may solve the wrong problems or spend too much time going down the wrong path, etc. Talk about one of these problems.

  • Ultimately, my goals were completed with the project. However, along the way I realized that bring a real product like this to market (even if I wanted to) wouldn’t make sense. The survey suggested that people weren’t really into a food live streaming app. That the product had already been tried (Nom) with way more resources and backing and failed. That the realities of using food and technology at the same time didn’t make sense. But this is okay, because for me it was more about the design process than if the product or business model was viable.

Future Features

Future improvements

  • What would complete this app?

    • Error page

      • When you click a feature that isn’t created/implemented/ready.

      • Empty dinner plate/bowl.

      • Quiet kitchen

    • Report button

    • Report button page

    • Social share icon dropdown

    • Settings pages

    • Profile page edit page

    • Other restaurant profiles

    • Other user profiles

    • Scrolling on home live/upcoming/videos pages

    • Other stream pages

    • Stream dashboard

    • Go LIVE stream page for recording

    • Reservation edit page with delete/cancel button

    • Followed restaurant profile page

    • Add follow user profile page

    • Other filter pages with background for map/upcoming home/videos homes.

    • Other menu pages with background for rest of app.

    • Other menu pages with different part highlighted.


I have a number of individuals to thank for their testing and feedback throughout the process. It was really an international effort of family, friends, strangers, and the design community. The project would’ve been far more 1-sided without all your perspectives.

  • 11 people I did usability testing with:

    • Paul, Anja, Cody M., Walida, Melissa, Petar, Halle, Bun, Cody D., Anika, Sam

    • American, Serbian, Thai, Hungarian, Indian

    • Teacher, UX researcher, writer, developer, medical student, engineer, real estate agent

  • 9 people I did a design check with:

    • Akshar, Marcus, Sandra, Sanket, Heimdall, Matthew, p_rototy_pe, Ray, Riki

    • Indian, British, Nigerian, Kiwi

  • 21 survey respondents:

    • Israel, Sweden, Canada, Germany, Indonesia, Japan, Spain, South Africa, Taiwan, Ghana, Vietnam

CASE STUDY: Starter Pack – Life Improvement (Web)

CASE STUDY: Starter Pack – Life Improvement (Web)

CASE STUDY: Move - Ride Share (Mobile)

CASE STUDY: Move - Ride Share (Mobile)