Written by Lindsey Menges

Lindsey joined DoorDash in 2018 and is a Design Technologist on the Design Infrastructure team. When not building Prism components, she loves roasting her own coffee and hiking all around Northern California.

At the beginning of 2020, DoorDash’s Design Infrastructure team introduced a Theming feature to our Prism design language system, an internal library that makes frontend development projects more efficient while ensuring consistent design across all of our products. Theming provided an API for engineers to define how Prism components would appear on the screen. With the introduction of this new feature, any team building a product for the web could easily bring the Prism design language system into their project and take advantage of the large number of pre-built components, typography elements, and visual color definitions.

Our design language system, which we call Prism, is one of the most powerful tools that our frontend engineers utilize in their projects. Prism’s centralized web, iOS, Android, and Figma libraries contain definitions for the lowest-level elements of our design ecosystem…

Read the rest on the DoorDash Engineering blog →

Implementing Theming in DoorDash’s Design Language System was originally published in Design @ DoorDash on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design Infrastructure is becoming a core part of how we design and build our products at DoorDash.

Officially, the Design Infrastructure team here is just me, and I work alongside a ragtag group of folks assisting from product design and engineering. But now, we’re looking to grow the team to scale up its impact and make DoorDash a leader in high quality design and engineering.

We want to build a home where people who love both design and engineering can use their skills to impact our products & processes at scale. Personally, I’ve always struggled with having to pick between being either a designer or an engineer. But with the role that this team is playing, there’s now a more defined space for others like me, where we can do both.

So what is Design Infrastructure at DoorDash?

Defining Design Infrastructure

One way you can define what we do is to see what we’ve already done. For instance, over the last year, we’ve shipped our Design Language System (DLS) for Web, Android, and iOS. We’ve built libraries that share typography, color, spacing styles and concepts between platforms using design tokens while setting the stage for cross-platform design work and shared components. We’ve standardized our typography and color systems throughout our apps. We’ve invested in building out a robust component system in DLS Web, making the hard, tedious, error-prone work of building things like modals no effort on the part of both design and engineering. And finally, we’ve started shaping the processes of how designers think about design, how they communicate and work with engineering, and how engineers think about implementing the experiences we design.

But that’s just a small part of what Design Infrastructure aims to do.

There are two halves of design at DoorDash that are equally important—being able to be generative and exploratory to find the right shape of a solution, and then productionizing those designs to account for edge-cases, utilizing existing solutions, patterns and language, and working alongside engineering to make those designs truly work.

And when engineering our products, we need to think about so many things: how do we make sure that we account for our edge cases? How can we make implementing complex (but important!) micro-interactions repeatable and low-cost, so that we can really focus on the things that are different between experiences? How can we make accessibility something that we bake into all of our work, as simply as possible? How do we make it easier to have shared understanding and concepts with design, so that we can communicate more fluidly? And how can we make our work as collaborative as possible?

We think Design Infrastructure is responsible for making all of this easier.

Efficient Exploration

Design Infrastructure can help designers be more efficient when exploring the edges of design—think of building tools like René from Jon Gold—so that the manual work of coming up with many options can be automated away, and the real value of human judgement can be put to better use evaluating and selecting the designs that make the most sense for the problem at hand. We also build prototypes & prototyping tools that help designers solve hard questions that static design tools can’t answer. We work with product designers to push our visual, and interaction design system forward, spending time outside of any individual product project to work holistically across our systems.

Designing for Production

Design Infrastructure will make productionizing (taking our explorations and making them work in the context of our design & engineering systems) easier: building tools for finding, understanding, and using existing design decisions & patterns—both through static (like documentation) and interactive (think tools for that guide you to use parts of the system) means. We can make communication easier by having a shared design language across design and engineering tools, and ensuring that designs are easy to read and understand when they’re documented (think a super-charged Zeplin). And we work with product design to ensure that our brand consistency and visual design quality is at a standard that meets our systems.

Design Tools, Systems, and Patterns

Design Infrastructure builds the components and frameworks that make implementing our designs easy. By creating & engineering complex interactions once and reusing them, we ensure they’re high quality and allow product designers and engineers to focus on product problems. By designing usable, flexible-enough APIs for engineers & designers to configure components, we make our system robust and better able to meet the needs of our experiences. We design our systems to make updating them as simple as possible. And finally, we establish a focus on accessibility deep in the designs and the code we write so that it’s a foundational part of how we design and build our products.

Design Infrastructure is at the intersection of product design and engineering, and we support both sides through our tools, systems, communication and most importantly, our shared empathy of design and engineering.

A home for the people in the middle

I’ve always been a hybrid. I’ve done engineering and design at every single stop of my career, and I don’t know how I can do something that doesn’t engage both sets of skills.

For a long time, I wondered what the right space for me was—was I better off as an engineer or as a designer? And even though I’ve always done both, it was always hard doing both at the same time.

I know now that it doesn’t have to be this way. There is room for both sides in one role & one team. My goal, alongside supporting our partners in product design and engineering, is to build a space where you don’t have to choose one side. I want a home for the best people at the intersection of design and engineering to do their best work. A place where we can make an impact on the quality of all our products and make how we do our work even better and more collaborative.

That’s what the Design Infrastructure team at DoorDash is.

And if you’re excited about that as much as I am, you should come work on it.

We’re looking for Design Technologists and Visual Designers. If you’re interested message me at kathryn@doordash.com, or DM me on Twitter. If you’re interested in learning more about what we’ve done so far, take a look at this talk I gave in April to Khosla Ventures companies:

Let’s do this!

Design Systems and Infrastructure—where design and engineering meet. was originally published in Design @ DoorDash on Medium, where people are continuing the conversation by highlighting and responding to this story.

So. You’re building a design system for your company. It’s got everything that you would expect. Text Inputs! Custom single-select and multi-select fields! Buttons with every configuration option under the sun. And of course, the old standby: the modal.

