DoorDash Redesign Challenge

Preface: This redesign challenge is part of the KPCB Design Fellows Application. I am not a designer at DoorDash.


The food delivery space is a saturated market of the on demand economy. Companies including DoorDash, Grubhub, Postmates, and now UberEats and Amazon compete with one another to sign on and retain as many merchants, drivers, and users as they possibly can.

I’ve used Grubhub and Postmates before, but never DoorDash. As a result, I’m able to tackle this challenge with fresh eyes, having only used a few other on demand apps before.

In the following challenge, I focused primarily on the interaction design of the web app for a variety of reasons. Firstly, without knowledge of internal business and engineering constraints, especially for a company facing the challenges of the on-demand marketplace, I decided to avoid creating any kinds of “new features” without data to back up my decisions. With interaction design, however, it’s relatively easier to conduct some basic usability testing to see how users respond to the actual design itself. Furthermore, my design background skews heavily on native mobile apps, so I decided to challenge myself by focusing on DoorDash’s web platform.

1. Identifying the opportunities for innovation and improvement

With any redesign first comes identifying opportunities for innovation and improvement. How can the user experience of ordering food from DoorDash be improved?

Opportunity 1: Consistency between native and web platforms.

Upon first glance, there are lots of similarities between the two platforms. However, once you take a closer look:

  • The mobile list provides price range (denoted by ‘$’), as well as the rating. My assumption is that these pieces of information are very important to users, especially when looking for new restaurants to try, and leaving them out on the web platform is a mistake.
  • Where are the filters on the web platform? The three filters provided on mobile are extremely helpful for users to quickly navigate and filter the restaurants they’re interested in trying, reducing cognitive load on users.

It’s important to maintain consistency between the two platforms to create familiarity for your users. Users are no longer single screen exclusive, thus companies should design and strive for consistency between all screen sizes.

Consistency aside, there are also a few areas of opportunity for the web platform in regard to the interaction design.

Opportunity 2: Cuisine filter badges provide insufficient user feedback (i.e. active vs inactive)

In the gif above, I’m filtering for restaurants that have salad. On hover, the salad badge expands to its active state. On click, however, there are no obvious transformations to the badge itself that demonstrates that I’ve applied the filter. Rather, the word “salad” is auto-populated into the search bar. This is confusing primarily because it doesn’t match the user’s mental model — a search bar is for searching, and badges/buttons are for clicking. It isn’t intuitive to take a button and populate it into a search bar.

Opportunity 3: The results laid out as a grid creates a lot of unnecessary cognitive load onto users.

Wow. Such clutter. Much cognitive load.

As a user, I can’t read and interpret more than one result at a time. How do I even begin to navigate the plethora of results presented to me? Should I just scroll endlessly? What do I do if I want to see which restaurants deliver the fastest, or have the highest ratings?

Opportunity 4: Insufficient user feedback when users add an item to their basket.

The actual cost has scrolled off the dialog, and isn’t present until a user scrolls all the way down.

In the user flow above, you can see that I decide to add a Caesar Salad to my basket. In the following modal window, I’m then prompted to select the size, a variety of add-on options, as well as other menu items that other people order.

With so much variability in the price range, however, there’s a large lack of feedback in regards to the price. Sure, next to the item says the add on price, but as a customer, I would find it much more helpful to know the full cost without having to scroll back and forth.

Another issue with this design is the possibility of users clicking the size or add on items, then exit by clicking the ‘X’ or outside of the modal window because they think their orders have been added to cart. Why? Well, when the modal window first appears, there is no clear “add to cart” CTA until a user scrolls down.

Based off of these assumptions, here is a summary of the goals I’m striving for via my interaction redesign:

  • improve consistency between native and web app.
  • provide more indicative user feedback based on their interactions.
  • improve the user experience and strive for clarity through a new layout.

Next, I’ll outline my design process below.

2. The Design Process

I began the design process by wireframing some of the potential layouts that might improve the user experience based on my prior assumptions.

Wireframe 1
Wireframe 2

The wireframes above are very similar, their difference being primarily in the filtering of cuisine. The first uses a GUI similar to their current approach to the cuisine picker, while the second uses a dropdown list to display the options.

The biggest layout difference between these wireframes and DoorDash’s current web platform is probably obvious: I approached this redesign using a list and split screen. I believe this is the most efficient way to display information for users for a variety of reasons. Firstly, the existing grid approach is extremely cumbersome: in order to view items on the menu, users must click to explore, then click the ‘back’ button to go return to the results. After exploring a few different restaurants, this might become mentally tiring for the user. The split screen list approach, however, shows no more than 5 restaurants at a time, which bears a much lower cognitive load on the user. Furthermore, most of the screen real estate is devoted to the menu items, which is what users are ultimately looking for. By streamlining the restaurants with their respective menu items, I hope users have an easier time finding the right restaurant to satiate their appetite.

