Skip to content

Get Out of the Building

edited by Emily Remirez
April 2018

Details

Work Type
Austin Community College - User Interface 1
My Role
UX Designer
Time Frame
April - May 2018
Skills
  • Generative Research
  • Design Iterations
  • Prototyping
  • Usability Test

Summary

This project taught me some important lessons about both myself and the UX design process. I realized that I love the loop of iterating and testing. It’s incredibly gratifying to create something that I know works based on user feedback.

The biggest lesson, however, was that I hadn’t followed Steve Blank’s advice to “...get out of the building” to actually test. My final design only worked inside the building.

In other words; it worked in a vacuum that is a usability test; you and the user in a room with a device. But in my research I learned that that isn’t how my users actually listen to podcasts. They are usually doing something at the same time: exercising, driving, cleaning. The flow I created would require users to stop everything they are doing and walk step by step through my flow in order to achieve their goal. Now, I had a feeling from the beginning that the real way users would need to interact with this app would be with Voice UI, but it seemed like too huge of an undertaking. I was afraid to try something new.

Problem Definition

Book with sections highlighted.
Figure 1. An example of highlighting text.

Design an interaction flow that allows a user to do one or more of the following:

  1. “Highlight” audio, analogous to highlighting text in a book. What else can the user do now that they’ve highlighted the content?
  2. Listen to the book with other listeners around the world. Share your emotions on the content with the other listeners.
  3. Take notes on parts of the audio book you find interesting.

Constraint: Work within the technical limitations of existing devices and features.

The REAL Goal

People sitting at a table talking
Fig 2. Photo by rawpixel on Unsplash

My initial goal was to follow the brief. I went head first into sketching out some flows for a tool to allow users to create a highlight, just designing features. Now, tools aren’t innately bad, but I hadn’t even considered the why. Why did users need this?

To answer this question, I conducted interviews and constructed a User Scenario. By doing this, I discovered the REAL reason people want to create a highlight: to share interesting things with their friends in order to have a conversation. Meeting this goal would would create a REAL and compelling solution, not just a tool.

Discovery

The Discover phase
Figure 3. Discovery phase of my Design Process

Target Users

The target users weren’t specified in the initial brief, but I knew they had to be people who listened to long form spoken word content. Yes, that category is broad, but it served as a criterion for who I would interview. Talking to these users, I realized that they all listened to podcasts. I had discovered a more target user base: podcast listeners.

Interviews

Once I determined who the target users were I conducted three interviews. These were some of my first interviews as a designer. From these conversational investigations, I pulled a few key quotes that really inspired my design.

“...I’ll quote [a podcast] but I’ll quote it really poorly...I can’t ever remember where I heard it from. I’m not very confident…”

User K

“...It was hard for me to articulate exactly what the episode was about... I couldn't do it justice by saying it...”

User A

These key quotes informed the REAL goal, the why.

Persona VS Scenario

I chose to create a user scenario because it gave context to the whole user experience: where they were, what they were doing, when they listen, why they listen, and why they want to highlight. The specifics about the user that are generally part of a persona were less valuable in solving this problem.

User Scenario

Person lighting to iPhone
Figure 4. Photo by rawpixel on Unsplash

I conducted interviews in order to turn that list of features into a validated user problem with a user scenario.

You’re listening to your favorite podcast and you hear something really interesting; like your whole life is different interesting. You try to take a mental note in hopes that you can share it with your friend so their life can be different too. The next day you see your friend and you try tell them about what you heard, but you don't remember the exact details; you don't even remember where you heard it.

The Loop

In this phase of the design process I ideated and got feedback on those ideas. My approach was to start pretty lo-fi and ramp up once I settled on a plan.

The Loop Phase
Figure 5. The Loop of Design and Feedback.

Sketches

This was a sketch exploring the rough idea of how the app would work. I used the term “Cupcake” to describe this sketch. I borrowed this metaphor from IBM: a cupcake is simple and small, but still delivers on the goods. Similarly, this idea was simple and small but still delivers and solves the user’s need.

Here was a sketch including using Voice to prompt the app to create a highlight. The “Cake” metaphor is useful again here. A wedding cake is much more difficult to make than a cupcake, but also has tremendous value. This VUI flow has tremendous value, but was also a huge undertaking that I was scared at the time to tackle.

First Iteration Sketches
Figure 6. IBM Cupcake (Left) and Wedding Cake (Right).

Prototyping

My first prototype didn’t consider the flow. By conducting usability tests, I learned that users were confused by what they were seeing. They needed more context. This helped me improve my subsequent designs.

Prototype Overview
Figure 7. Collection of screens from my first prototype.

Usability Test | Feedback 01

Through usability testing I learned some valuable insights. This image represents a lesson in the value of context. On the left , you can see that my original design used blank label templates. As a result, users had no idea what they were even looking at. In my next iteration, I added real world data to give context.

Figure 8. A sample of the feedback from usability testing. When usability testing the user was confused because i didn't include any actual data.

Usability Test | Feedback 02

From a usability perspective, users weren’t familiar with the new icons I used. It didn’t help that they weren’t labeled. Responding to user feedback, the icons are now labeled.

Figure 9. A sample of the feedback from usability testing. When usability testing the user was confused because i didn't label the icons..

Usability Test | Feedback 03

Here, I presented my users with a flow and pattern that most weren't familiar with. I have some audio editing experience and I designed this screen, so I knew what was happening, but the users didn't. Their feedback helped me design a screen that was intuitive to all users.

Figure 10. A sample of the feedback from usability testing. When usability testing the user was confused because I introduced a new pattern to users and didn't label the icons.

Positives

  1. The faster you can get an idea tested the better.
  2. Improve based on feedback, don’t feature add.
  3. Give relevant context. Use actual information and data not just placeholders.
  4. Be aware of the user’s knowledge of icons.
  5. Be aware of when you ask users to do something new.
  6. Test outside of the building. Go to where your users actually use the product.

Not So Positives

  1. Don't design for yourself.
  2. Don’t exclude context in an effort to save time prototyping.
  3. Don't ignore the better solution because you’re afraid to try something new.

Next Steps

Sell it to the Apple Podcasts!

Ok, realistically:

  1. Implement Voice UI Screens.
  2. Tighten Up Visual Aspects.
  3. User test outside of the building.

View More Case Studies

Previous view_module Projects Next

What do you think?

Designers are nothing without critique and feedback,
so let me know what you are thinking.

Contact