Interaction Design Through Boba
Boba or bubble milk tea is a tea drink with numerous toppings availible, from tapioca balls to egg pudding. For me, it is an obsession, if I could go to a boba shop and pick it up as much as a coffee lover goes to their local coffee shop does, I would. But boba can be very confusing with the range of flavors and toppings availible and also unhealthy, often containing more sugar than a can of soda. For those unfamiliar with less common flavors like wintermelon, taro, and lychee, they may not understand what their drink will look like.
Before I concluded on designing a boba web app, I started out by thinking about beverages and drink-ordering apps in general.
I broke it down into:
- Drink data that can be visualized: ingredients, macros, price, taste
- Types of drinks: coffee, tea, smoothies, juice, alcohol, milkshakes, boba
- Common places that serve drinks: Starbucks, Jamba Juice, Ding Tea, Pressed Juicery, 85 Degrees
- Local to UC San Diego popular places that serve drinks: Camellia Road, Vitality Bowls, Art of Espresso
- Age demographics: young adults (age 18–28), adults (28–45), middle adults (45–65), elderly (65+)
Amy, Emily, and I saw the closest thing that broke layers down into drink data that could be visualized was coffee (see right). However, due to the UC San Diego demographics, boba was more popular out of the rest of the drinks that did not have as detailed of information (see left). Because of this, we decided to make a boba web app.
After deciding upon boba, I created tests to see how people chose their boba drinks. I tested 3 people each for my prototypes and documented the results.
Prototype 1: Boba Binary Trees
This first prototype was where a yes/no decision tree would make one’s drink choice.
The testers went along these tree paths:
- Light → tea → fruity → lychee
- Light → tea → normal → oolong
- Light → tea → normal → jasmine
Main like: Options were all in order to create the most optimized drink and did not have to make too many decisions.
Main dislike: There were not enough options
Interesting observation: There may be a connotation with the word “heavy”
Prototype 2: Boba Visualizer
This next prototype was where a visual would appear of the boba broken into layers of percentages of ingredients and associated macros.
For instance, Jasmine milk tea is about 60% milk which is 6g of protein and 80 calories. It has 20% boba which is 25g of carbs and 100 calories. The remaining 20% is jasmine tea, water, and sugar which is another 5g of carbs and 20 calories. Participants were given 3 options: lychee fruit tea, jasmine milk tea, and strawberry fruit tea.
Choices and reasoning
- Lychee → likes lychee
- The one with the least sugar → is careful about health
- Lychee → liked fruity drinks
Main like: Better idea of what one is consuming
Main dislike: If one already knew what they liked it would not help them make a drink decision
Experience prototyping results
All in all, there is a need for the data and breakdown of drinks like boba. I tested two methods of helping users decide drinks based on their foundations: one that tested on self-interest and one that tested drink composition. Both helped the participants out and they were quite interested in the idea of it since there is nothing specifically like it.
I created an inspiration board. It is potential foundations and ideas for the app with respect to boba and drinks broadly. I then thought of pros and “I-wish” statements about each of the inspirations.
Items and their “I wish” statements
- Build-your-own (byo) smoothie chart
+ Visualizes what ingredients can make a drink and what they serve as
— I wish there was a byo boba feature with all possible ingredients listed
- Split boba picture
+ Shows the potential for fun two-way boba drinks
— I wish one could contain one tea and the other a different then combine
- Picture of boba tea house menu
+ Accentuates the number of boba variety there is
— I wish I understood makes each drink! I only know the “normal” ones
- Top drinks and their composition
+ Shows the most popular drinks and from that, most popular ingredients
— I wish this would be applied boba shops that only have popular drinks
- Coffee composition
+ Shows the composition of coffee not obvious for someone unfamiliar
— I wish this would be applied to boba as most drinks share ingredients
- A binary tree for deciding
+ Has two routes for everything stemming from a root
— I wish this could be applied to deciding drinks as yes/no options
Best way of deciding which boba drink to order but without the right tree line it can go wrong
- Boba drinks in layers
+ Shows composition of what the colors are and how much space it takes
— I wish this would show more than color and density visuals of a drink
- Mixed drink visualization
+ This could easily substitute for boba layers based on ingredients
— I wish this was not alcohol
- Nutrition of boba
+Helps people be more conscious of what macros they are consuming
— I wish there were macro counts based on layers to show ingredients
Best idea of what should be visualized in a drink but should be improved on because it does not visualize by layer or any other type of data
- Boba layer visualization
+Visual to show live layers of boba as they are being poured
— I wish there was an illustration for each layer with more information
Storyboarding and Paper Prototyping
I created storyboards of what the potential user’s situations might have been.
We each created a visualization system for drinks and their details through paper wireframe prototyping.
Our peers evaluated our paper prototypes and gave us feedback and ideas based on pain points:
- Add user profiles for saving favorites and options based on cookies
- The evaluators were confused about what was clickable and what was not so reduce the number of boxed items
- The evaluators were not sure of how to exit certain screens so include both swipe to make the screen disappear as well as an exit icon or arrow
- There was lack of discoverability of available features so add more arrows or animation to drink layers
- Have a scroll bar appear instead of just an arrow
- Some users were overwhelmed by the display of filters to help recommend drinks so elongate the layout to be more friendly
After creating the bare bones of our application we summed up:
Point of View
Users need to know what they are consuming in order to live a more healthy and knowledgeable lifestyle. Our target user is anyone who consumes boba. They can use our app to order their drink. The core interaction allows a user to select a location, then they can either search for a drink if they already have one in mind, or use the filters to select a drink. After looking at the ingredients, they can finally make their informed decision on which drink to order. This app would like to provide users a way to see the macronutrients and visuals of their drink based on usual or new customizations.
POV: Knowing the contents of a user’s drink leads to increased satisfaction and awareness for their health.
If our design did not exist, users would estimate how many of each layer exists (i.e. tea, toppings, milk). They might find this from an online bubble tea recipe. Then they would use math to calculate the calories per macro per ingredient and choose based on estimation. This is more steps than most users would take.
We then improved the visualization system for drinks and their details based on the low-fidelity wireframes and test participant feedback.
The application is unique in that it solves a specific boba problem. Features that stand out are that this app has customizer sliders to make level adjustments that change the nutrients based on the ingredient layer. It also has a swipe down to go back feature which is rather difficult to code on mobile compared to a simple button that takes one back to the previous page. Finally, there is a swipe to select and see through different drinks, kind of like a carousel. These are fun, unique, and animated user interactions we thought differentiated us.
A user can login to the app and swipe through their favorite drinks. They can access the entire menu by tapping the all option on the upper right hand corner. Once a user selects a drink, they can see the standard nutrition facts. They can also adjust the levels of sugar, milk, and tea which will dynamically change the amount of calories, protein, fat, and carbs.
A big thing when designing and developing the app was prioritizing the features while not overcomplicating things. Rather than many user interactions we wanted modern, meaningful ones.
To test the usability of the app, we had boba-drinking participants that came from a wide range of demographics perform two tasks. The first was to create a unique drink that was customized to their taste. They started with a base drink but were asked to add different toppings to make it unique. The next task was for the user to find the greatest possible amount of carbs in grams of pineapple fruit tea.
- User is able to successfully navigate through the app with swiping. They sees that there are drinks peeking out of the edge so knows they can swipe right and left to navigate through drinks.
- User is able to successfully figure out how to get to the most amount of carbs for prompt 2 (50g) by making the drink purely sugar
- User could not figure out whether there was 10% or 100% in calories due to the interface of the clickable arrows covering the numbers
- User was not able to figure out that the sliders were clickable or even there (thought they were just levels of the drink that only adjusted based on the numeric input)
- Users had a difficult time finding the “All” drinks button on the app.
Comments and speculations
- Usually there are more constraints and less flexibility and in store you would never be able to order 100% of something except for tea.
- Although user flexibility is important, perhaps it confuses the intuitively of the ways of adjusting features.
- Due to the color matching of light colors to the sliders, when in bright lighting conditions, the bright screen colors were more difficult to see.
- The “All” buttonis a small circular button in the top right corner in a small font. It is also on a light background.
We initially asked potential testers about their lifestyle, health, and drink ordering habits. Our target demographic was a group of people who liked boba, but ranged on their familiarity with different flavors and level of health consciousness. Our recruitment process consisted of asking questions to gauge these various attributes in order to obtain our target demographic of boba drinkers.
Based off initial feedback we created two options for searching for drinks:
Option A (the search bar) allows for more user freedom in which boba places they want information from, but has a greater possibility for dissatisfaction if the user inputs a place that is not currently within the database. We thought A might turn out better because it is simpler and doesn’t have addition store locations and components to show the user. It allows them to search for whatever store they’d like without cluttering them with the boba store options they have.
Option B (the dropdown) provides the users with their possible options, but may lead them to feel confined in their choices. Although it is impossible to guarantee complete satisfaction for every user since we cannot have the drinks of every boba place, the user experience of selecting a place can be refined to lead to a better experience. We thought B might turn out better because users will be able to see the boba store options nearby just by clicking on the dropdown. It allows users to be in the know and not have to remember the boba shop they’re looking for off the top of their head or if it’s even from a different area.
x2 = (observed — expected)2 / expected
a: x2 = (26–20)2 / 20 = (6)2 / 20 = 36 / 20 = 1.8
b: x2 = (15–14)2 / 15 = (1)2 / 15 = 1 / 15 = 0.0666
p-value = 0.10
According to our data, people dramatically utilized the dropdown (B) more than the search bar (A). Both of these components served the same purpose of filtering drinks from the carousel. The search bar had the additional functionality of being able to open up the drawer for specific drinks. We suspect that people utilized the dropdown more than the search bar because the dropdown appeared to be more clickable. Additionally, the drop down immediately showed suggested options. With the search bar, one had to know what store or what drink one were planning to order. This was difficult for first time users of our application (which were the majority of the test subjects) because they were unfamiliar with what options were available to them.
Through A/B testing we have learned that users prefered to have options but not infinite choices so that they’re overwhelmed. Users like the drop down menu and being able to view all the drinks at once. Using Google Analytics, we discovered that users prefer the drop down feature that provides options, rather than typing in a specific drink and place.
We made more changes like this in order to provide options for the user without overwhelming them with freedom by combining the two types of components together. Essentially, we added a dropdown to the search bar because it allows users to have all of the functionality of the search bar while also providing recommended stores and drinks for them.
Amy and I had a lot of fun doing user testing and programmed was done solely by Emily 💙 We learned user research is the most important step because it dictates everything — from a concept to an idea to a design.