Year: 2018-2019

Role: Design Lead

Plus: Austin Marticorena

Methods: User Flows, Site Flows, Low Fidelity Wireframes, User Testing, User Interviews, Project Planning, Discussion Guides

Year: 2018-2019

Role: Design Lead

Plus: Austin Marticorena

Methods: User Flows, Site Flows, Low Fidelity Wireframes, User Testing, User Interviews, Project Planning, Discussion Guides

Overview

It's 6:42pm. You just got home. Traffic was normal, muted, and painful. You're starving. You need to finish some work. You turn the grab the remote, turn on the television and in the seconds before the Apple TV boots up...you decide to order Thai food.

Overview

It's 6:42pm. You just got home. Traffic was normal, muted, and painful. You're starving. You need to finish some work. You turn the grab the remote, turn on the television and in the seconds before the Apple TV boots up...you decide to order Thai food.

Who are they? What do they do for a living?  How old are they?  Describe a typical day when they use your product. Are they at home? Or at work? What time is it? Delivery? Carryout? Do they have a “go-to” spot? What kind of device are they using? Describe the room that they were in...

Knowing your users is the first step to knowing what to design. Sure we have intuition and design sensibilities. Sure maybe our product managers have years of uncategorized, domain knowledge up their sleeves...but who at your company can tell me what percentage of people order more than 1 item? Or what's a typical bag size? Do customers care what app they're ordering on? 

Some of these answers are based on quantity and some of them based on quality. It's the combination of those two that makes a good product design decision. UX research and usability testing can mostly get you qualitative data. Event tracking and having a good data analyst gets you the quant.

What we did at ChowNow was preface our tests with a lot of these qualitative type questions. If anything, it gave us a small generalization of the makeup of the online ordering space.

Who are they? What do they do for a living?  How old are they?  Describe a typical day when they use your product. Are they at home? Or at work? What time is it? Delivery? Carryout? Do they have a “go-to” spot? What kind of device are they using? Describe the room that they were in...

Knowing your users is the first step to knowing what to design. Sure we have intuition and design sensibilities. Sure maybe our product managers have years of uncategorized, domain knowledge up their sleeves...but who at your company can tell me what percentage of people order more than 1 item? Or what's a typical bag size? Do customers care what app they're ordering on? 

Some of these answers are based on quantity and some of them based on quality. It's the combination of those two that makes a good product design decision. UX research and usability testing can mostly get you qualitative data. Event tracking and having a good data analyst gets you the quant.

What we did at ChowNow was preface our tests with a lot of these qualitative type questions. If anything, it gave us a small generalization of the makeup of the online ordering space.

Don't ask a lot of your users before they get to the thing they want to do. We eliminated 3 unnecessary steps before a user gets to a menu. 

Don't ask a lot of your users before they get to the thing they want to do. We eliminated 3 unnecessary steps before a user gets to a menu. 

Say that ten times fast. Ok. Great. Now, back to the tale.

When I got to ChowNow there was a void  in UX. No task script, no equipment, no user list to pull from, no software to test with. So what do we do when starting from ground zero? Number one, order equipment: cameras, mounts, cables, software. Number two, determine what you want to test. Number three, write a task-based script ( this is good for the very beginning when you want to test certain scenarios ). Number four, gather some people . 

Number four was the hardest. People are fickle. Gathering 5-10 participants for a UX test... not the most exciting event. So you have to pay people. We decided to approach some internal ( see colleagues ) participants first. These people were cheap ( free ) and felt an obligation to help the company. We tested all the newly orientated hires in their first week...before they got jaded or knew the product too well . Gathering external participants was harder but we did it by using our contacts in the design community and tricking convincing local college students that it would be educational and fun.  All in all, we ran our test pilot through 30+ participants in 8 months and made perhaps 10-12 improvements across mobile and desktop. Those improvements saved users time and increased conversion rates by close to 9% overall across mobile and desktop.

Say that ten times fast. Ok. Great. Now, back to the tale.

When I got to ChowNow there was a void  in UX. No task script, no equipment, no user list to pull from, no software to test with. So what do we do when starting from ground zero? Number one, order equipment: cameras, mounts, cables, software. Number two, determine what you want to test. Number three, write a task-based script ( this is good for the very beginning when you want to test certain scenarios ). Number four, gather some people . 