Hi-Fidelity Mockups

I’ll start by presenting the flow of the mockups I’ve redesigned to provide some context before jumping into design decisions. Let’s get started.

  1. I’ve just typed in my address in the landing page (not shown), and here are the results. I’m immediately greeted by the most “delightful” restaurant near me, and their menu items look fantastic! Let’s take a closer look.
Yum. Squat and Gobble!

2. I scroll down and hover over “French Onion Soup”. This looks tasty. I’ll add it to my cart.

French Onion Soup, meet my stomach.

3. Looks like I can add other items that people have added with their French onion soups!

4. Okay, the Chili looks good. I’ll add that into my order.

5. Great! Now I can see that it’s in my cart! Time to order more food from Squat and Gobble!

Design Decisions:

Split screen layout: By using the split screen to show the first result’s menu items, we not only minimize the cognitive load that DoorDash’s current layout creates, but we also immediately invite the user to explore the menu, minimizing a point of friction for the user and perhaps increasing conversion rate.

A challenge here might be, how might it look for a responsive screen size? Their current approach is indeed very intuitively scalable across multiple screen sizes, as it utilizes the 3 column approach. Not to worry, however —this was definitely something I consider when designing for any web platform.

1280px vs 768px

As you can see above, once a screen size is <768px wide, the split screen breaks down into two screens. The left screen shows the restaurants, and when clicked or tapped, it takes users to the restaurant’s menu items. If users desire to go back, they can either use the back affordance in their browser window, or the <restaurants affordance above the restaurant menu. For mobile, a similar resizing of the layout would occur.

Redesign of search bar: I redesigned the search bar so that it’s dynamic, only present when the user needs to use it. In the current DoorDash layout, the search bar is always present, meaning it takes up screen real estate despite it not being constantly used.

The new search bar takes up much less screen real estate while remaining easily accessible for the user.

Redesign of cuisine badge interactions: Currently, as I mentioned in the opportunities section, the badge label is auto-populated into the search bar instead. This is confusing primarily because it doesn’t match the user’s mental model — a search bar is for searching, and badges/buttons are for clicking. It isn’t intuitive to take a button and populate it into a search bar.

Cuisine badge interaction prototyped in Principle

In the prototype above, I redesigned the interaction a user has with the badges to provide better feedback. The 50% opacity represents the inactive state, the increase in size and opacity represents the hover state, and the red ring around the badge represents the active state.

Redesign of “Add to order” modal interaction: I mentioned in the opportunities section that providing feedback and keeping the CTA visible is important here for the user.

In this prototype, you can see that the CTA is visible at all times in a fixed footer, and depending on if the user adds an extra item or has add-ons for their dish, they’re clearly displayed in the button as the total cost changes dynamically. Above the CTA, the add ons are also displayed so the user can clearly see that they’ve added an extra item to their cart.

Lessons Learned

  1. Constraints matter. I found the open-endedness of this redesign challenge to be quite challenging because there were no constraints. In the real world of design, when working alongside engineers, product managers, marketing experts, and user researchers, there are a plethora of constraints that shape how a product takes form.
  2. Teamwork makes the dreamwork. I would have loved to collaborated with other designers, engineers, or best yet, DoorDash customers to understand the potential tradeoffs. Much of my design was based off of intuition and assumption, rather than data, which I would have loved to leverage. For example, it would be really interesting to A/B test my layout against their current layout to look at conversion rates.
  3. Every problem is different, so do your research. I researched DoorDash on TechCrunch and read about the on-demand space, and looked at competitors including Postmates and Grubhub to gain a better understanding of the design systems that underly these on-demand service apps.
  4. Screen sizes matter. We’re in the 21st century, and oh my gosh there are so so so many screen sizes. Designers must understand how their designs should scale across multiple screen sizes and platforms.
  5. The best designers are critical of themselves. It’s hard to not be in love with your own designs, but this is really what separates good designers from great designers. Throughout this project, as I was designing, I kept thinking…what would John Maeda do? Just kidding. But seriously, every step of the way, it’s imperative to think about alternative designs and their potential tradeoffs.
  6. Medium is awful with GIF support. Yup. I said it. I had trouble uploading GIFS >1MB, so I had to make them quite small, thus they look a bit pixelated.
  7. I really, really love product design. I loved this challenge, and I’m excited to continue growing my skill sets as a product designer.

Thanks for taking the time to read this!