Jordan Scavo
A prototype for a stylized boba shop kiosk that allows the customer to
Boba shops have gained a lot of popularity in the US within the past decade, largely in part due to East Asian media becoming more mainstream among the population. While some of these shops have patrons come to the counter to give their order to an employee, some boba shops are trying out a different model: the self-service kiosk. Self-service kiosks are becoming a wildly popular option not just for the restaurants, but also for the customers. People are increasingly opting for ordering options that don’t require social interaction, whether that be due to COVID-19 safety, social anxiety, time constraints, or browsing convenience. Regardless of the reasons, though, there is a burgeoning demand for self-service kiosks in settings like boba shops.
With our project, we wanted to take an approach that other self-service kiosks have not yet considered. We wanted there to be a visual reflection of the customizations on the items being customized to show the user what their drink will look like. This is what our prototype, Tapioca Tech, addresses in its design.
As the team lead, I had unique responsibilities throughout the course of the project. For example, I guided our team’s weekly meetings and created agendas of what we would be accomplishing. I was also responsible for scheduling and making sure any meetings outside of class time worked for all of the group. Furthermore, as we got into the nitty gritty of prototyping, I delegated tasks so everyone would get a fair share of work.
In the Research Phase of GDD, the design team gathers project expectations from stakeholders, does research on the current market for the intended product, and learns potential users’ goals, values, and issues. The overall aim of this phase is to build a foundation upon which the design team can form personas.
The Research stage consists of six steps: the kickoff meeting, literature review, competitive audit, stakeholder interviews, subject matter expert (SME) interviews, and user interviews. For the sake of time, our team bypassed the stakeholder and SME interviews.
If this were a real business project, the team would start with a kickoff meeting with the stakeholders who would introduce the design team to the project and inform them of the goals and requirements they have. However, since this was a school project, we simply simulated this step by discussing what our stakeholders might expect. We imagined that a boba shop called Koala Tea hired us to create an ordering kiosk. From there, we developed a problem statement and a persona hypothesis, pictured below. We believed that we would have one main type of user: the boba enjoyer.
The next step would be the lit review, where the design team would research information that relates to the future product or whatever domain it is in. Doing this helps us as designers to better understand the context of our product. Our team found 5 scholarly articles about the domain of the self-service kiosk, summarized the content, and detailed its relevance to our project in the following images.
Next was the competitive audit, where we evaluate our competitors’ products and their features. This step is important to the GDD process because it provides context for the designers to see what features work (or don’t work) in preexisting apps. For our competitive audit, we created a chart that displays the positive and negative features of the competitors.
The final portion of the Research phase involves user interviews. Interviewing potential users is essential to GDD because it allows the designers to see what their intended user base’s goals are. From there, they can design the product around helping the user reach their goals.
We interviewed five people who in some way fit the criteria of our target users we identified in the persona hypothesis. Our team held the interviews online using Microsoft Teams. In each interview, one group member moderated (asked questions) and the other four facilitated (took notes). We rotated the role of moderator so everyone would get a chance to lead an interview.
Immediately after each interview took place, our design team gathered on a virtual whiteboard (Figjam) and did affinity mapping based on our notes. We individually wrote virtual sticky notes and then discussed while placing alike sticky notes together on the board. Some of the sticky notes didn't end up making the cut because there weren't several that could be grouped together. For the sake of visibility, these have been omitted from the photos of the affinity maps below.
From here, our design team moved on to the Modeling phase, where we would analyze our findings and formulate a persona based off of major user behaviors we identified.
After concluding the Research phase, we moved on to the Modeling phase. We started by identifying major behavioral variables we noticed during user interviews and then placing each participant on a scale based on their behaviors and opinions. Several of these scales gave our team great insight into what we focused on in our prototype, like prioritizing customization and giving users the ability to both browse broadly and within specific categories.
Once we identified the major behaviors of our user base, we created our primary persona, who is the hypothetical user that we will focus on designing our product for. We based this persona’s demographic traits and goals on the behavioral patterns from the previous step.
The following stage is the Requirements phase. We used the persona we created to develop a context scenario, or a fictitious “day-in-the-life” story of our user. This is an important step because it brings our persona to life and allows the designers to more fully flesh out the persona’s needs and goals.
Building off of our context scenario, we formulated a list of required features that would fulfill our persona’s needs. Requirements are paramount because they inform how the Frameworks phase will play out. Below are the context scenario and finalized list of requirements.
Once we identified the requirements of our persona, we moved into the Frameworks phase of the project. At this point, our team created a wireframe, or a “rough-draft” of the screens of our kiosk app. This wireframe shows paths the user could take, whether they be key path scenarios or validation scenarios.
Key path scenarios are the typical path the primary persona would take on the application, whereas validation scenarios are additional possible paths.
The last step in the process was Refinement. It consists of two major steps: prototyping and usability testing. Prototyping is essential because it is the final product of the design phase that will then be translated into an actual coded app.
We started by developing a clear visual style for the app based on typical styles used for boba shops. We chose some colors to represent the Koala Tea brand as well as typography that could be used throughout.
Referencing our wireframes, our team used Figma to prototype our application. Mekayla and I, being in charge of the individual product pages, also used advanced prototyping techniques to make certain functions more fleshed out, like price calculation and adding items to the cart.
We used the new Figma functionalities and variables in order to accomplish a more high-fidelity feel, such as expressions, conditionals, and Boolean properties. The following is an example of the interactions we attached to buttons like the add to cart button so it would update the prototype accordingly.
We finished the Refinement phase by conducting two usability tests to see how our prototype worked. The tests were administered online on Microsoft Teams so we could view the participant’s screen while they navigated the app. They talked through their thought process which allowed us to see where they hit snags or got confused. After the tests, we fixed any errors and streamlined the prototype into the final product.
As we went through, things did not always go the way we expected, but we persevered. One important thing to note is that some of the advanced prototyping we included relies on Figma features that are still in beta, so they don’t always work properly. However, to the best of our ability, our team came up with solutions to get around this, creating a sophisticated and high-fidelity prototype that we can all be proud of.