While building a modal can seem simple from the start, there are a lot of cases and issues to discover once you release and iterate on it. And for us, we discovered a ton in the process of building a modal for our design system at DoorDash:

1. We learned that z-indexes in content need to be managed in a consistent way
2. We discovered that there are many accessibility considerations that need to be accounted for with modal contexts
3. We found a gap in the way we tested our work, assumptions that were less solid than we thought, and unforeseen bugs because of it

So, here’s some stories (adjusted a bit from reality) that helped us learn how to build a modal.

The z-index problem

Four days pass. You internally published your fancy reusable animated modal out as a package a couple of days ago, and it’s been pushed into production a few minutes ago—a coworker used it to rebuild the event sign-up experience. You get excited about seeing the thing out in the world, all the people RSVP-ing for all their fun events, and you smile a little. A moment later—

Support: We’re seeing some funky behavior when folks try to join an event after this latest deploy. Looks like event RSVP numbers are tanking, and conversion is in the single digits, but only on desktop web—seems like mobile web is unaffected.

Me: Weird.

Coworker: Double weird. I didn’t do anything different between mobile web and desktop at all…………… why would it break??

Support: From reports, it seems like customers are stumbling on filling out one of the fields—looks like it’s the one where they specify the number of people that they’re bringing with them. On desktop, people are clicking it, but they can’t see the options for number of guests—they click and it just doesn’t open. And they keep on clicking, according to the tracking on that thing.

Coworker: Wait but the dropdown didn’t change at all with my deploy. We just moved the existing content of the RSVP flow into the new modal. We’ve been using that same single-select dropdown since it came out in the design sys—

Me: Oh god, I know what it is. On mobile the single-select dropdown uses the native select renderer that pops up a system scrolling list. On desktop, we render our own custom dropdown. The dang thing probably has z-index conflicts with the modal. It’s rendering the custom dropdown behind the modal.

Coworker: z-index??? Classic.

You need to know how to create and manage stacking contexts:

The stacking context is a three-dimensional conceptualization of HTML elements along an imaginary z-index relative to the user, who is assumed to be facing the viewport or the webpage. HTML elements occupy this space in priority order based on element attributes.

When you create a new stacking context, you ensure that elements that are children of that context cannot change their stacking behavior relative to other elements that are not in its stacking context. No amount of fuxing with z-index on a child in one context will make it stack differently against a child in another context. The only way to change the stacking between different contexts is to change the stacking behavior of the elements that created the new contexts.

Within a stacking context, child elements are stacked according to the same rules previously explained. Importantly, the z-index values of its child stacking contexts only have meaning in this parent. Stacking contexts are treated atomically as a single unit in the parent stacking context.

So how would knowing about these concepts work out in the context of our Modal?

This is how you prevent issues of modal content, application content, and the modal itself causing issues:

Takeaway: Know how to create new stacking contexts for application content and modal content, so that messing with z-indexes values in either doesn’t cause content to appear above or below what it’s expected to.

A demonstration:

The point being: since you can anticipate that there will be components that use z-index for layering in your modal content, you can create a new stacking context for that content to ensure that those elements in the modal content container with z-index only display above or below items in the modal content context.

At DoorDash, we use a LayerManager component that uses react-gateway internally to ensure that Modal content is rendered into a different stacking context than application content—so no matter what you stick into a modal, or whatever z-index you put onto a something in application content, the Modal will render above it—no crazy layering issues because stack order is guaranteed.

Managing the focus state of your application

Six months pass. You get a Slack message from user research.

Me: “We did that badly on the usability test!?”

User Research: Yup. We went through the ADA guidelines audit, and it seems our keyboard accessibility is pretttttttty bad. Among other things accessibility-related.

Me: Really? I put focus states on all of our components, and try to make sure we’ve got the right tabindex properties our interactive elements. What went wrong?

User Research: Looking over the notes from the session, it seems like the biggest culprit is that in any of our modals, when they’re first opened up, tabbing doesn’t change focus into the modal. When folks try to tab around, they end up having to tab through a bunch of page content, stuff that should be hidden/obscured by the overlay, before they’re able to actually interact with and use the modal itself.

Me: Oh boy. I think I missed this completely when I was working on this… Time to go brush up on modal accessibility.

Wait. Where can I learn how to do this correctly?

The WAI-ARIA documentation and examples are your friend

If you’re not familiar with what WAI-ARIA is, I’ll let their intro explain:

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

If you want to know how to build accessible applications and websites, those docs are the first thing you should read. They describe so many of the expectations for how modal dialogs (their parlance for the modal component) should work for accessibility: how they should be labeled for screen-readers, what keyboard shortcuts should be expected, and of course, how focus should be managed when you enter and exit a modal.

While the WAI-ARIA docs are a great resource, the Mozilla docs on dialog accessibility do a great job condensing the guidelines for focus management:

A dialog has particular requirements for how keyboard focus should be managed:

1. Dialogs always need to have at least one focusable control. For many dialogs, there will be a button like “Close”, “OK” or “Cancel”. Besides that, dialogs can contain any number of focusable elements, even entire forms or other container widgets like tabs.

2. When the dialog appears on the screen, keyboard focus (whose control depends upon the dialogs purpose) should be moved to the default focusable control inside the dialog. For dialogs that only provide a basic message it could be an “OK” button. For dialogs containing a form it could be the first field in the form.

3. After the dialog is dismissed, keyboard focus should be moved back to where it was before it moved into the dialog. Otherwise the focus can be dropped to the beginning of the page.

4. For most dialogs the expected behavior is that the dialog’s tab order wraps, which means that when the user tabs through the focusable elements in the dialog, the first focusable element will be focused after the last one has been reached. In other words, the tab order should be contained by the dialog.

