UI/UX Case Study: Capitol Factory Coffee

The Omni Hotel in downtown Austin is a center for professionals who are visiting and those who work in Capitol Factory, a startup hub, located on the 15th floor. Although their offices have basic coffee, employees frequent Peet’s in the lobby to satisfy their more refined tastes.

“Three people cheering with iced coffee and lattes at Verve Coffee” by Nathan Dumlao on Unsplash

Concept

A new feature of the Omni Hotel app lets users order coffee from the selective menu of Peet’s coffee in the lobby. Employees can order using their unique employee ID and guests can charge to their room.

User Analysis

First I observe the flow of customers and record every piece of data I can gather about them. Some of the information is facts: how much they spend, the time of the total transaction, whether they pay with credit card or cash. Other data is assumptions I make: are they an employee of the hotel, guests or employees of Capitol Factory, whether they were familiar with the menu/baristas.

Trends begin to emerge:

• employees of Capitol Factory holding a phone and a wallet
• spend a maximum $5.00
• familiar with menu
• familiar with barista
• in a hurry — average transaction time of 2 minutes
• doesn’t want paper receipt

Journey

Meet Kate, a Product Manager of a busy startup in Capitol Factory. Follow along as she becomes the master of her caffeinated destiny:

1. User is sitting at her desk and thinks, “I need coffee”
2. She navigates to her Omni Hotel app
3. Types her unique employee ID
4. User chooses the size of her drink
5. types “Macchiato” to complete her order
6. Realizing she doesn’t have time to go downstairs, she shares her order with her assistant
7. Downstairs, her assistant scans the QR code that was sent to her to complete the transaction

empathy map

Prototyping

The paper prototype, assembled in Marvel, proves to be problematic for the users. More information about the buttons is needed to complete the task.

What I Learn From User Testing

I ask users to complete the simple task of ordering a medium Macchiato. In my prototype, I purposely omit labels for buttons. I’m trying to understand if users would naturally flow through the app based on experiences with similar products. My conclusion is no.

Here are some takeaways:

• Users do assume the blue button would let them submit the order after typing. However, it makes the return key confusing. I would omit the blue button altogether and rename the return key to “GO” and allow it to function as submit.
• The red button doesn’t feel like a checkout button — change the color.
• Although the mail icon should be a way to email a receipt, users assume they can email the order
• Users are unclear what the share icon would let them do

In Retrospect

Although it is a short project to demonstrate the basic concepts of user research and design, there are some lessons to learn. Notably, time management. I spend too much time gathering data which limits my opportunity to synthesize. In designing my first iteration I spend too much time making it perfect before I have any information about it. This makes redesigning impossible.

I am ahead of myself in attempting to test with little direction. In a low fidelity prototype, users won’t always understand my design choices — there is not enough information. If the goal is to see if they can achieve a given task, give them the tools they need to make that happen. The sleekness of the design will come later.

After completing the project using paper prototyping, I understand the value in modern tools like sketch. Speed and readability are essential.