Swerve Case Study: IOS/Android App
Project Outline
Role: Product Designer
Responsibilities: User Testing, UI Design, UX Design
Company: Fictional App
Brief
Swerve is a mobile point of sales focused on simplifying a server’s job by decrease friction points and increasing accuracy and speed. Swerve is a passion project I created from my dozens of conversations talking with servers and being in the business. As always I used human-centered design to discover problems, interview users, design, test and iterate thoughtfully.
The Problem
Current POS systems are stationary and require the server to take an order at the table and input it into the system later. This decreases efficiency and increases order inaccuracy. These are both magnified during busier hours and more staff than POS machines.
After 10 in impromptu interviews with servers, I found these problems.
9/10 greatly disliked their current POS.
10/10 believed the POS was overly complicated. (AVG time to be fluent: greater than 4 shifts of six hours)
10/10 get upset/anxious when waiting behind another server inputting their order.
8/10 believed the POS effected their tip amounts due to speed/accuracy
Competitors
Toast: A tablet you can walk around with.
Revel: Stationary POS.
Shopkeep: Stationary POS with a lot of features.
Note: You’re required to purchase a POS to able to use their application
Our Solution
Create an easy to use and order efficient mobile application for servers to use at the table when taking an order.
TABLES:
At a glance, the server can see all of the assigned tables and seated tabled tables. Due to the need to move quickly, we made each assigned table a tab with the order connected. Making adding a change to an order one tap a way at all times.
Search: Left
Current POS systems are hard to understand and utilize category levels to locate menu items. This screen was created to feel mobile native allowing any user to pick it up and find what they needed quickly through typing or alphabetically scrolling.
Modifications: Right
Orders can be complicated and require on the fly changes. Modifications make it easy to add or subtract ingredients and if needed make a preparation note
Tipping:
Order efficiency and accuracy are the two root problems that needed to be addressed. When addressing them correctly we will end up with the desired outcome for a server, better tips. This screen was created to encourage patrons to tip appropriately to their service given.
Note: The percentage is arbitrary and would need testing to better calculate percent margins that would feel fair to both parties.
Metrics for Success
- First time user of ‘Swerve’ input a complicated order faster than an experienced user on a current POS.
- Increase accuracy by greater than 10%
- Increase average tipping by 5%
The Results
Currently, haven’t had the opportunity to test. Further testing will continue in the near future.
What I learned
This was the first project I got to use the “Jobs to be done” framework and I really enjoyed it. Focusing on the outcome for the user rather the problem or potential features made it easier to stay focused on the objective.
I am still learning on how to test prototypes and this has been a particularly difficult one. I am going to continue to research better practices and steps to create better prototypes and testing them better.
Current resources I am using to Grow:
Learn UX by Jeff Gothelf
Sprint by Jake Knapp
Product Breakfast Club Podcast
The Process
Where the idea came from, the people I spoke with, and the rationale I used.
A short story
Back in 2010, some super brilliant dudes by the names of Jack Dorsey and Jim McKelvey created a little startup called Square. You might have heard of it. They made a convenient accessory that was powered by a smartphone and changed the merchant service game forever. The only thing is, it only changed it for retail; what about the restaurant industry?
My Idea
Let’s remove all of the unnecessary pieces: registers, tablets, stands, cases, printers, and cords (2019, the year of getting rid of cords, I hope). I want to create a phone application that is robust enough for a multitude of restaurants to adopt but simple enough to make taking orders quick and effortless. Plug a Square into the phone and you’re good to go!
The reason for using a smartphone is to decrease the financial barrier of entry by utilizing the staff’s smartphones. Secondly, I believe that a familiar-feeling device will increase the fluidity in which a server works due to their familiarity with their own device. Lastly, there won’t be any more lines waiting to use a terminal. During a rush, servers usually bunch up and rush each other to get their orders put in, and this is can cause order inaccuracy and friction between team members.
Project Deliverables
-A list of assumptions that can be tested and validated
- A few screens to showcase the UI and better communicate the idea
- Strong Rationale for my design decisions
- Platforms: iOS & Android
Understanding the Project
Before I jump right in, let’s outline some important information.
The Project
For the scope of this project, I will be focusing on waitstaff and their touch points. My solutions should impact their day-to-day in a positive manner. I want to solve the realistic frictions created by outdated products and show empathy for every aspect of a server’s job. Although I know that friction comes from many areas (other staff members, management, and customers) I want to start by dialing into the two primary procedures a server needs to complete. Taking orders and payment.
My Environment
To make this project feel even more real I am going to identify myself as a solo product designer in a small fictitious startup. It is comprised of two developers, a marketer, and business leader. Being a small startup there is a limited runway and a ton to do so I need to create ROI positive work that doesn’t drown the developers and makes cost-effective moves in testing.
Let’s Dig in!
Empathize
Human Conversations:
Throughout the last few months, I have spoken to dozens of restaurant servers, hosts, and owners and asked them about their personal feelings toward their POS systems. Mind you, this is while I am paying for my food and never during a rush. Everything feels pretty chill and organic.
Question: “So what do you think of your Point of Sale?”
Common Answer: *Long Sigh*… It’s pretty good.
Follow Up Question: “Doesn’t sound like it, tell me about it.”
AVG Answer 1: “It’s clunky, a lot of features I couldn’t understand until someone showed me and even then it’s still easy to forget.”
AVG Answer 2: “It’s slow, I need something that can keep up with the chaos.”
Last Question: “What do you like about the Point of Sale?”
Answer 1: “It gets the job done.”
Answer 2: “It has a lot of features so I never worry if it can’t do something I need.”
Note: Looking back at these questions I could have composed them better. Going to continue to learn more about user interviews so I can ensure the information I get back isn’t due to me leading it.
Synthesizing
From the dozen or so of people I had spoken to not many were happy with their POS. In fact, it felt more like they had become complacent. Almost as if they had dealt with so many different systems that by this point I’m not sure they believed that a good system could exist. (Just a feeling I got.)
Some showed their appreciation for how robust the system was but that it was often a stumbling block. Lastly, no one was happy with the speed. To accomplish common tasks it took a dozen steps and most of those steps were not obvious. In some cases, people needed 1 to 2 days of training on how to use the POS. To top it off sometimes management would add/remove items and this would result in some newfound chaos.
Priority Needs
1. A system that is simple and straight-forward. (Very little practice)
2. A system with enough depth to solve common problems.
3. Taking payment via a card reader (Square, PayPal, etc…) and the ability for customers to add a quality tip.
Ideation
To better understand what I need to wireframe I will need to create a list of small needs (the smaller pieces needed to solve the priority problems)
Task Needs: The Actions needed to achieve the server’s outcome
- See assigned tables
- Add requested menu
- Find requested items quickly
- Modify requested items to fit the need of the customer (add/remove)
- Add or sub a side dish
- Take payment (card, cash, gift card)
- Split checks appropriately
- Add discounts
- Receive a tip for the service
- Give Receipts (email / text)
Action Map:
These are the actions that need to be taken to complete an order.
Wire-framing & Mapping
Using the information above, I start to wireframe my ideas until things started to click. Once I had all of my ideas on paper they were sorted into MVP or bloat. Bloated ideas were cataloged and kept while the MVP ideas were ideated on.
Better Mapping
I have a pretty good idea on how I believe this application will work, but I want to refine the steps and simplify as much as possible.
Side Note
I know there are other pieces that are needed to make this application work at its full potential. I believe having an app on the host’s phone to seat tables, keep a queue, and notify serves of being sat is very helpful. I also worry about how an application would look/work for a cook. Considering the environment a cook works in they really can’t be looking at a phone. This will possibly be addressed at another time — moving on.
Design & Prototype
Pixel-pushing time! This is where I feel most of the problems will really be shown with my solutions. You can stare at an artboard on Sketch for hours and it feels right but once you see it being used by another person is when you’ll see the true flaws.
Mod Screen:
The purpose of this screen is to allow for a complicated order to be accepted and charged appropriately. Say your customer orders the bacon cheeseburger but wants extra bacon, mushrooms, and avocado but doesn’t want the onions and mustard, cooked medium with ranch dressing on the side. Currently, I have designed it with tags; but that would be a huge pain to set up. Considering that I need to be mindful of barriers, I need to reduce that workload.
Possible Problems (Outside of design)
A friend of mine pointed out that the application would have to be very mindful of the battery power it uses. Wait staff can be on the clock for 10 hours straight so what happens when their battery dies on their phone?
Another interesting problem is when a customer is signing the receipt if they drop/hurt/break the server’s phone? Maybe insurance? Who knows…