Main takeaway: ensure that focus when tabbing while a modal is open is restricted to focusable content in the modal.

You can see some of the behaviors in the list above in this lil’ animation:

One thing to note: this behavior is not something you get for free if you’re using aria-role="dialog" —you, as the application developer, need to implement this focusing behavior yourself or have a library do it for you.

All the quirks of a managing focus with modals can be tricky to enumerate and consider, and are certainly not something you want folks to re-implement every time you just need a modal to get people to put stuff in their cart. On that path is madness, alongside the missing of many, many edge cases.

Luckily, we can make sure that, with a standardized dialog modal from our design system, no matter what, the focus management can be applied and no one has to worry about re-implementing it again. And with some handy libraries, implementing it the first time is easy to read and understand. If you’re just using straight vanilla JavaScript, it’ll look something like this with focus-trap!

focus-trap is a small library that will manage saving the last focused element, finding and focusing on the first focus-able element of the modal, keeping focus within the modal, and restoring focus to the last focused element once the modal is unmounted.

You can see some an example of how to use it here:

For DoorDash, we use focus-trap-react, a light wrapper around focus-trap that makes it easy for us to integrate into our modal implementation. No matter what, our modals will do the right thing for keyboard users.

The scrolling annoyance & the curious viewport

It’s been a week and a half. Among the daily batch of JIRA tickets that somehow ends up in my inbox, a short but sweet one from our designer looks like this:

[DLS-124] Scrolling to bottom of modal scrolls to bottom of page

Description: When using the add-item modal, when you scroll to the bottom, continuing to scroll causes the background content of the page to keep scrolling until you hit the bottom. It’s a bit annoying.

In my head I’m thinking:

Ugh, that is annoying. I should fix that soon.

So, I went to work.

Investigating a few options from other modal implementations for locking the scrolling of the page content when a modal is visible was a normal task that people seemed to handle in fairly straightforward, mundane ways. As simple as tossing an overflow: hidden on the document.body, right?

Not quite.

[DLS-147] Scrolling within a modal on mobile can get content in a weird state

Description: We started using the modal for confirming your contact information when you log in; people get stuck because the confirm button, that you’ve is supposed to be fixed to the bottom of the viewport, is hidden behind the navigation controls. So customers try to scroll to move forward, and then things get weird—they don’t actually get the confirm button to show up where they can click it, but they end up scrolling the content of the page behind the modal. They can see the page scroll bar move, but nothing visible (even the actual content of the modal) actually moves with it.

So, I guess this is two bugs!

What!? Why is the button outside of the viewport, behind those controls? And I thought I handled the page content scrolling? Ugh, this is getting tricky…

I dug in. There were three real problems:

1.

We made an assumption that viewport height units would just work, in all contexts—that if you set a modal to the full size of the viewport, it would ensure that the content and controls of the modal would always be visible. Unfortunately, the definition of in-view is hard to pin down, especially on mobile.

There’s a great survey on GitHub of the mobile browser landscape in regards to how they treat the viewport in relation to the browser’s navigation controls. I would read that to really understand how

The mobile browser URL bar is such a pain! It interacts with the page in a different way in every browser. This page hopes to explain the nuances of how the URL bar affects the web page, document the differences between the browsers, and explain some proposed recent changes to Chrome to improve the current situation.

Nicholas Hoizey has an excellent writeup on this issue, which surfaced this explanation from a contributor on Safari:

This is completely intentional. It took quite a bit of work on our part to achieve this effect.:)

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the “looks like shit” part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.

So, to handle this issue, we ended up accounting for the specific amount of pixels hidden by the Safari navigation controls using css calc—we could ensure that our content is always visible, and that there would be no situation where something you expect to be available to the user is blocked off.

2.

overflow: hidden isn’t sufficient for preventing the body content from scrolling. On iOS, there are only two reliable ways of doing this: Setting position: fixed on the document.body, or adding event listeners that prevent the default behavior of touchmove on the body content. And because the tradeoffs of short-circuiting touch events seemed too problematic for use in our modal, we went with the position: fixed body content.

3.

We only tested the modal for mobile using the responsive testing mode on Google Chrome. We didn’t use actual devices, and in the process, missed out on the issues above—we didn’t have the right tools in place to ensure we could see the issues the modal had.

It’s hard to anticipate a certain class of problems unless you’ve been through them before. There are edge cases that are easy to overlook when you think things are certain — and the way through is to be confident in strategies to gather information, test your stuff, and uncover problems. Design systems, for all they are in technology, are also about processes: the way we anticipate problems, investigate the design and technical tradeoffs, and distribute those solutions more broadly.

And in this case, for these problems, there was a gap in how we were working. The process of testing our designs, on actual devices, and making sure the assumptions we felt were incontrovertible were actually true in practice was missing, and the gaps showed.

So the lesson: Always test with real devices. Always test your design in the real contexts that they’ll be used. You’ll be surprised at all the little things that you didn’t consider, and you’ll iterate accordingly.

The Takeaways

So, what did we learn?

Consider modal accessibility from the start

Test your accessibility, with different browsers, desktop and mobile, and with screen-readers. Understand how keyboard users, non-visual users, and other folks will use your modal—accounting for all those use cases and setting up your product teams for success from day one will pay enormous benefits in the long run.

Know the content that modal will contain, and guard for edge cases

The z-index issue is one of a class of issues that is mitigated with research and planning: anticipate how your components will be used, and figure out their pain points—as a component that will used in a layering context, understand and anticipate that you’ll need to account for uses of layered components both in application content and in the modal content itself.

The system is made of processes as much as components

Open yourself up to look beyond the components themselves, but the way they’re made, the way they’re tested, and the way issues are discovered. As we saw with the mobile scrolling issue, we needed better requirements around testing all of our assumptions, on-device, so that we could’ve seen the issues around mobile sooner, and learned that our assumptions were not as rock solid as we thought they were.

