The edible live streaming community
March - April 2019 (2 months)
Research, Branding, Design, Animation
Persona, Journey Map, Sitemap, User Flow, Style Guide, App Screens, Interactive Animated Prototype
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.
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
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.
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. Below are three examples of this design process from sketch, low-fidelity, to high-fidelity.
A round of user testing, involving task completion tests and an unstructured test, was conducted on each successive prototype. For each round, I followed The Nielsen Norman group’s recommendation to test with no more than five users, as there are diminishing returns with larger numbers of users. The first two rounds focused on screen flow logic and features while the third round focused on aesthetic and design elements. Before each test, I would briefly introduce the tester to the main concept of the app and, to ensure I wasn’t biasing their responses, remembering to ask open-ended questions throughout like:
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?
For the task completion test, I created a task list based on my persona that I would ask users to to accomplish. Then I ranked (from 1 being worst to 3 being best) how easily the tester completed each task, allowing me to judge success. Such tasks included:
Watch a stream
Make a reservation at a restaurant
Send a message to a friend
Change your settings
View a restaurant’s profile
For the unstructured test, I asked the tester to show me how they would use the app, while speaking about their thought process out loud.
User testing was critical to reassessing how my designed solution was aligning with my persona’s goals and what issues still remained within the product. It allowed me to ask: what is frustrating for a new user? are the correct screens and actions available or emphasized? When returning to editing my designs, I focused on specifics issues that arose repeatedly with the testers and on tasks that scored the lowest (high difficulty). For example, many users scored poorly on the task to “make a reservation at a restaurant” in two prototypes, which was a red flag for me to totally rethink the reservation screen and how it connected to the rest of the app.
I was surprised how quickly nearly all of the testers moved through even the poorly drawn wireframe prototype. They often began mindlessly clicking through the screens to explore the app before I could even start with a question. They understood how to navigate the logic of a material design interface without thinking about it. This was a key realization for me, to follow the tried-and-tested interfaces and patterns instead of trying to reinvent the wheel for the sake of creativity at the cost of the user’s ease of experience.
Additionally, it surprised me how hard it was for testers 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.
This was primarily a mobile project, but I kept responsive design at the forefront of my process by beginning with the smallest android viewport (360dp x 640dp). The mobile design in Figma had a 8px grid, 4dp baseline grid, 4 column layout with 16px gutters and margins. I ensured mobile best practices by including 48px x 49px tap targets, 65 characters per line for body text, and keeping 8px as the ‘magic number’ for sizing and spacing. Additionally, I created tentative tablet and web mockups if a port to those platforms was decided on in the future.
CHEW stands apart from other competitors in the food industry by allowing you to learn and interact with chefs and restaurants. The app focuses on emphasizing ratings, reservations, and reminders. I focused my design process around these core features.
The recipes on CHEW are meant to be utilized in companion to a live stream of recorded video. You access the recipe that the restaurant provides for a dish they are making live. The streamers can’t always go into detail about the measurements and steps, so the attached recipe can be referred to while learning from the whole cooking process via stream.
On other streaming services, the chat box is a wall of quickly moving text and memes. Not the best place to ask a specific question and cut through the noise. The question credit system provides uses with 1 credit per day, with a paid option to purchase more. The credit can be used to ask a direct question to the streaming chef that will bypass the normal chat box and get pinned for the streamer to answer.
Every food platform has a rating system, typically out of 5 stars. CHEW wanted to be different by utilizing a ‘raw rating’ in the form of CHEW stars, like the Michelin stars that restaurants are awarded. The stars can be given to users that ask good questions or streamers that put on an impressive show. In the end, this lessens the focus on being poorly/highly rated as there are just higher and lower rated people based on stars.
If you watch a restaurant’s stream that particularly impresses you, you can always go to their profile and make a reservation––connecting you to their seat schedule, and dates.
For both upcoming streams that you don’t want to miss and reservations you’ve made at a new restaurant, a reminder system within the app keeps you up to date on your latest food journey.
I focused on my main features and call-to-actions (CTAs) when animating my CHEW app. I wanted the animation to be quick-packed and quirky to match the express of the brand and goofy CHEW character. The following microinteractions were involved: scrolling, dragging, button tap, loaders, and splash screen chewing. Adding working scrolling bars to the video player and distance filter involved complex variables and formulas. A fake loader was added to both the reservation and verification processes to give the user a feeling that the app is working better. Below are a few examples.
The 49 mobile screens were organized, logically named, and prepared to be handed off to developers via Figma or Zeplin to pull HTML/CSS from.
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
By the end of the project, I concluded that a food streaming app wasn’t market viable product. A nearly similar platform called ‘Nom’ was launched by YouTube co-founder Steve Chen in 2016 with $4.7 million in funding and backing from major celebrities. Despite this support, the platform was taken down in 2018.
Young people who are comfortable with live streaming as a technology aren’t that interested in cooking. Additionally, the realities of technology and food don’t fit well together. Cooking in a hot, hectic kitchen with dirty hands while trying to handle cameras and answer questions doesn’t make sense. Users interested in food ultimately want quick entertainment and recipes, not a long cooking process on stream. And lastly, I didn’t feel there was a strong enough reason to would people use this service instead of Twitch, Facebook, or YouTube.
I wanted to embed an interactive animated prototype of my app with a device overlay. After considering InVision, InVision Studio, Adobe XD, Principle, and Figma, I settled on Protopie. A recent Figma integration released a month earlier allowed me to import my screens into Protopie. However, because it was still in beta I had to import one screen at time and adjust hundreds of minor compatibility bugs. Lastly, custom HTML/CSS had to be used to embed a presentable prototype on this page.
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 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.
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.
My user survey had far too many questions and didn’t provide valuable data. Surveys cannot be relied on as you get respondents that don’t represent average users. They are biased just by being motivated to fill out your survey. It’s easier to design for someone you really know. You don’t “feel” the pain points with a product from a survey response .Next time I will begin my research process with a screening for interviewees and conduct qualitative user interviews where I can get thorough responses and emotional insights.
I didn’t 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.
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..
An entire tablet and/or web product.
Animations that aren’t possible in Protopie:
button ripple effect
social share icon dropdown
additional settings pages
profile edit page
additional user/restaurant profiles
additional stream pages
reservation edit page
I have a number of individuals to thank for their testing, feedback, and consolation throughout this process. It was an international effort of family, friends, and strangers from America, Serbia, Thailand, Hungary, India, Britain, Nigeria, New Zealand, Israel, Sweden, Canada, Germany, Indonesia, Japan, Spain, South Africa, Taiwan, Ghana, and Vietnam. The project would’ve been far more one-sided without all your perspectives.