Teahouse customers have few opportunities to get suggestions about drinks + customizations.
Suggest drinks + customizations based on other customers with similar tastes.
Capstone project for my Bachelor’s. No subject or process constraints.
Sole UI/UX designer
September to December 2021
I conducted an ethnographic study of teahouse (boba/bubble tea) customers ordering drinks, mapping the current state of a typical customer journey.
I centered my problem space on this specific high friction flow (yellow dotted outline).
Customers trying a teahouse for the first-time experience friction because they are unfamiliar with how this teahouse compares to other teahouses they’re familiar with.
The current solution is inadequate. Increasingly, the typical key touchpoint, the order taker, has barriers to recommending drinks:
They don’t know the customer’s unique tastes
They might be busy
They might have a self-ordering kiosk
Distilling a pain point
Customers are unsure which drink to try, and have few opportunities to help them inform their choice.
Customers want to ensure they’re getting a drink they’ll like.
Teahouses want to maximize customer satisfaction and retention.
Since this is a UI/UX exercise, technical and business constraints weren’t considered. From a more holistic product design perspective, I overlook these limitations during this project.
Industry leaders of the space, like Square, are generalized and have massive scale to reduce costs. Limiting potential clients to teahouses result in a tiny market.
Given the deeper integration of this product with a teahouse (vs. other point of sales services), the product requires effective and scalable client support infrastructure and processes.
Using data from other client teahouses to provide normalized recommendations requires a certain scale that would be difficult to achieve at first.
Customers may be concerned about the privacy of the data about them this service would produce.
Reconciling pain points
I envisioned how a typical customer journey could look if avoidable friction were removed.
"What would I like?"
The core of my solution is an (out of scope) software that recommends drinks + customizations that a customer would like based on their preferences. (A bit like TrueFit, horizontal competitor)
Recommendations are shown whenever a customer has a choice to make.
"Teaprint knows what I like"
I created a customer-facing brand, Teaprint, to grow awareness about the recommendation engine.
The resulting brand equity would help set expectations of customers visiting a client (Teaprint-enabled™) teahouse.
"I want something similar to what I like"
First-time Teaprint users can answer questions about drinks they’ve previously enjoyed to be recommended drinks + customizations.
The software would use this data as a baseline to provide recommendations.
"I liked x and didn't like y."
Following a purchase, customers are prompted to rate various aspects of their order to inform Teaprint.
They can be incentivized to leave feedback with more accurate recommendations next time and by the business.
I conducted remote moderated testing using Maze with six friends.
Customers understand algorithmic suggestions
Customers can customize their drinks
Teaprint onboarding educates customers about cross-business recommendations
Flows were easy to understand and follow
Customers expect the graph part of the graph selector to be tappable
Teaprint onboarding didn’t do a good enough job at explaining what Teaprint does
Opportunity to provide more crowd-driven reviews + recommendations to help customers make decisions
Made graph in the graph selector tappable
Made copy for Teaprint onboarding more concise and clear
Rich reviews + recommendations were not a usability flaw. It would make a more well-rounded solution, but it was out of scope.
This project was successful in its objectives: to showcase my end-to-end product design skills for my undergrad capstone project.
The entire problem space stems from my desires, marring it with the false consensus effect (you are not your user).
I attempt to disclaim this bias by acknowledging the assumptions I make, and ultimately chose to overlook this bias for the opportunity to tackle a problem that I love for my first end-to-end "self-briefed" project.
Usability testing could have provided more precise results if I instructed testers not to “look around the app” (and that they could have the opportunity to do so after the study). ※