Make your component a tool to distribute best practices

Building a design system helps aggregate good decisions, account for tricky & elusive bugs, and ensure that the lessons we learn through building can be archived and reused again and again, with minimal effort. Accounting for how modals work on mobile, how they ensure background content doesn’t annoyingly scroll, how we enforce that they’re accessible—a shared component in a design system, with the appropriate API and documentation, can provide us a tool to allow product developers & designers to focus their thinking at a higher level of abstraction. We consider how we shape the product and all its facets, rather than focusing on the UI focused decisions that don’t need to change, and can take an inordinate amount of time to get right, again and again.

That’s all. I hope you enjoyed it—and I hope this helps you consider the things that aren’t so intuitive about building a modal so you can provide a great tool to your developers, and to the users they’re supporting.

P.S. If you found this interesting, we’re doing work like this and more at DoorDash. Email me at kathryn@doordash.com, or DM me on Twitter. The future is bright.

How To Build a Modal was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Weekend Work: Designing Search for DoorDash

What You Want, When You Want It

Howdy. This is the first in a series of posts taking on some specific design problems from cool companies doing interesting things. I’ll break down the problems and work through a process of coming up with a solution or two. Keep in mind that most of the work done here occurred in drips and drabs over a couple of days.

For the first go, I decided to write about a quick weekend re-design of the search experience for DoorDash, a company out of Palo Alto which is trying to to empower small businesses to offer delivery in an affordable and convenient way. They contacted me and asked for some help thinking about the problem, and I threw some work together. Below are some thoughts on the problem, process, and a peek at a first iteration of a potential solution. You can find all of the assets from this project here.

You can find more of my work at ryngonzalez.com.

Design is the process of deciding how something should be. When you’re a product designer (which doesn’t necessarily mean you have design in your title), you have a particular perspective on a problem, and your perspective shapes how you tackle the corresponding solution, which includes but is not limited to the products that you’re creating. Every smart & stable organization has a singular perspective on how they go about their work, a perspective that is the aggregate and result of all these internal viewpoints coming together (through fire, brimstone, and high-intensity discussions) into something coherent and visible from the work that they put out in the open.

As an outsider trying to design from the perspective of DoorDash, I needed to make a few assumptions about how they see the world and the problems at hand.

The macro-problem: enabling small businesses to easily offer delivery.

The micro-problem: helping customers find what they want delivered.

Here’s what I came up with after reading up on their work and chatting a bit with them:

1. Smart operational, technology, and design choices lead to a better experience for both the customer and the small business.
   How can you design the customer experience to enable better operational efficiency? How can you design the operational process to enable a better customer experience?
2. Discovery, delivery, and usage are all steps of the overall experience that must be designed with intention on a holistic level.
   Each step affects the other, and problems in one step should be solved by considering changes throughout the system as a whole, not just isolated in one area. Design with the idea that you can change more than the customer facing interface.

These are the points that helped orient my thinking while designing a better search experience for customers. I spent a few hours this past week doing some writing, sketching, and prototyping and came up with a thing or two that could help solve this problem.

Anyway, let’s get on with the show.

DoorDash Search: What we have now

Before I get into the meat of things, I’ll just say that the modus operandi here is avoid straying too far into unneeded ratholes like updating the visual style, working on iconography that’s pixel perfect, or obsessing over inconsistencies between different mockups (not a priority), while ignoring the problems that we set out to work on.

I’ll just point out the visual aesthetic in play so that I don’t have to explain later: the interface is simple, sticks closely to the iOS design guidelines, and uses a few custom components that don’t stray too far from what’s established. Red and Avenir provide a slight veer from the standard. Photography is limited to small squares for each restaurant’s branding.

Current issues

As for navigational and functional issues, here’s the current state of it from the horse’s mouth:

Right now, we simply show a giant list of all the restaurants within a specific radius that the customer can order from. This obviously has several drawbacks. It scales poorly if you have lots of restaurants, e.g. 1000+ menus. It’s also very hard to discover new restaurants — usually you have to know the restaurant beforehand or pull up Yelp at the same time.

Put in another way:

Search in DoorDash right now is a blunt tool for finding food from places that you know, rather than a sharp tool for finding exactly what you want to eat based on your context or mood, without you needing to go outside the app for recommendations and ratings. It throws everything it has at you, with no curation or organization (intuitive filtering by category doesn’t exist), and very little signposting (like the quality of a restaurant, the average price, the ratings of individual items) to help guide you when making a choice about what you’d like to eat. The onus of finding what you need is on you the customer, rather than on the service and interface, and there’s a lot of improvements that could be made to shift that responsibility.

Order process

Right now, picking an item to order is a 3 or 4 step process (dependent on if a given restaurant has multiple menus):

The search is business-centered, vs. item-centered or a hybrid of the two. Even if you knew exactly what kind of meal you wanted (say a large tabouli salad and some falafel) you would necessarily need to find a restaurant that would serve that first before you could add it to your cart, and then drill down into the restaurant’s menu to actually select it. For now, the service is not taking advantage of the fact that they have access to item-level listings to greatly increase the utility of search, and that they can use their data on what people are buying on a per-item level to drive an increased push in recommendations.

Search

Right now search acts on two properties of a listed business to help a user find it: the name of the business and the single category of the business. This leaves you four ways to find something you want to eat:

1. You know a place that serves the dish that you want, and search for its name.
2. You know a place with which you’ve had good food in the past, with dish TBD, and search for its name.
3. You search for the category of cuisine that would likely serve a given dish.
4. You search for a general category of cuisine that you’re in the mood for.

While this can be useful in some cases, there’s still a large burden on the user to know what’s good, and too little guidance on our part to help facilitate this decision making process.

So, that’s where we’re at now.

1. No organization, curation, and recommendations

