Project Overview:
Our application, Tips, seeks to assist newly-employed baristas in learning on-the-job skills and onboarding quickly. With step-by-step guides and quick help features, the baristas in training will use the wear interface of the application to become more autonomous and learn to make numerous drinks, all in a shorter amount of time. Additionally, the mobile side will be used by managers or experienced baristas to customize the tutorials that will help the new employees succeed. Together, our application will streamline the transfer of knowledge from experienced cafe employees to those less so.
Brainstorming Process:
When we first started on this project, we were geared towards helping the restaurant space. We recognized that the food and drink industry had huge potential for integrating new technologies, specifically wearable technology. Many people now possess wearables, but restaurants and cafes are traditionally people-driven and shy away from new technology. So to have a successful idea in this space, we needed to tackle a problem that can be helped by wearable technology, while also not disrupting the system already in place.
Our first idea was to build a wearable app that would benefit waiters in particular, allowing them to keep track of which tables they are managing and reminding them when to check up on guests, to increase overall customer satisfaction. Upon interviewing waiters and managers, we quickly found out that the initial idea wouldn’t be optimal, since a waiter’s job is in fact to keep track of their own guests without the aid of anyone else, let alone a wearable app. Experienced waiters were also already accustomed to their way of interacting on the job, and introducing a new technology would most likely slow them down. We did, however, learn that the average time it takes for new waiters and baristas to learn on-the-job tasks is about 2-3 weeks. The process involves shadowing a more experienced employee and after that, simply learning on the fly. We felt the current system was cumbersome for experienced employees and the time for training could be shortened.
To address these issues, we narrowed our focus from food service workers to newly hired baristas, who are still learning the basics of the job. Our new idea shifted to helping these new baristas quickly learn how to do their job, be it making drinks for customers or finding supplies to restock.
Design Iteration: see all iteration in a pdf | flowchart pdf
Our initial designs focused very heavily on the mobile side as a tool for managers to monitor and aid new baristas. We kept the watch interface that the baristas use extremely simple- to the point where it actually lacked basic functionality. We also initially picked a brown-tan color scheme to fit the theme of a coffee shop. We quickly realized that since our app depends heavily on list views and a lot of text, the brown and tan colors made it a little hard to read. Initial feedback also let us know that we had way too much text in our app.
We then switched to a very clean teal and white color scheme for legibility. We also started to shift focus away from the mobile side, and started adding a lot more functionality to the watch, as the baristas-in-training were our target users for this app. Such changes include moving the “locate” and “restock” functionalities from the phone to the watch, as well as the ability to call for the manager from the watch.
Our final design iteration cut down even more on text and included pictures and animations to help give visual cues. We added a lot more information to the recipe view- including dots at the bottom indicating what step the user is on and the total number of steps. We also included the ability to go back recipe list at any point in a recipe. We also changed “going to the next step” from tapping/swiping the screen to shaking the watch, as baristas are often using both their hands to do things. The recipe list menu on the watch was originally a singular list that displayed one item per screen with arrows to go back and forth between items. Realizing just how large restaurant menus can be, we switched to a scrollable (swipeable) list view that is much easier and faster to navigate. Our final design has a lot more going on on the screen, but it’s all necessary functionality and information that got neglected in our original designs.
Competitive Analysis:
When looking into our competitive landscape, we found several applications that handled the recipe or step-by-step aspect that we had also planned to cover. Applications, such as BaristaMe and Spro, had very detailed visualization and information for recipes and tools one might use. However, this in-depth and verbose knowledge doesn’t fit the bill for onboarding baristas, who need quick and concise instructions they can memorize when on the job as there isn’t as much freedom in time. Furthermore, our competitors catered to those who wished to make drinks at home, which didn’t quite capture the busy and bustling environment cafes could have. While our application may not have as detailed visualizations or information, it is the tradeoff we made to accommodate the pain point of the vast amount of recipes baristas are required to remember. As well, our app is set apart from our competitors because of our specific user group; the other features that make up Tips cater specifically to the job and helping new employees ramp up more quickly, which none of the competitor applications can service.
Wireframes (InvisionApp)
We started off with low-fi sketches, then moved onto InvisionApp to work on our wireframes (figuring out the layout and transitions of our screens). From there, we started mocking up high-fi prototypes with Framer Studio (before starting on our final product in Android Studio, where we continued to iterate on designs from users/peer feedbacks). For more details on exact changes, refer to design iteration section. Attached below is some rough low-fi sketches and links to our wireframes + code to our high-fi prototypes.
Low-fi Sketches (note: couldn't embed images b/c of hackster update)
InvisionApp
Initial phone prototype: https://invis.io/AC58JLHJ6
User-testing watch prototype: https://invis.io/GZ4Z3R467
Framer Code (dropbox code download)
Personas:
From interviews and observations, we created three personas, one for the mobile and two for the wear, but focused more so on the latter as this was where our user group truly laid. Our mobile person was a manager, Pete, around his 40s, who mainly handled the logistics of the cafe. Although not very technology savvy, his goal is to run the cafe as smoothly and optimally as possible (i.e. quickly filling orders, happy customers, no accidents, etc.). He would rather not use new technology, but if it would increase the customer pool or help his employees provide better or more profitable/valuable service, he would prefer something straightforward to use and easy to integrate.
Our second persona is a new barista, Jill, working part time and enrolled in classes. She has worked at a local cafe before, and is works a job as a barista to earn a little more cash for school. While learning to make drinks may not be her largest pain point, Jill is still unfamiliar with the layout of the new cafe, especially since this one has a bunch of fancy new machines. Under the stress of school and work, Jill gets flustered when people get angry or machines do not work correctly. However, she is a quick learner and is pretty tech savvy
Finally, our last persona is also a new barista, Bill, a guy with no experience working at a cafe before. He is in his mid 20s, unsure what to do but would like to move up in the ranks if possible. He wants to pick up things quickly and has a hard time asking for help at times. However, Bill has never made a majority of the complex drinks served at cafes and often needs a lot of help. He is willing to learn and hopes to prove himself to his employer and provide the customers with good service
Scenarios:
We created a few scenarios to imagine and illustrate our application in a real-use context. These were particularly useful in our first iterations of our prototype when we were unable to do as in-depth user studies by allowing us to envision the app in action. From these studies we were able to make a few tweaks when we thought things might go wrong, and think of potential other issues that might arise. A few of our scenarios from previous iterations are outlined in the following.
The holidays are approaching and a small cafe located in the town square is rolling out their specials for the holiday. They three drinks they bring out for the holiday are well known and well liked by the town. Pete, the local manager, is aware of this trend, and would like to make sure all of his employees, especially his new ones, know how to make these particular drinks. But instead of using time outside of open hours or have the new employees shadow their experienced counterparts, he has decided to try Tips. He opens his smartphone to the application and taps through the menu to drinks, and adds ‘Holiday Specials’ to the existing categories. Once created, Pete taps into that and adds his first drink. He keeps the steps to a minimal amount of text, and when done, saves the recipe. This flow continues for the next two drinks, and then, once all is saved, Pete knows that the new drinks will be available for his employees.
Jill, one of Pete’s new employees, has never made Rosemary Ginger Molasses Latte. However, she quickly turns to her watch, and follows the flow from drinks, to Holiday Specials, to the requested refreshment. She sees the first step is whip milk, and grabs the necessary ingredient. As she is whipping the milk, Jill taps the next arrow to proceed to the next step. She sees the words ginger combined with the pouring animation, and understands next she must add the ginger molasses syrup. Tapping again, she follows the rest of the steps quickly and orderly, moving around her peer employees and finishing up the drink with a small design of latte art. As she sets the drink on the counter and calls the name of the customer, she easily taps the home icon and is directed back to the main menu for the next order.
Bill, a new employee at the mall’s Starbucks, is working the register with a long line waiting for him. Although him and another employee are manning two of the registers, the customers often look disgruntled when they order, laden with their bags or children. Bill is trying to punch in the requested drink for a customer when suddenly the screen goes black. He fumbles to try and reset the order, but accidentally adds two orders of the requested drink instead of one. The man he is trying to ring up looks agitated with his folly and is demanding why this is taking so long, which makes him nervous, and his fellow employee has hands busy making a drink. He isn’t sure what to do, so discreetly pulls up the Tips app on his watch, and taps the help icon. Bill briefly taps yes to confirm and tells the customer the manager will be with them shortly to smooth out the issue. The manager comes immediately, settles the issue with the register and customer, and the day proceeds.
User Studies:
Our user studies were particularly critical in our iterations of design and function of our application.
Our user testing was especially helpful in refining our application. We did a wizard-of-oz type study with two baristas from Qualcomm Cafe, one experienced barista and one new barista. They both walked through our prototypes with three main tasks, and we gauged their reactions as well as their verbal responses to the interface. Particularly, they pointed out what made sense and what did not, or what did not seem useful and what could be. The feedback from these users significantly impacted our design modifications. Although we are the designers and not the user, we measure the success of our design by satisfaction our target users. The only way to reach this goal is by changing our app to fit the needs of these target users.
Technical Challenges:
During the implementation of our application we faced a number of technical issues with our Android code and our hardware, which affected our implementation and design.
One of the main issues we faced was image uploading and hosting on the Rails server we initiated. Since the retrieving and rendering numerous images would be a heavy computational load on both mobile and wear interfaces, we needed to reconsider the way we incorporated visual elements. We solved the problem by having a preset list of animations that would illustrate actions for a given instructions. We parsed the list of steps looking for a set of keywords,which we would associate with our preset animations.
Another challenge we faced was with the wearable accelerometer. To move between steps in a recipe, we defined a specific shake gesture. We spent a lot of time fine-tuning the acceleration thresholds for the different axes. Since each accelerometer has an inherent sensitivity and bias factor, we needed to find these values and adjust our threshold values accordingly. In addition, we considered all the other shaking motions a barista would make when making drinks and ensured there was no transition to the next step of the recipe.
Final Product Design:
The final product is a multi-featured app that aids new baristas in the entire onboarding process. As previously discussed, the main feature is the step-by-step recipe guide on the wearable, which can be navigated by shaking motions. Recipes can be selected by tapping through the hierarchy of drink types, as shown (once again) below.
Once a drink is selected, the steps appear one at a time, along with a designated animation. Shaking will trigger the next step.
If the barista needs to contact the manager, they can do so simply by tapping the alert (!) icon next to the home button. This will pop up a confirmation page (giving user control and freedom to exit in case user accidentally tapped the icon); upon selecting yes on the confirmation activity, the wear sends a notification to the mobile and the manager will be notified that the barista is in need of assistance.
We have also included a feature for supplies. In the main menu, the barista can navigate to supplies, locate the necessary supply, and select either to restock the supply or locate it. Selecting “restock” will send a notification to the manager telling them that the supply needs to be restocked. Selecting “locate” will show a step-by-step guide (similar to making a drink) to finding that particular supply (in storage/inventory).
The manager can provide these custom recipes and supply locations on the mobile app, which communicates directly with our database.
Our database is a Ruby on Rails server hosted on DigitalOcean, as seen below. The database consists of simple tables, corresponding to each item in the main menu (Drinks, Supplies).
Summary:
This project definitely helped us learn effective design principles and how to translate our scenarios to our design. In the end, we had an app that was effectively able to transfer knowledge from a more experienced employee to a new, which was our initial goal. By reaching out to target users and iterating over our design, we were able to create a viable product that worked within the limitations of issues like screen space and memory.
Although our product is not perfect, it gave us insight into how the food and drink industry could be aided by integrating technology,specifically wearable technology. Although various mobile apps exist to aid people in cooking or making drinks, they do not translate well to the restaurant and cafe space, as employees generally do not have access to their phones. Tips takes a novel by catering to the more niche user of a barista. It is not just a recipe app translated to the watch; it focuses on tasks performed on the job. By keeping the steps for a recipe concise and making it easy for an employee to contact a manager, our app allows baristas to work efficiently and learn quickly.
Final Presentation: pdf | google slides
Comments