Creator is a hamburger restaurant startup that is centered around 2 extremely beautiful and complex robots that make hamburgers.
I was tasked with creating software that staff would use to manage the restaurant during service, and creating process and systems to create the foundation for a growing product and team.
This involved a suite of apps including:
The creator restaurant, Folsom St. San Francisco.
I needed to go and feel the Creator restaurant experience for myself - and understand how the data from a robotic-powered restaurant can create unique dining experiences. Some questions I asked myself were, how that data can be used to design the most efficient foodservice operation for guests and staff. What software do we need? How do we support a growing product team? How do we plan for 100 restaurants?
The goal was to design and build a stable restaurant management app and continuously add features to improve the restaurant experience for guest and staff.
To understand the restaurant its necessary to be in the restaurant, watch service, take notes, and ask questions. I created a process of observing and questioning staff repeatedly during the research phase for each feature. I regularly interviewed the restaurant manager, restaurant staff, product teams, and stakeholders to get their feedback and input.
It was also essential to create a process to document and share the information learned from this research.
Research observations - Observe staff, managers, and guest in a real-time restaurant service. Interview them with questions from my observations.
The process of staff interviews began with observing. I would choose a station (fry cook) and observe them during service. As I watched, questions would come up that I'd write down. A whole series of questions about different tasks, the tools they used, the different amounts of ingredients. These would form the basis of the formal staff interviews. Because of our proximity during observations - as things came up, the staff members could mention and show me in real time their issues. This process was incredibly helpful.
User journey maps are incredibly helpful and can be used to map all sorts of product aspects to a users flow. I was able to create specific user journey maps for the main tasks for each of the positions in the restaurant. I mapped user satisfaction across each step of their flows to see where we had issues and where things were working well. From this, I was able to identify areas of opportunity and tackle specific problem areas as significant pain points.
I also mapped employee interaction, customer interaction, and devices to the map to help identify other areas of opportunity. This information was critical in designing the information architecture for the restaurant service app.
I used the Kano method to gain a better understanding of our product. We needed to understand where we should apply resources. Kano lets us track whether a feature is a must-have or is seen as an exciter feature that adds delight to the product. This method helps us understand the status of the particular function and the approximate effort to complete it. Kano is especially helpful in prioritizing what work to do.
As I began the information architecture for the app, I interviewed staff members again. This time I created a series of cards that represented the different sections of the app. I asked the staff members to organize them as they felt made the most sense. This is a great way to make sure we were organizing all app functionality into the most understandable way to our staff.
What are the different jobs in the restaurant? What info do they need to excel at those jobs? We have a Manager, Burger Runner, Bartender, Order Assembler, and Fry cook. Each of these jobs requires unique information and experience to achieve success.
First, I take each of our user types and dive deeper. What specific tasks are necessary for each, how do they interact with their environment, the robots, the guests, other staff, etc.?
User Personas underlay most of our product design process. Without understanding our users, we can't design our products effectively.
Research artifact - understanding different staff user needs.
Research artifact - decision tree for all order types.
Research observations - observing the fry cook in action.
Research observations - observe staff setting up restaurant for service.
The information we gathered during observations and interviews and other UX processes allowed me to form some conclusions about the staff and their tasks. Using this information, I created an initial design and created a prototype that would enable us to do user testing and get feedback. This process was repeated for each user and each major task.
A prototype of the Liver Burger Tracker view. Allowing staff to address issues on the robot.
Because we had the luxury of company employees being our users, I interacted with them daily. Involving them in the process of designing the app not only gets us a better app; it created unity amongst employees and a shared vision for the app and restaurant. These are perhaps just as valuable as the product learning gained from these exercises.
The physical space and timing of orders turned out to be the most significant factors in creating an order management system. This information, combined with our user information allowed me to create detailed wireframes to validate our UX thinking further.
Wireframing and simple click-through prototyping in Sketch.
The Live-Tracker view allowed staff to address robot issues very quickly.
Staff manage orders as they come through.
I started working with the Creator product team when they were just transitioning from a small team to a growing team. We sat down and worked out how we thought the product team should work. We set up JIRA, using the dual-track scrum method. We had daily standups, We documented in Confluence and, we had a weekly design review.
The importance of a clean handoff to engineering teams and a good working relationship is fundamental to product success. One of my goals at Creator was to create the process for their team to grow and set the foundation for their creative team's process.
I used FramerX to generate active components, create prototypes with these components, and handoff React components with exact CSS and animations defined.
FramerX allows the import of JSON files to populate designs with real info. We could export a JSON file that represented everything that happened in the restaurant during service. Our goal was to use this feature to create moving prototypes with real info that could then be used to test new UI components in a near-live scenario.
Screenshot of FramerX and the button component screen. All components are live, clickable components for easy prototyping and handoff to engineering.
The research I did and the data provided by the robots allowed us to do things that no other food service apps have done. We, therefore, applied for a design patent based on my work on the fry cook interface based on the use of robot data in the interface for food production.
To measure our results:
Throughout the project, we were able to design and build a stable product. We improved restaurant operations drastically as we added new features for staff, freeing them up to help guests and create a better restaurant experience. We saw a decline in bad reviews, a steady decrease in refires and other customer issues and, a steady increase in customers served.