2. No signposting for comparing and contrasting different restaurants and items

3. Not taking advantage of itemized search and discovery

Process

For me, a lot of design is about writing. I write to give a structure to errant and passing thoughts that I’d otherwise miss. As thoughts come, I put another leaf on my project outline so that it’s connected to what came before in an organized set. It’s like thinking out loud manifested on paper: it gives me a third party viewpoint with which I can look at and analyze my ideas, and to think in a more critical way about them. A space for metacognition. It’s a medium the lends itself to rounding out the understanding of a problem, and it’s invaluable to me when I’m trying to capture the shape of the problem space or some ideas that I could use to tackle it.

On the flip side, I usually have a notebook for sketching by my side while I’m trying to flesh out my outline. It’s the free-form place where I can explore, mess up, and just come up with the shape of ideas wacky, obscene, and potentially useful. To me, writing and sketching are just two sides of the “trying-to-figure-out-the-problem” phase.

The Organizing Principle

The thing that I wanted to explore and design first was the idea that the items and businesses could both be equally positioned as things to be searched for and presented: a design that would show you restaurants and items in a set of search results, rather than just surfacing restaurants and forcing you to drill down to find the dishes you wanted.

When you go to the DoorDash app right now, you’re thinking about ordering in the same way you would think about selecting a restaurant to go eat at in person: it’s the Yelp-Foursquare-Maps-Model.

But DoorDash is in a special position in that it knows about the individual items that a restaurant serves, knows stats about each individual item (sales, ratings). Those items are the actual things selected for delivery at the end of the selection process, and the restaurant that provides it simply helps guide someone towards that selection. So, what could an item-centered search and discovery experience look like?

In an item-centered approach, there’s no need to select who to buy from, only what you want to buy. Sure, the information about the given seller can be found once you click through to the details about the item, but it’s merely used as a point of comparison, a component of signposting once they’ve picked out what they’re looking for.

I think there’s a middle ground to be had here. With an item-centered experience, the small businesses DoorDash aims to help are de-emphasized in a way that could be destructive: they could become faceless sellers, disintermediated from the selection experience entirely. This isn’t something that aligns well with DoorDash’s aim and also removes the restaurant as a signal of quality, so it’s not a viable move to shift completely to this model. So how can we utilize the advantages of both an item-centered approach (speedier ordering, sharper search results, and item-level signposting) and the restaurant-centered approach (better for browsing, better for discovery, better for our restaurants) in some sort of hybrid model?

Here are the rules that oriented my approach:

1. When displaying item listings, provide important context about the restaurant providing the item. We don’t want to make the businesses we serve faceless entities. For any item we want to provide that information as more signposting that will help ease the selection process.
2. Item listings should be actionable. The magic of an itemized listing is that you can provide a shorter path to selection and ordering. When you see an item in a collection or list, you should be able to easily get it into your cart.
3. Mix items and restaurants in a smart way, but allow for refinement down to each mode individually. We shouldn’t be afraid to serve both types of result during a search, but we should build in ways to drill down into each type of result to allow for a more accurate search.

Signposting: “What’s good?”

Now that we have the organizing principle set, we can focus on a couple of the lower level problems: lack of signposting for comparing items, lack of organization of items for a more meandering process of discovery, and lack of recommendations to help guide a selection process.

Signposting: reviews

How do you figure out what’s good to eat? What’s the metric (or metrics) that help indicate and guide you as a customer? In the current DoorDash, there’s nothing except the title and the category of cuisine that can help shape how you pick what to order and where to order from. User feedback, in the form of user reviews or photos, is non-existent.

Signposting is interesting in that some signals are inherent to a given item or restaurant — it is this category of restaurant, it will take this much time to deliver — and can’t be changed based on user feedback. Other signals are quantitative and changed implicitly and explicitly by what a user does.

Here, I took a few sketches and my hunches about what’d be useful to a customer looking for a good restaurant to order from; each iteration is numbered, with #1 being the first.

When someone is looking to compare restaurants for drilling down into, they’re going to be looking at type, affordability, rating, and delivery speed. Gathering and displaying type information is easy, it’s all the descriptive information that the restaurant provides itself. Normally, average cost is something decided by the restaurant or explicitly set from user feedback. One cool thing DoorDash can do that others can’t is provide calculated average selling price from the orders that each restaurant fulfills. That means we’re providing a more accurate gauge of affordability, and a shorter step in either the restaurant signup or user feedback process. That’s a win.

Going through this, I wanted to figure out what our key comparison metric was for user feedback, and how we would represent it as signposting. Initially in sketch #1 above, I had a vague “satisfaction score” that was displayed as a percentage. I didn’t know what exactly that measure would correspond to, and what it really indicated. Identifying the key unit of measurement here was important: when does someone provide feedback, what are they rating, and how do we prompt them?

There are a couple of options here. We can ask for feedback on the quality of an delivery (which maps 1-to-1 with a restaurant, since you can only select from one restaurant per order), we can ask for quality of each individual item, or we can ask for a combination of the two. What I first came up with is on the left: when an order completes, you receive an email with your receipt, and the next time you open up the DoorDash app, you’ll see the feedback view from your last delivery (if you haven’t rated it already via the web user feedback interface from the email receipt). Like Uber or Lyft, DoorDash has a clear view on the state and process of delivery, and knows when it’s completed, and has the ability to present a request for feedback at very apt times.

And a good question to ask is: will user feedback be most accurate immediately after completion of delivery, or after some other time? Unlike an Uber, for example, the DoorDash experience doesn’t quite end once a delivery is fulfilled: you still have to see your food and eat it before you can say whether the experience was good. One way Amazon takes user feedback for an order is by staggering a request for feedback a few days after delivery — it gives you a chance to actually use the thing you ordered and see if it suites you. For DoorDash, we could stagger the request for feedback as well on a shorter timescale, since (good) food doesn’t last very long after delivery. So waiting to ask for feedback (via email receipt, or a push notification to prompt you to return to the app), in a half-hour after delivery, should be appropriate.

