UX in action: Q&A with Frank Yoo, Director of Product Design at Lyft

Posted on May 24, 2015
4 min read

Share

We sat down with Lyft’s Director of Product Design, Frank Yoo, to talk about how he thinks about building product, managing design teams, and the future of ride-sharing. Enjoy!

Q: How is your team at Lyft structured?

Currently, our team consists of nine product designers, three UX researchers, and myself. We’re roughly organized by three design “pods” that focus on one of our three core experiences, which include passenger, driver, and enterprise.

The idea is that we establish a deep domain expertise in each area. So each pod is accountable for all platforms and all UX touch-points, such that a customer’s experience throughout the entire product experience is consistent, polished, and optimized for that particular use case.

Q: What tools does your team use to stay organized and to collaborate with each other?

For constant communication, we’re definitely heavy Slack users. Though I will say, sometimes that random Giphy plugin scares the crap out of me. But we also use Dropbox for design files. And for most of my daily management tasks, I’m in a combination of email, calendar, Google Docs, and a healthy amount of 1 on 1 coffee runs.

For projects we use Jira. It’s a beast of a tool but once you get familiar with all the functionality, it’s pretty powerful. The learning curve is pretty steep but it’s our main product management and bug tracking tool.

Q: Lyft delivers 17 million rides per month. In terms of UX research, how is your team collecting feedback from all of your users?

So we have many channels. We have our data and analytics team, but we’re also collecting a ton of insights from our own UX research team. We hear about bugs and issues from our customer support group, and anecdotal feedback from friends, family, and other connections.

And of course, we have all the various signals from social media—all the shout outs on Twitter and Facebook demanding that we fix our stuff. So it comes from all sides. But we definitely have organized channels and ways in which that feedback funnels back into the team.

Q: What have you found to be the most effective method for receiving user feedback?

There’s nothing more compelling than observing a customer struggle with your product. Whether it’s through live observations or mobile screen recording, visibly seeing the frustration on a participant’s face, or watching someone aimlessly poke around your UI is a pretty powerful motivator. And I’ve seen that also be the case for other people. You really want to jump in and stop the pain and fix it right there.

And also, since our use cases are predominantly mobile, I find the best sessions for me are the ones that take place in the real world, or under the most simulated real-world conditions. For me, those sessions deliver the purest signal.

We’ll actually go out and take rides with people, both with passengers and with drivers. Often times we’re sitting right there with the driver taking notes, and asking them to step through certain interactions—while parked, of course. The more you can simulate how your UI will perform under real-world conditions, I think that’s where you learn the most.

Q: What’s the timeline like for your research projects? Are you working within two-week agile sprints? How does that work at Lyft?

It depends. In terms of our product development process, we have weekly “trains,” or a weekly release cycle. There’s QA testing happening all the time, so if you complete a project by a particular cut-off and it gets QA’d in time, it’ll make it on that train and get released. So that doesn’t match up 1 to 1 with our research cadence.

Sometimes we have to back things out from a projected release date. For example, we might try to get a feature out for the April 11th train, which is several weeks out. And if we miss that train, then we’ll just catch the next one. We try to back things out and give ourselves sufficient time to properly conduct the research, and provide the design thinking and prototypes that go into any of our solutions—so we can come out with the best solution.

We try to continue to work quickly and make sure we’re always shipping. It’s a constant hustle. We don’t want to get too relaxed. So we’re hustling to ship, but we want to make sure that everything that’s going out the door is of the highest quality.

Q: Any big UX and design predictions for the ride-sharing industry in the next year or two?

As this service matures, I think the best experiences will win the day. This is a very design-driven aspiration. But looking much farther into the future, I think the interaction models might even move away from the screen and become more automated. Let’s say you need something in the future, you won’t order it, it will just show up. Maybe no buttons. No more screen-based UI as we know it. That’s the future that I imagine.

You would just walk out the door and your car would be there. Lyft would just know. I’ve talked to a few different companies that are thinking about this sort of an experience—getting our heads our of our phone, off of our laptops, and not prescribing any sort of wearable, screen-based UI. Through artificial intelligence and your behaviors, things just know when to show up for you.

It seems like a crazy, weird concept. But as technology becomes more woven into the fabric of our day-to-day, that’s the kind of future I’m looking forward to. So at five o’clock, I walk out the door, and the system just knows that I’m ready to go home.

In this Article

    Related Blog Posts

    • Blog

      How to achieve product-market fit

      According to CISQ, $2.26 trillion is spent on software re-work in the US So...
    • product design principles

      Blog

      Top product design principles for creating standout products

      Having user-centered product design principles means emphasizing early user involvement and iterative refinement to...
    • product design prototyping

      Blog

      Mastering product design prototyping

      Product design prototyping involves building early versions of a product to test and refine...