Number four was the hardest. People are fickle. Gathering 5-10 participants for a UX test... not the most exciting event. So you have to pay people. We decided to approach some internal ( see colleagues ) participants first. These people were cheap ( free ) and felt an obligation to help the company. We tested all the newly orientated hires in their first week...before they got jaded or knew the product too well . Gathering external participants was harder but we did it by using our contacts in the design community and tricking convincing local college students that it would be educational and fun.  All in all, we ran our test pilot through 30+ participants in 8 months and made perhaps 10-12 improvements across mobile and desktop. Those improvements saved users time and increased conversion rates by close to 9% overall across mobile and desktop.

1. No one has a vested interest in what food app they order from. Most people are just looking for the cheapest price or a place they are used to.
2. People are creatures of habit and locality. You order mostly from the same few places around your house or work. Though those habits may differ...delivery if at work, pick up if at home, etc.
   
3. Don't ask a lot of your users before they get to the thing they want to do. We eliminated 3 steps before a user gets to a menu. This allowed the user to see the menu and then decide when they wanted to order. Conversely, it also led them to bounce faster when they didn't see what they wanted. 
4. Food ordering is a simple activity. It's singular and shallow. There are no other steps outside of putting an item in your bag and hitting the checkout button. ( This is not related to market place apps, but solely ordering food). Users generally don't care too much about hours or seeing their "bag" or other features that are not related to helping them order or decide what to order. Hunger is a need more than a desire.
5. Just put the "edit" button. Sure users can discover how to edit by clicking on the section...but saving them that 3 seconds of thinking/hesitation can help buy some goodwill later on in your experience. 

1. No one has a vested interest in what food app they order from. Most people are just looking for the cheapest price or a place they are used to.
2. People are creatures of habit and locality. You order mostly from the same few places around your house or work. Though those habits may differ...delivery if at work, pick up if at home, etc.
   
3. Don't ask a lot of your users before they get to the thing they want to do. We eliminated 3 steps before a user gets to a menu. This allowed the user to see the menu and then decide when they wanted to order. Conversely, it also led them to bounce faster when they didn't see what they wanted. 
4. Food ordering is a simple activity. It's singular and shallow. There are no other steps outside of putting an item in your bag and hitting the checkout button. ( This is not related to market place apps, but solely ordering food). Users generally don't care too much about hours or seeing their "bag" or other features that are not related to helping them order or decide what to order. Hunger is a need more than a desire.
5. Just put the "edit" button. Sure users can discover how to edit by clicking on the section...but saving them that 3 seconds of thinking/hesitation can help buy some goodwill later on in your experience. 

The second half of knowing the mindset of your users is quantitative data. The only real way to get this is to track events somehow. This can be done through Google Analytics or something like Amplitude. We did this in a 3-month long pilot program to a small subset of users --> see my other project on here Going Green.

But how do you know what to track? Well, that's where it gets complicated. When you first start using a tool like Amplitude, it's easy to try and track everything. That usually leads to dead ends or just useless digging or double data. Believe me...I know from experience . The best thing you can do is make a list of the blurry decisions you made during the design process or the lingering issues with your current app and try to solve those. ( ie. how many people really click _____? or is it important to have a "remove" button here? is it being used and what's the path that users take when they do use it?)

The second half of knowing the mindset of your users is quantitative data. The only real way to get this is to track events somehow. This can be done through Google Analytics or something like Amplitude. We did this in a 3-month long pilot program to a small subset of users --> see my other project on here Going Green.

But how do you know what to track? Well, that's where it gets complicated. When you first start using a tool like Amplitude, it's easy to try and track everything. That usually leads to dead ends or just useless digging or double data. Believe me...I know from experience . The best thing you can do is make a list of the blurry decisions you made during the design process or the lingering issues with your current app and try to solve those. ( ie. how many people really click _____? or is it important to have a "remove" button here? is it being used and what's the path that users take when they do use it?)

Overall, operating in this way became easier the more we did it. Our initial plan was to have a quarterly cadence to usability testing. This ended up being put aside as priorities shifted. It was unfortunate. Though, I can definitely see a world where this works...as expected. 

Overall, operating in this way became easier the more we did it. Our initial plan was to have a quarterly cadence to usability testing. This ended up being put aside as priorities shifted. It was unfortunate. Though, I can definitely see a world where this works...as expected.