In the scheme above, each order has a rating, and each item from an order can have a rating as well. This takes advantage of that fact that items can have signposting as well, for when they’re displayed individually or as items within a menu of a restaurant.

Signposting: Photos

One key thing missing here is photos. Photos of each restaurant, while good indicators of quality and category, are less necessary for DoorDash listings because a customer won’t be going to the physical place — there’s a disconnect between what’s shown and what a customer will experience. One thing to consider: on the restaurant side, owners might prefer to have pictures of their locations to entice customers on DoorDash to come visit in person; just another reminder that we’re designing for more than just the customer ordering their food, we’re designing for the customer who’s using our service to help enable them to offer delivery. If we can keep the quality of both sides of that relationship high and improving, then a design decision like the one above is more easily justifiable.

Something possibly more useful would be to display a collection of photos of delivered items — these are the kind of things you’ll get when you order, and the photos of those things are perceived as a good indicator of their quality.

An initial interaction is to the left. A horizontal carousel of photos for items served by the restaurant is displayed at the top of a restaurant’s details page. Tapping on a photo will expand it and display information about the item — you can even add the item directly to your cart from that view.

A huge question that we haven’t touched on yet: where do we get these photos? On one hand, we can request this during the user feedback process. People like taking pictures of their food, right? Well, one issue is that food packaged for delivery might not be very attractive looking; there’s less of a incentive to take a picture, and less of an impact on someone scrolling through images of food presented in a utilitarian way. So, I’d recommend requesting restaurants to provide photos of each of their dishes. More work on their end, but a much better experience on the customer-side.

Signposting & Item Discovery on Restaurant Page

We’ll start moving towards the homepage and the center of search and discovery. Before we head out, I’ll point out some lessons and improvements from the rest of the signposting section applied here on the restaurant page:

There’s a couple of important things to note here. In the current version of DoorDash, restaurant pages are sparse, and act as the root of a menu — you work your way down through different categories and sections until you hit an item, which you then tap to configure (even if the only thing to configure is special instructions for preparation) and add to your cart. Here for any item being selected, unless there’s a set of options to modify an item, we’ll just add it immediately to a customer’s cart, instead of breaking their context and sending them to a configuration screen for every single item even if its not needed. Throughout the page, more static details are presented, more signposting is available, and people can even add a restaurant as a “favorite”. This can enable super quick ordering, as we’ll put access to these favorites on the main discovery homepage.

With an increased focus on providing easier access to the items that you’re looking for, we’ve added an auto-curated section within each restaurant page that presents a couple of the items that we recommend. The mechanism for picking and ordering these items is left undefined — “Top items” is just a label that doesn’t indicate much. There are numerous recommendation strategies that could be presented at that pages, and each could be presented to a specific customer or a subset of them. One example that could be used is a strategy primed for batching like items together into a single delivery run for a courier or a production run for a cook. Say DoorDash has just taken in an order for a “Chocolate Croissant” from Mayfield Bakery in Palo Alto. Someone else is looking at Mayfield’s page: what we’ll do is present “Chocolate Croissant” as a top item for anyone visiting that page within a certain time period prior to pickup of the original order. We may even present the item with a discount to encourage customer to add it to their order. Regardless, the specific algorithm for selection isn’t important. The introduction of algorithmically generated lists of items or restaurants as ways to increase operational efficiency and customer selection as a key navigational element of DoorDash’s discovery process is the most important thing to take away.

So. That’s the signposting strategy.

Discovery: browsing & search

Now that we have the foundational elements in place, we can talk a bit about discovery. How do you find what you want, when you’re somewhere on the spectrum between “I know exactly what dish I want” and “It’s 6pm, I’m tired, and I’m looking for something nice and spicy”? It’s a tough nut to crack. Whole swathes of companies have risen and fallen trying to solve this problem, and it’s certainly not one solved with any finality at this point.

That said, I’m a big fan of the approach and execution of Foursquare: there’s a simplicity and accuracy to their tip-based, token-extracted search model. “What the heck does that mean?” I hear you say.

Let me explain:

Foursquare is uncannily accurate and able to find something desirable, even if the user is starting from a fuzzily described starting point. It’s search is flexible, powerful, and contextually sorted — it knows what you like (based on your check-ins, tips, selected tastes) and can float those results that fit well to the top.

Foursquare’s accuracy is built on the mountain of tips and check-in that it’s gathered over the years; it is highly unlikely that you could replicate the execution of a system like this without a lot of patience and an excellent strategy to encourage an unusual amount of reviews to be added (*cough* competing for mayorships with friends *cough*). For item level reviews, this could be even harder to get good tip coverage. Very few people I assume (danger!) will rate more than one item in their order. So how can we bring a more effective DoorDash search experience knowing this?

Halfway there with item-by-item descriptions

The key thing that DoorDash has that Foursquare doesn’t is, again, knowledge of the items being sold through its system. It has descriptions of what these things are, data on how well these things sell, and knowledge of who buys them. Every time that someone uses DoorDash, they provide more context about the shape of what they could like in the future. This predictive quality is useful for recommendations, and the item-by-item descriptions of items being sold in the system can be used to construct a scheme for effective searching.

One key thing to understand here is the possibility to use the information given at the restaurant level (type of cuisine, name of restaurant, average restaurant score) to map and surface item results, and information given at the item level could be use to surface and find restaurants that fit the search. For example, say you know of a wonderful place that serves lots of delicious ramen, and lots of orders for its different ramen has been delivered through DoorDash. It doesn’t have “ramen” in its name, it doesn’t have ramen in its description, and there’s no information on the restaurant level that it sells ramen. However, we know, as DoorDash, that it sells dishes with “ramen” in their titles, how many of those dishes it lists, how good those dishes sell, and how well those dishes get rated. With those signals, we can relate a query with a restaurant based on the information its inventory of items provides. And it goes the other way as well: search for “thai noodles”, and you should be presented not just with restaurants categorized as “Thai” and serving dishes with “noodles” in its name or description, but also with direct links to those dishes, even if they’re not directly tagged as “thai” cuisine — they simply inherit their type information from the restaurant that sells it.

Here’s some of those ideas in mocked-up form:

Here, we have the search results screen; anytime you do a search, you get a set of items and restaurants that map to your query, using the scheme from above. When you tap into each section, you can filter down into just the matching category: just items or just restaurants. For the restaurants section, we’ll have more results on this initial page, since they’ll be below the fold. For items, we’ll display more information about the restaurant providing the dish for sale: the logo will be in small in front of the selected photo of the dish, and the name of restaurant will be presented below the title of the dish.

On these search pages, we’ll provide filtering controls that allow you to narrow down and exactly the food you want, and at the place and time that you need it. You can select a saved address to be delivered to, or you can go add a new address (defaulting to your current location). We also provide the ability to filter by the average pricing of a restaurant.

Each of these selectors (for location, time, and filters) are displayed in a dropdown interface that preserves the context of the search, and a large, tappable surface (the dark overlay) that can be tapped to easily return to the search. It is more connected spatially with the element and action that triggered it’s opening, and in turn enables a short reach to select any of the options presented— unlike a standard UIActionSheet that appears from the bottom of the screen.

The dropdown interaction described above is easier to grok once you’ve taken a moment to watch it being played with, or played with it yourself. I’ve embedded a video below for you to check it out.

All of the prototypes presented here were built with Framer.js — it’s my tool of choice for software prototyping (particularly of the mobile variety) at the moment. It’s important to note what the point of using these tools is: I’m trying to communicate to you, dear reader, and to communicate an interactive experience, it’s not very helpful to just throw you static mockups and a textual description. So why Framer, against the field of other tools like Origami (Quartz Composer), Form, Pixate, et cetera? The point of this prototyping is to communicate as efficiently through as close an approximation as possible, and there’s a careful balance to play between using the right tool for the job and the right tool for you as the prototyper — if you can build something fast that communicates well what you aim to say with any particular tool, then use it. I know how to code (I studied and still practice as an engineer) and I can communicate what I want to with Framer. So it’s my comfortable spot, and it doesn’t limit what I want to say (or hasn’t so far).

So, in summary on the search experience:

1. Find items and restaurants based on connected properties. Find restaurants and items based on the more than just the names and descriptions of each — each item can be found with partial phrase matching on any of the properties of the restaurant that owns it, and each restaurant can be found based on the names and descriptions of the items that are part of its inventory.
2. Both items and restaurants are surfaced in search results. Whenever you make a search request, you’re not restricted to just looking for a place to order from. You can search and find exact items that could satisfy your query. Easier access to adding these items to your cart makes it much easier to get an order started.
3. Provide sharper tools to help you find exactly what you want. The addition of filters for price and category make it easy to narrow the search space for something you want. Improving the modification of delivery location and setting of delivery time filters makes it easier to set the context for your order.

Browsing, recommendations and guided access

Search is a sharp tool for when you have a good idea of what you want. For every other instance, when you’re more unsure of what you want and browsing around for something, we need to provide guided access in recommendations of various types:

1. Recommendations algorithmically generated from past preference. We can present items or restaurants that are found based on past rating on items, saved favorites, past orders, and the likelihood you’ll rate the recommendation highly.
2. Recommendations based on context, like current time of day. If you’re on DoorDash, we should present you with a way to access the most relevant results as soon as possible — and one easy way of doing that is to present the categories that are most relevant to you. We can present based on time of day (for instance, “best breakfast” as the first category you see), and then show other categories that we find as relevant to you: eat a lot of Southern food, and have provided good ratings for what you’ve ordered in the past? We’ll feature that category.
3. Recommendations provided to encourage operational flow. For example, we can provide recommendations for items or restaurants that can encourage batching for cheaper orders (the Lyft Line model of delivery discounts).
4. Recommendations as an additional revenue model. The homepage, and the recommendation model used in it, can provide another revenue model for DoorDash: promoted recommendations for restaurants and items. This could even be extended to search results, though I haven’t taken that step in this set of iterations.

A lot of interface design can be broken into system design — creating elements of functionality that can be composed and re-applied in different contexts, all working harmoniously without redundancy. How do you design these system components and make sure you can apply it wherever you need it? Here, each recommendation presents an item or restaurant (using the same elements from search), an explanation for why it’s being presented, and a badge that shows more information (like the discounted price) or an identifier of what type of recommendation it is.

To the left, you can see how you can scroll through these recommendations, and also see category recommendations at the top of the search homepage. You can drill down into a listing of all the categories, and see even more recommendations by tapping at the bottom of each section. When you drill into a category, you’re presented with a search on just the given category. On the right side of the navigation bar, you can access your faved restaurants for easy ordering.

The search homepage is the starting point of all orders, so it has to accommodate both overarching contexts with which it’ll be used: specific searching and imprecise browsing. By offering this gateway that can guide with recommendations and assist searching with easily adjusted filtering, I hope this discovery experience can help prop up that first step in the search-order-eat experience that DoorDash aims to provide.

Sequencing and success metrics

One aspect of the product development process that designers often neglect to talk about is the sequencing of the building of their designs. How do we take a high level initial recommendation, like the one presented here, and translate it into a working product? A lot of that is about sub-dividing the large logical chunks into workable sets of changes that have corresponding dependencies. What I mean is that you need to understand which parts of the experience can be built out first because they don’t rely on other parts of the experience already existing. The easy first step for the set of designs from above is to build and launch reviews and feedback gathering first. To provide the data needed for signposting of restaurants and items, we need to build up a corpus of data, and releasing the mechanism to gather all that first, a few months to half year before releasing anything else, is absolutely necessary. Once that’s in place, rolling out a nicer search and discovery experience becomes a tractable problem that can be released in shorter intervals.

Another thing too often neglected during in the product design phase is a way of measuring the success of a solution. Some changes don’t necessarily require the tracking of a “metric of success”, but for many design decisions building off of an existing product, it can be a good source of intuition to base further changes on. For this project, the biggest metric I’d be looking to track would be average-time-to-order and an associated rating-per-minute-ordering . The designs suggested above are all aimed to get you food that you’ll enjoy in a timely-and operationally efficient manner. If we can reduce the overall average time to make an order, and increase the quality of those orders at the same time, then that would be a strong indicator that we’ve achieved what we set out to do.

Caveats and conclusion

Doing design as a third party, even with access to a little bit of internal knowledge and data as I did, can be frustrating. This mode of operating, where these decisions are made from a place where inferences have to be utilized in place of the full body of data, are always going to be shadows of what a fully-integrated process would entail. It’s harder to work through different iterations and paths without the feedback (quantitative and qualitative) that is necessary to understand how to steer course. These are shots in a dim room, well intentioned, but necessarily lacking a fine clarity that’s derived from more iterations directed by shorter feedback loops.

On the flip-side, these kinds of exercises are useful for quick learning — taking this time over the last couple of days to work through a broadly-defined problem like this, has given me a sense of how DoorDash sees the world, and how it must operate and design. The company is in a special position, working on a hard infrastructure and operations problem, and in turn enabling an elegant ordering experience for its customer — all the while also providing a reliable and economical fulfillment experience for the restaurants it serves. The question I had to face was: how can we take this radical focus on efficiency, process design, & simplicity, and apply it to the previously lacking search and discovery experience?

And this article (and all the artifacts attached) is what I came up with. It’s just a start, iteration #1 in a long tree of attempts and explorations (if I had access and time to help the company in a more thorough capacity). The ideal design process would have been a tree of stops and starts, each built on knowledge gleaned from the last branch of attempts, and I didn’t have the access to data (quantitative and qualitative) needed to run that ideal process. That’s the kind of process we need to do great design: a series of small steps, well considered, all moving towards something a little better, with no fear to back track and say that an idea was wrong, and to reorient in another direction accordingly. Deciding, intentionally, how something should be and learning from every decision along the way.

Pixel by pixel, word by word.

Designing Search for DoorDash was originally published in Work In Public on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, Uber released a small marketing page promoting their UberTeacher initiative: recruiting and highlighting the stories of underpaid teachers around the US who, to scrape by with their meager wages, are forced to find another job like driving for Uber.

The Awl even wrote a post highlighting the tone-deafness apparent on the page:

The problem with Uber self-seriously announcing that it “provides teachers with the flexibility and opportunity they need to continue creating a foundation of excellence for students across the country” is ultimately a matter of tone, not the literal fact that teachers are using Uber to supplement their incomes.

If I were writing for (and running) Uber, this is what I would say:

As communities are heading back to school, we’d like to take a moment to talk about the educators who are also our Uber partner drivers. Whether it’s an afternoon shift or a summertime gig, partnering with Uber provides teachers with the flexibility and opportunity they need to earn living wages and help provide for their families, and we’d like to thank them for choosing to work with us.

Every day teachers are asked to do more with less, constantly faced with new challenges and limited resources. In a society that undervalues the impact of educators, we know our service is one way for them to make a better living. In no way does this solve the larger problem, but we hope our contribution can help individuals in small, real ways, as we pour resources into legislation and lobbying that will help improve their situation as a whole. No one should be forced to work a second job to be able to earn a living, and we understand that. We’re working our hardest to make sure this situation is temporary, and providing help while it’s still an issue.

We want to support politicians like Governor Pat. McCrory in North Carolina who understand the problem at hand, and are fighting for change in Washington. Anywhere we operate, we will support initiatives that incentivize and reward teachers for their hard, oft overlooked work, while reducing the need for them to seek out secondary incomes like driving for us.

“Teachers, in general, need a little bit more money. With Uber, I get to pick when I want to drive and how much money I want to bring in. I can be a great teacher and make both happen.” — Jenny Hochmiller, High Tech Early College

Teachers are wonderful leaders in a community, and we know the influence they can make in the lives of our children — and it’s a terrible reality that they are woefully underpaid and overworked. We hope providing flexible, part time work can allow them to worry less about wages and focus more on the students they nurture and educate.

“I’m a criminal justice instructor and deputy sheriff – not to mention a father of two girls. As a driver with Uber, I see first hand how Uber takes safety to the next level.” — Corey Watson, Colerain High School

We’re doing everything we can to help educators — the guardians of our children, under appreciated and underpaid — provide a solid living for their families, while we fight and fund against the abhorrent situation they’re under in our society today. These posts will highlight their stories and our approach to amending this situation.

The long term goal for Uber is to build a transportation system for the future, one that can be used by anyone, anywhere to transport themselves or their belongings to any other place, without the financial, environmental, and social costs that plague our own-your-own-car society today.

We’re constantly working to build a future without the problems people face right now. We know that if we don’t take a look at all the issues, we’ll miss the forest for the trees. So we’ve decided that the financial well being of the people we employ as our drivers today (and everyone else who’s chosen to work with us to earn what they need to survive) is a serious, complex problem that needs to be addressed from a legal, social, and technological level. We have the resources to help provide a future where wages are fair and livable, and no one has to work multiple jobs to live comfortably.

So we’re going to do everything to make that reality our destination.

Maybe in another life, Uber would write this.