Season 3

|

Episode 10

Defining the visual language for DoorDash

Kathryn Gonzalez

First Designer @ DoorDash

Dec 14, 2023

Dec 14, 2023

|

45 min

45 min

music by Dennis

About this Episode

In this episode, Kathryn Gonzalez walks us through how she built the DoorDash design language as the first designer and frontend engineer. We talk about what it's like designing for a 3-sided marketplace, how to figure out the right level of craft for your product, and get an inside look at how DoorDash structures their design system.

Kathryn spent almost 7 years at DoorDash and eventually became the Head of Design Infrastructure so this episode is chalk full of wisdom ✨

Share on Twitter
Share on Twitter
Share on LinkedIn
Share on LinkedIn

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers πŸ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Free lessons from πŸ‘‡

Lauren LoPrete

Lead designer @ Netflix

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers πŸ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Transcript chapters

Early days at DoorDash

I came from a much smaller startup, a five person company out of Boston called Fetch Notes that, , had ultimately failed and shut down. , and so coming to, , a company like DoorDash, which at, the time they had just raised their series B.

and they were relatively large compared to what my experience had been at the time. And there were eight other engineers and the company overall was 35 and 40 people. I was just super excited and to work with a group of folks , interested and excited about building a consumer product and was mostly excited to learn from them because I was, , pretty early in my career at that point.

think those early days were for me, you know, kind of coming into it, thinking this was a big startup or a big company that was very successful sort of seeing that, , even at that stage, there's still a lot that we [00:01:00] were figuring out. You know, we, , didn't have a fully realized design team.

I was the first full time product design hire, first full time front end engineering hire, , but we had a design intern and our co founder did some design, but. All of it was very kind of ad hoc and, , unstructured. And there's still a lot that we're figuring out about what it is that we needed to build as a company.

And so I think, you know, being, , able to jump into the chaos, just work on lots of different things. Like working on the consumer product I think my first project there was figuring out how do we make, , tracking an order and the status of it, , as easy and trustworthy as possible, , while also, , finding problems in very different spaces, like working on how.

Our internal team build menus for restaurants, and building a very complex and crazy internal tool, being flexible and having lots of different spaces. I was playing in to, you know, both [00:02:00] learn about the product that we were building for, the outside world, but also helping our teams be more efficient.

I think that was, you know, a learning that. I've carried through in my career at DoorDash in the sense that, you know, I built a lot of things for the internal teams to be more efficient in building our product, but then also had a lot of influence in terms of what it is we actually like shipped to everyone that orders the burger on DoorDash.

You said a pretty interesting phrase there, which is finding problems. And I think that's pretty true of first design hires, where it's not like you're being handed these polished PRDs where it's like, solve this problem. Okay. Then solve this problem and solve this problem. You kind of have to be the person that does seek out what problems make sense to solve and how to allocate your time.

So can you drill into that a little bit more? Like, what did it look like to be someone who found problems as a designer?

Early days at DoorDash

I came from a much smaller startup, a five person company out of Boston called Fetch Notes that, , had ultimately failed and shut down. , and so coming to, , a company like DoorDash, which at, the time they had just raised their series B.

and they were relatively large compared to what my experience had been at the time. And there were eight other engineers and the company overall was 35 and 40 people. I was just super excited and to work with a group of folks , interested and excited about building a consumer product and was mostly excited to learn from them because I was, , pretty early in my career at that point.

think those early days were for me, you know, kind of coming into it, thinking this was a big startup or a big company that was very successful sort of seeing that, , even at that stage, there's still a lot that we [00:01:00] were figuring out. You know, we, , didn't have a fully realized design team.

I was the first full time product design hire, first full time front end engineering hire, , but we had a design intern and our co founder did some design, but. All of it was very kind of ad hoc and, , unstructured. And there's still a lot that we're figuring out about what it is that we needed to build as a company.

And so I think, you know, being, , able to jump into the chaos, just work on lots of different things. Like working on the consumer product I think my first project there was figuring out how do we make, , tracking an order and the status of it, , as easy and trustworthy as possible, , while also, , finding problems in very different spaces, like working on how.

Our internal team build menus for restaurants, and building a very complex and crazy internal tool, being flexible and having lots of different spaces. I was playing in to, you know, both [00:02:00] learn about the product that we were building for, the outside world, but also helping our teams be more efficient.

I think that was, you know, a learning that. I've carried through in my career at DoorDash in the sense that, you know, I built a lot of things for the internal teams to be more efficient in building our product, but then also had a lot of influence in terms of what it is we actually like shipped to everyone that orders the burger on DoorDash.

You said a pretty interesting phrase there, which is finding problems. And I think that's pretty true of first design hires, where it's not like you're being handed these polished PRDs where it's like, solve this problem. Okay. Then solve this problem and solve this problem. You kind of have to be the person that does seek out what problems make sense to solve and how to allocate your time.

So can you drill into that a little bit more? Like, what did it look like to be someone who found problems as a designer?

Seeking out the right problems to solve

I think one of the things that is very true and is a core value that we [00:03:00] like took forward at DoorDash was the idea that, you have to see your role and what you're doing as someone that is owning the product, that is owning the outcomes of what we're all, you know, building here as a business. one of the traits that, , all the early engineers and designers had at DoorDash was.

Um, having a strong sort of product sense and not just like thinking about being the builders of what the solution was to those product problems, but being out in the field, actually trying to understand what those challenges are. So, for instance, at Doordash actually, uh, every employee does deliveries.

They have to actually like go out in the world and see what the challenges are for a Dasher and sort of same thing for other spaces. So for like our merchant products, you know, one of the things that I learned helping start up that. , side of the business was, had to go into the restaurants and figure out what is the [00:04:00] craziness of the workflow that they're dealing with to be able to actually take in lots of orders, fulfill those orders, work with the in restaurant customers, and then also manage their staff as they're coordinating all of this, getting a sense of that and being close to the people that have the problems, having an instinct to then take that insight Into the product and then build it because you're the designer and the engineer too. I think that's something that is a superpower for people that are in those early stages.

And you're definitely a unicorn I've never met someone who was hired as both the first part designer and the first front end engineer. Can you talk a little bit more about how that breakdown worked in practice in the early days? Like how much time were you spending in a design tool versus actually shipping code?

Seeking out the right problems to solve

I think one of the things that is very true and is a core value that we [00:03:00] like took forward at DoorDash was the idea that, you have to see your role and what you're doing as someone that is owning the product, that is owning the outcomes of what we're all, you know, building here as a business. one of the traits that, , all the early engineers and designers had at DoorDash was.

Um, having a strong sort of product sense and not just like thinking about being the builders of what the solution was to those product problems, but being out in the field, actually trying to understand what those challenges are. So, for instance, at Doordash actually, uh, every employee does deliveries.

They have to actually like go out in the world and see what the challenges are for a Dasher and sort of same thing for other spaces. So for like our merchant products, you know, one of the things that I learned helping start up that. , side of the business was, had to go into the restaurants and figure out what is the [00:04:00] craziness of the workflow that they're dealing with to be able to actually take in lots of orders, fulfill those orders, work with the in restaurant customers, and then also manage their staff as they're coordinating all of this, getting a sense of that and being close to the people that have the problems, having an instinct to then take that insight Into the product and then build it because you're the designer and the engineer too. I think that's something that is a superpower for people that are in those early stages.

And you're definitely a unicorn I've never met someone who was hired as both the first part designer and the first front end engineer. Can you talk a little bit more about how that breakdown worked in practice in the early days? Like how much time were you spending in a design tool versus actually shipping code?

Balancing time between designing and coding

sort of treated those two sides of, you know, my skillset as two different jobs at DoorDash. during the day. I would focus primarily on [00:05:00] product design work, where, you know, product design at the time we were building, , mockups and sketch and like writing docs to sort of, , clarify our ideas.

, but we also were. Working either super closely with the engineers on, like, you know, the, , work that they were building, to get to that level of, quality and, and fidelity of the design,

and then on the opposite side, there is a lot of front end engineering work that was more disconnected from, , the actual product and the design work that I did during the day. a lot of infrastructure work, for instance.

like building out the foundation that all of, you know, the other engineers that were more full stack, not as front end savvy, not as design oriented.

, you know, could build on top of to get to that level of quality that, you know, we wanted to, , get DoorDash to eventually, that was something that was exciting for me. I also want to recognize that it's. Definitely one of the things that is [00:06:00] unsustainable part of the whole premise for me, , you know, being a full time design technologist after a couple of years at DoorDash was the fact that I couldn't play both of those roles and still live a balanced life.

And so I needed a role that actually brought those 2 things together in a way that was more structured and official. That's how I managed it. , but it's something that was definitely a unique and, um you know, high growth sort of experience for me.

I want to go super deep on this infrastructure and design language piece of the puzzle, because I think you have a really unique perspective as someone who laid the foundation for, you know, a billion dollar company and their visual language, and you can wear both the design and the technical hats. So maybe as kind of a context, so we really understand what it was like, can you maybe describe. The state of affairs when you first joined and started actually shipping code, because I think a lot of [00:07:00] people hear this, like, well, there was kind of a design co founder and there's a design intern. There's eight engineers and 40 people and no full time designer. And that to me is like, oh, gosh, like, what was the state of.

Design and the front end. Can you talk to us a little bit about what you inherited? And then at what point did you actually decide, you know what, I'm going to start investing in things at the infrastructure level.

Balancing time between designing and coding

sort of treated those two sides of, you know, my skillset as two different jobs at DoorDash. during the day. I would focus primarily on [00:05:00] product design work, where, you know, product design at the time we were building, , mockups and sketch and like writing docs to sort of, , clarify our ideas.

, but we also were. Working either super closely with the engineers on, like, you know, the, , work that they were building, to get to that level of, quality and, and fidelity of the design,

and then on the opposite side, there is a lot of front end engineering work that was more disconnected from, , the actual product and the design work that I did during the day. a lot of infrastructure work, for instance.

like building out the foundation that all of, you know, the other engineers that were more full stack, not as front end savvy, not as design oriented.

, you know, could build on top of to get to that level of quality that, you know, we wanted to, , get DoorDash to eventually, that was something that was exciting for me. I also want to recognize that it's. Definitely one of the things that is [00:06:00] unsustainable part of the whole premise for me, , you know, being a full time design technologist after a couple of years at DoorDash was the fact that I couldn't play both of those roles and still live a balanced life.

And so I needed a role that actually brought those 2 things together in a way that was more structured and official. That's how I managed it. , but it's something that was definitely a unique and, um you know, high growth sort of experience for me.

I want to go super deep on this infrastructure and design language piece of the puzzle, because I think you have a really unique perspective as someone who laid the foundation for, you know, a billion dollar company and their visual language, and you can wear both the design and the technical hats. So maybe as kind of a context, so we really understand what it was like, can you maybe describe. The state of affairs when you first joined and started actually shipping code, because I think a lot of [00:07:00] people hear this, like, well, there was kind of a design co founder and there's a design intern. There's eight engineers and 40 people and no full time designer. And that to me is like, oh, gosh, like, what was the state of.

Design and the front end. Can you talk to us a little bit about what you inherited? And then at what point did you actually decide, you know what, I'm going to start investing in things at the infrastructure level.

Investing in the infrastructure level

one of the things that was interesting coming into it is that, starting first from the design side, I think we were still very early days and. sort of knowing what the best experience was for, the consumer side and, you know, we hadn't even started building, , robust tools for some of our merchants and we had a very bare bones.

, product for dashers, which was actually the first, , product that like, , the company had built. Surprisingly, we didn't start with a consumer first product. We started with our dasher product to build a logistics network to then actually fulfill deliveries, [00:08:00] which we were just getting over the phone in the early days.

The founders were, seeing that, , the consumer side and the merchant side and the dasher side were still relatively early in their, , sort of design and visual language, our brand hadn't really been, matured and built. We, had an early stage idea of, you know, what DoorDash, , , was supposed to be for people, but we didn't have, , really strong or coherent narrative yet of, what we were, aiming for in the far future, there is still a lot that we're figuring out.

And it took a lot of the time between, you know, when I joined in 2015 to when I. Focus on building a real and full design system in 2017 for us to have more of those questions answered. on the technical side, I think 1 of the things that was very true is because there wasn't a strong front end engineering lead on the web.

There was. A lot of different tools that we, , use to build our product. [00:09:00] for all the people that were there in that era of, , web development, we were using things like backbone and bootstrap and angular and all of mixes of other tools in a way that wasn't. , tied together, and it wasn't, super coherent and productive for, the kinds of engineers that we would need to start hiring.

Because at the time, we only had, you know, full stack engineers that were. More backend oriented, more product oriented, they didn't necessarily have the sort of technical background or, I to get the level of quality on the front end side we really wanted as a company, especially as we were building our consumer product.

Did you have to justify that value? Like, was it obvious that that was something that you should work on? And how did you balance new feature work versus these investments into like the underlying visual language and front end infrastructure?

I think [00:10:00] one of the things that was interesting is because of my. split job title, where my official role and what I was hired for at DoorDash was actually just primarily product design, but I ended up taking on this additional role outside of it, , in a more unofficial capacity. I had more freedom and leeway to, , focus on the infrastructural side, , in that, , sort of extra time that.

I gave myself, you know, doing the work at DoorDash, and my day job was still focused on product design and feature related kind of work. that was how I found the space to do it. I think one of the things that I would say for someone that's, you know, not willing to, blow up their work life balance by doing something as crazy as that, is that, There is, ways to, , sell and scope infrastructure work in a way that, is not going to be like a [00:11:00] cost that a founder or an executive is going to.

you know, say outright is not worth investing in. I think there's always a version of an infrastructural change or a process or cultural change that you can scale back to something that is worthwhile and, you know, relatively easy to implement. , that I think, , an executive that sees that long term vision from you, , is willing to invest in.

and and I really. you know, would prefer someone think, , in more of those terms to be able to, take the smaller steps to get to the right place versus, pitching, I'm just going to do infrastructure work for the next 6 months. That usually doesn't. Work in your favor.

And also, I think, doesn't give you the space to, know exactly what is the right part to start on and what is the right thing to, , sort of then iterate from.

Investing in the infrastructure level

one of the things that was interesting coming into it is that, starting first from the design side, I think we were still very early days and. sort of knowing what the best experience was for, the consumer side and, you know, we hadn't even started building, , robust tools for some of our merchants and we had a very bare bones.

, product for dashers, which was actually the first, , product that like, , the company had built. Surprisingly, we didn't start with a consumer first product. We started with our dasher product to build a logistics network to then actually fulfill deliveries, [00:08:00] which we were just getting over the phone in the early days.

The founders were, seeing that, , the consumer side and the merchant side and the dasher side were still relatively early in their, , sort of design and visual language, our brand hadn't really been, matured and built. We, had an early stage idea of, you know, what DoorDash, , , was supposed to be for people, but we didn't have, , really strong or coherent narrative yet of, what we were, aiming for in the far future, there is still a lot that we're figuring out.

And it took a lot of the time between, you know, when I joined in 2015 to when I. Focus on building a real and full design system in 2017 for us to have more of those questions answered. on the technical side, I think 1 of the things that was very true is because there wasn't a strong front end engineering lead on the web.

There was. A lot of different tools that we, , use to build our product. [00:09:00] for all the people that were there in that era of, , web development, we were using things like backbone and bootstrap and angular and all of mixes of other tools in a way that wasn't. , tied together, and it wasn't, super coherent and productive for, the kinds of engineers that we would need to start hiring.

Because at the time, we only had, you know, full stack engineers that were. More backend oriented, more product oriented, they didn't necessarily have the sort of technical background or, I to get the level of quality on the front end side we really wanted as a company, especially as we were building our consumer product.

Did you have to justify that value? Like, was it obvious that that was something that you should work on? And how did you balance new feature work versus these investments into like the underlying visual language and front end infrastructure?

I think [00:10:00] one of the things that was interesting is because of my. split job title, where my official role and what I was hired for at DoorDash was actually just primarily product design, but I ended up taking on this additional role outside of it, , in a more unofficial capacity. I had more freedom and leeway to, , focus on the infrastructural side, , in that, , sort of extra time that.

I gave myself, you know, doing the work at DoorDash, and my day job was still focused on product design and feature related kind of work. that was how I found the space to do it. I think one of the things that I would say for someone that's, you know, not willing to, blow up their work life balance by doing something as crazy as that, is that, There is, ways to, , sell and scope infrastructure work in a way that, is not going to be like a [00:11:00] cost that a founder or an executive is going to.

you know, say outright is not worth investing in. I think there's always a version of an infrastructural change or a process or cultural change that you can scale back to something that is worthwhile and, you know, relatively easy to implement. , that I think, , an executive that sees that long term vision from you, , is willing to invest in.

and and I really. you know, would prefer someone think, , in more of those terms to be able to, take the smaller steps to get to the right place versus, pitching, I'm just going to do infrastructure work for the next 6 months. That usually doesn't. Work in your favor.

And also, I think, doesn't give you the space to, know exactly what is the right part to start on and what is the right thing to, , sort of then iterate from.

How to find the right level of craft

Like this strand. So let's drill into this because I think you have a really interesting [00:12:00] experience. You can see things from all the different angles, but I also think your situation is pretty unique. Like probably not a lot of people that are listening to this are. Owning all of the design and all of the front end for an early stage startup.

And so maybe we can even abstract some of your lessons and speak to people who are working on smaller design teams and they're considering some of these things and they just don't really have a lot of the answers. And so I have a few topics that I'd love to get your take on for a younger company, whether or not they're, you know, a startup, like smaller team.

how do you think about how far design should push the level of craft and attention to detail, because there's this spectrum of like, linear and all the things that we celebrate on design Twitter on one end, and then the other, it's just solve problems. This is Vicodin, not vitamins.

How are you thinking about that for DoorDash and then maybe any higher level lessons that you think you could share for other people in a similar scenario?

I think 1 thing [00:13:00] to say in terms of, you know, what, where is the responsibility really lie? I think for the, Yeah. Companies that we admire, for instance, like linear, as, as you mentioned, I think it is a cultural, , underpinning of who they are as a company and as a business, , that makes them able to invest in design and craft and quality at the level that they do.

there are just some companies and some businesses and business models where that doesn't really make sense. And I think like for a designer. Or an engineer that is hungry for that, , sort of level of craft to be what they work towards and aspire to. And they see around them every day. , I think that is an important thing to understand is not every company is going to be able to give you that.

When I think about that responsibility at DoorDash, one of the things that was, important is, Our business, you know, primarily is focused on, do we give people [00:14:00] the selection of restaurants and nowadays groceries and retail and all those things that they want?

Like, that is one of the most important things that, you know, matters. Can we do it in a way that is reliable and high quality? Like, does the food actually get to me? And like, do I trust DoorDash when they say it's going to be here in five minutes? that's the second most important thing. And the third most important thing is, you know, is it something that provides enough value for me and is cost efficient for me?

those are all things that I think when I think about design quality, , or like the craft of what we're building, , some of those things aren't necessarily going to be affected primarily by design. So for instance, there's a level of trust that you're building with the product. That you're designing and and that really that speaks to number two but a lot of what reliability means in that case is like can I accurately predict how long it takes [00:15:00] to, do a delivery and, give the right sort of expectations for our customer.

For DoorDash being able to know what is the and quality of the product that we are able to push and being able to, you push those levers. So, for instance, making sure that designers they have the tools to build high quality UI, high quality, like product for the, expectation of trust that, , our users like expect. That's something that, like, I can provide. I can also provide. , the right infrastructure for engineers to be able to, you be able to build performant, , high quality interfaces.

you know, in terms of that responsibility, I think about those are the things that are in my control that I can actually help push forward. for everything else. I need to be able to, you know, trust the people around me to, , do the best work that they can to make that craft and quality happen.

That speaks again to that idea of craft as a [00:16:00] culture. You have to, have craft in all its different senses. Present in your business and in your organization to get the level of quality in the product that, ultimately you are looking for

How to find the right level of craft

Like this strand. So let's drill into this because I think you have a really interesting [00:12:00] experience. You can see things from all the different angles, but I also think your situation is pretty unique. Like probably not a lot of people that are listening to this are. Owning all of the design and all of the front end for an early stage startup.

And so maybe we can even abstract some of your lessons and speak to people who are working on smaller design teams and they're considering some of these things and they just don't really have a lot of the answers. And so I have a few topics that I'd love to get your take on for a younger company, whether or not they're, you know, a startup, like smaller team.

how do you think about how far design should push the level of craft and attention to detail, because there's this spectrum of like, linear and all the things that we celebrate on design Twitter on one end, and then the other, it's just solve problems. This is Vicodin, not vitamins.

How are you thinking about that for DoorDash and then maybe any higher level lessons that you think you could share for other people in a similar scenario?

I think 1 thing [00:13:00] to say in terms of, you know, what, where is the responsibility really lie? I think for the, Yeah. Companies that we admire, for instance, like linear, as, as you mentioned, I think it is a cultural, , underpinning of who they are as a company and as a business, , that makes them able to invest in design and craft and quality at the level that they do.

there are just some companies and some businesses and business models where that doesn't really make sense. And I think like for a designer. Or an engineer that is hungry for that, , sort of level of craft to be what they work towards and aspire to. And they see around them every day. , I think that is an important thing to understand is not every company is going to be able to give you that.

When I think about that responsibility at DoorDash, one of the things that was, important is, Our business, you know, primarily is focused on, do we give people [00:14:00] the selection of restaurants and nowadays groceries and retail and all those things that they want?

Like, that is one of the most important things that, you know, matters. Can we do it in a way that is reliable and high quality? Like, does the food actually get to me? And like, do I trust DoorDash when they say it's going to be here in five minutes? that's the second most important thing. And the third most important thing is, you know, is it something that provides enough value for me and is cost efficient for me?

those are all things that I think when I think about design quality, , or like the craft of what we're building, , some of those things aren't necessarily going to be affected primarily by design. So for instance, there's a level of trust that you're building with the product. That you're designing and and that really that speaks to number two but a lot of what reliability means in that case is like can I accurately predict how long it takes [00:15:00] to, do a delivery and, give the right sort of expectations for our customer.

For DoorDash being able to know what is the and quality of the product that we are able to push and being able to, you push those levers. So, for instance, making sure that designers they have the tools to build high quality UI, high quality, like product for the, expectation of trust that, , our users like expect. That's something that, like, I can provide. I can also provide. , the right infrastructure for engineers to be able to, you be able to build performant, , high quality interfaces.

you know, in terms of that responsibility, I think about those are the things that are in my control that I can actually help push forward. for everything else. I need to be able to, you know, trust the people around me to, , do the best work that they can to make that craft and quality happen.

That speaks again to that idea of craft as a [00:16:00] culture. You have to, have craft in all its different senses. Present in your business and in your organization to get the level of quality in the product that, ultimately you are looking for

What it's like designing a three-sided marketplace

Did that level of quality differ depending on the product that you were designing? Cause I think DoorDash is a unique use case where you have this three sided marketplace and maybe at some point you kind of standardized the foundations where everything was at a similar baseline. But. Did you ever get to a point where you're like, man, this is the consumer app.

Like I have to sweat the details here. Whereas maybe it's a little bit different for the B2B platform or were there other differences in terms of like how you approach the design based off of who you were designing for?

totally. And I think that's part of, you know, the idea that you have to be close to the problems that are specific to, you who you're building for. And so, for instance, on the merchant side, a level of craft that maybe isn't what. [00:17:00] You would consider the traditional visual design craft that is more likely present in like the consumer side of our product or in consumer products in general, being able to recognize what is the level of sort of density and sort of information that is necessary needed.

And real time for merchants to be able to run a business, , and being successful. And, you know, as a product designer, being able to, , know, what it is I need to design to solve this particular problems. And then as a design system designer, actually provide the right, , sort of primitives that, you don't need at all on the consumer side.

So, for instance, like on the merchant side. We invested a lot in how do we think about, , data visualization and graphs and thinking about what is the building blocks that are specific to this space that are different from the other design systems work that we're doing on the consumer or Dasher side.

And let's really, invest a chunk of our time into [00:18:00] making. This, important part of the merchant experience. Great. some of the other things that, you know, are more prevalent on the consumer side and like maybe the visual richness of like the consumer product, we don't have to spend that time on merchant because it doesn't matter for merchants in that same way.

So I think that's like the level of. , consideration and thinking that's necessary as you're building a design system across like all these different spaces.

What it's like designing a three-sided marketplace

Did that level of quality differ depending on the product that you were designing? Cause I think DoorDash is a unique use case where you have this three sided marketplace and maybe at some point you kind of standardized the foundations where everything was at a similar baseline. But. Did you ever get to a point where you're like, man, this is the consumer app.

Like I have to sweat the details here. Whereas maybe it's a little bit different for the B2B platform or were there other differences in terms of like how you approach the design based off of who you were designing for?

totally. And I think that's part of, you know, the idea that you have to be close to the problems that are specific to, you who you're building for. And so, for instance, on the merchant side, a level of craft that maybe isn't what. [00:17:00] You would consider the traditional visual design craft that is more likely present in like the consumer side of our product or in consumer products in general, being able to recognize what is the level of sort of density and sort of information that is necessary needed.

And real time for merchants to be able to run a business, , and being successful. And, you know, as a product designer, being able to, , know, what it is I need to design to solve this particular problems. And then as a design system designer, actually provide the right, , sort of primitives that, you don't need at all on the consumer side.

So, for instance, like on the merchant side. We invested a lot in how do we think about, , data visualization and graphs and thinking about what is the building blocks that are specific to this space that are different from the other design systems work that we're doing on the consumer or Dasher side.

And let's really, invest a chunk of our time into [00:18:00] making. This, important part of the merchant experience. Great. some of the other things that, you know, are more prevalent on the consumer side and like maybe the visual richness of like the consumer product, we don't have to spend that time on merchant because it doesn't matter for merchants in that same way.

So I think that's like the level of. , consideration and thinking that's necessary as you're building a design system across like all these different spaces.

Thinking about parity between design<>code

What about parody between design and code in the early days? Cause I get a lot of DMS from people that are basically. Expressing some concern that there's this mounting design debt in the early days of a company. And we're just not on the same page with engineering. part of me is kind of like, well, how much does it actually matter?

And again, this is one of those things that since you can kind of see things from both sides of the table, how much were you even worrying about that in the early days? And maybe do you have a general way that you think about design debt in the early stages of a [00:19:00] company?

my pithy answer to this is embrace the chaos. I think, you know, one of, uh, the things I think it was Lauren LaPrette that, she had mentioned is that, design systems is a practice of, continually trying to reduce, uh, entropy. And as you know, anyone that's ever studied physics knows entropy always just goes up and to the right.

I really believe that is that, and it ties to this idea that design systems ultimately is a practice where you're continually, working to kind of take the reality of what exists out in the product, and trying to, , understand what is. you know, changing what is, being added as a pattern, what is a relevant sort of, a path for the design system to go down to make that product better, and making the design system kind of loosely, be able to take all those insights and then evolve itself as an independent sort of product.

Those two sides should never, you [00:20:00] know, the goal shouldn't be that they're one to one and the same thing for, you know, code and design system side of things, because the code is truly just like a representation of what the actual product is. And so being able to. as a design systems practitioner, give yourself the space to realize like, okay, it is a losing battle to try to make every single piece of this like completely one to one and like to have, for instance, the design system actually include everything that exists in the product.

That's just not. Realistic. And also I think doesn't necessarily, embody what the design system is trying to solve. There should be things that live outside of the design system. There should be things that the product, you know, being closer to our partners and to our users should have more insight on, Oh yeah, this is like a new way to do this thing that is better for our merchants job as a design system is to recognize that insight.

Recognize like that improvement, , take it back [00:21:00] into the system and then give it to the rest of the organization so that we're a conduit for growth and learning, from one small piece of the product to the organization as a whole. I think that's philosophically how I think about this tension between the difference between design and code.

But. You know, there are things that are worth trying to keep those, foundations as similar as possible, particularly like, you know, for the things that don't change as much, for the things that are, , the more underlying primitives that you end up using, more high level parts of the design system.

So things like our, , you know, tokens and all that. That, of course, should be as, , one to one as possible. But there are, , layers of abstraction above that, where you can be a little more loose with it. So, that's kind of how I think about it.

Thinking about parity between design<>code

What about parody between design and code in the early days? Cause I get a lot of DMS from people that are basically. Expressing some concern that there's this mounting design debt in the early days of a company. And we're just not on the same page with engineering. part of me is kind of like, well, how much does it actually matter?

And again, this is one of those things that since you can kind of see things from both sides of the table, how much were you even worrying about that in the early days? And maybe do you have a general way that you think about design debt in the early stages of a [00:19:00] company?

my pithy answer to this is embrace the chaos. I think, you know, one of, uh, the things I think it was Lauren LaPrette that, she had mentioned is that, design systems is a practice of, continually trying to reduce, uh, entropy. And as you know, anyone that's ever studied physics knows entropy always just goes up and to the right.

I really believe that is that, and it ties to this idea that design systems ultimately is a practice where you're continually, working to kind of take the reality of what exists out in the product, and trying to, , understand what is. you know, changing what is, being added as a pattern, what is a relevant sort of, a path for the design system to go down to make that product better, and making the design system kind of loosely, be able to take all those insights and then evolve itself as an independent sort of product.

Those two sides should never, you [00:20:00] know, the goal shouldn't be that they're one to one and the same thing for, you know, code and design system side of things, because the code is truly just like a representation of what the actual product is. And so being able to. as a design systems practitioner, give yourself the space to realize like, okay, it is a losing battle to try to make every single piece of this like completely one to one and like to have, for instance, the design system actually include everything that exists in the product.

That's just not. Realistic. And also I think doesn't necessarily, embody what the design system is trying to solve. There should be things that live outside of the design system. There should be things that the product, you know, being closer to our partners and to our users should have more insight on, Oh yeah, this is like a new way to do this thing that is better for our merchants job as a design system is to recognize that insight.

Recognize like that improvement, , take it back [00:21:00] into the system and then give it to the rest of the organization so that we're a conduit for growth and learning, from one small piece of the product to the organization as a whole. I think that's philosophically how I think about this tension between the difference between design and code.

But. You know, there are things that are worth trying to keep those, foundations as similar as possible, particularly like, you know, for the things that don't change as much, for the things that are, , the more underlying primitives that you end up using, more high level parts of the design system.

So things like our, , you know, tokens and all that. That, of course, should be as, , one to one as possible. But there are, , layers of abstraction above that, where you can be a little more loose with it. So, that's kind of how I think about it.

Building initial primitives

How early did you define things like tokens and those other primitives? Like, can we look at kind of the phases of your investment into the DoorDash design system? Like what were those initial [00:22:00] investments that you made and how quickly did you make them?

I characterize like us really starting a design system and more importantly, like the design systems practice, , being in 2017, getting to a place where some of the of resources that exist in a design system, like early styles, I wouldn't even characterize them as tokens because they weren't as robust as what tokens mean today.

I think that happened. earlier, probably in 2016. it was, a functional change for us to just have something that engineers could use without copying and pasting. And that was roughly what we used on the design side. to have that was, you know, it was a useful step, um, that ultimately, like when we started building the design system in full and building it in a way that was more robust and reminiscent of tokens as we know them today, that, , was something that we, you know, Throughout [00:23:00] and then like started over again from scratch because you know, it was not necessarily where we wanted to go But it was something that we you know had in those earlier days

Building initial primitives

How early did you define things like tokens and those other primitives? Like, can we look at kind of the phases of your investment into the DoorDash design system? Like what were those initial [00:22:00] investments that you made and how quickly did you make them?

I characterize like us really starting a design system and more importantly, like the design systems practice, , being in 2017, getting to a place where some of the of resources that exist in a design system, like early styles, I wouldn't even characterize them as tokens because they weren't as robust as what tokens mean today.

I think that happened. earlier, probably in 2016. it was, a functional change for us to just have something that engineers could use without copying and pasting. And that was roughly what we used on the design side. to have that was, you know, it was a useful step, um, that ultimately, like when we started building the design system in full and building it in a way that was more robust and reminiscent of tokens as we know them today, that, , was something that we, you know, Throughout [00:23:00] and then like started over again from scratch because you know, it was not necessarily where we wanted to go But it was something that we you know had in those earlier days

When to actually start your design system

So something that I've heard you say that I appreciate is that companies, especially startups, shouldn't start a design system for the sake of starting a design system, but you should do it only from a place of actually experiencing problems that you want to solve. And so I think I have a pretty good sense of the landscape over 12, 20 months.

What were some of the problems that you were experiencing that led you to say, you know what, it's time to take that next step and actually formalize a system that we can build upon and scale into the future.

I think for us, it was primarily the scale of the organization was our most pressing need. So by the time when we started building the design system more formally, I think we were about 10 front end engineers, but maybe like 50 engineers overall. And a lot of [00:24:00] those were full stack people that were, you know, building UIs.

we were also starting to grow as a design team. So I think at that point we were probably eight people in total. having something more formalized, something that we could rely on as a resource, , was something that was readily valuable because there was just a lot of. craft debt mismatches and our intentions on the design side and what we were actually putting out into the world that we wanted to help resolve and, it was definitely the right time given, , the growth of the team. I think the other thing that's, you know, worth sort of noting from that time is I didn't necessarily start, full time exclusively on the design system when I started the design system in 2017, half my time was actually doing a lot of more broad design engineering work. And that included things like prototyping and helping.

make sure that we were landing, , important, like features at the right level of quality that we wanted, as well as also like helping with,[00:25:00] , some of the front end infrastructure work that I had kicked off a few years before. there was still, I think like, uh, a lot of other things that occupied, my time.

, and I really wanted to. Focus on a core sort of MVP for, , the design system in, in those early days in 2017.

When to actually start your design system

So something that I've heard you say that I appreciate is that companies, especially startups, shouldn't start a design system for the sake of starting a design system, but you should do it only from a place of actually experiencing problems that you want to solve. And so I think I have a pretty good sense of the landscape over 12, 20 months.

What were some of the problems that you were experiencing that led you to say, you know what, it's time to take that next step and actually formalize a system that we can build upon and scale into the future.

I think for us, it was primarily the scale of the organization was our most pressing need. So by the time when we started building the design system more formally, I think we were about 10 front end engineers, but maybe like 50 engineers overall. And a lot of [00:24:00] those were full stack people that were, you know, building UIs.

we were also starting to grow as a design team. So I think at that point we were probably eight people in total. having something more formalized, something that we could rely on as a resource, , was something that was readily valuable because there was just a lot of. craft debt mismatches and our intentions on the design side and what we were actually putting out into the world that we wanted to help resolve and, it was definitely the right time given, , the growth of the team. I think the other thing that's, you know, worth sort of noting from that time is I didn't necessarily start, full time exclusively on the design system when I started the design system in 2017, half my time was actually doing a lot of more broad design engineering work. And that included things like prototyping and helping.

make sure that we were landing, , important, like features at the right level of quality that we wanted, as well as also like helping with,[00:25:00] , some of the front end infrastructure work that I had kicked off a few years before. there was still, I think like, uh, a lot of other things that occupied, my time.

, and I really wanted to. Focus on a core sort of MVP for, , the design system in, in those early days in 2017.

How Kathryn started building the official design system

It's interesting to hear your answer be scale, because what you just described is a level of scale that the vast majority of people listening to this probably won't experience maybe ever. And yet, how many of those teams are actively prioritizing this initial design system in those first couple of years?

I don't even know if I have a question there. It's just something that has stood out to me. It's like, well, that, that answer is unique to your situation. Regardless of how you got there, let's kind of now take Step on the other side of this decision. So you've said, all right, I'm going to start taking steps to formalize the design system, really starting in investing in this infrastructure level.

You might even have to [00:26:00] go rogue a little bit in order to make it happen. What were some of those initial steps that you took?

for context, one of the things that was important was I was starting the DSS effort in fall in mid 2017, we had. Kickstarted and a process for us to do a rebrand that, was basically in like, you know, the we want the founders want to do this stage.

And so we hadn't like, you know, engaged with a design partner yet and hadn't sort of gone through that process. But I knew that was on a radar. what I wanted to do is by the end of the year, plan to actually get that. rebrand out into the world, , and I knew that there was an opportunity for the design system to be a tool for us to use in, like, you know, executing that rebrand and to then, like, get that strong adoption that.

We want it across all of our different product surfaces. I was [00:27:00] trying to race towards that milestone. what I really focused on was, okay, what is the core MVP that I need for both, the design system, Helping us, do the rebrand and then what do I need for engineers to start trusting it?

once we've done that migration, put it in front of them in all the code that they're using, all this done by January. And so what I really thought about was, okay, , can I build something that is, a good representation of our tokens? , can I do something that is. backwards compatible so we can, get all of our existing surfaces looking visually like what we want as like the new brand using these tokens, that we can then sort of leverage to migrate more things into the more official components of the design system.

and then what are some of the core like components that we need? You know, the obvious stuff, like buttons and modals and that sort of thing. [00:28:00] And so really that was what my first six months, like really focusing full time on the design system were like, the, right gambit for us because we were able to successfully use the design system and executing that rebrand, by middle of, uh, the following year.

Everything in on the website was using the design system. we were able to leverage that sort of success and organizational buy in to start investing in the design system for our other products or other platforms like iOS and and so those were kind of the ways that I thought about what we needed to do in the early days, and I always tried to see it from more of the sort of.

business and organizational lens so that, like, we could make the right decisions and the right timing, to help, take this from just a, you know, a project, which it could have been at that point to something that ended up being a practice that we continued [00:29:00] all the way until, you know, the team's still doing it today.

How Kathryn started building the official design system

It's interesting to hear your answer be scale, because what you just described is a level of scale that the vast majority of people listening to this probably won't experience maybe ever. And yet, how many of those teams are actively prioritizing this initial design system in those first couple of years?

I don't even know if I have a question there. It's just something that has stood out to me. It's like, well, that, that answer is unique to your situation. Regardless of how you got there, let's kind of now take Step on the other side of this decision. So you've said, all right, I'm going to start taking steps to formalize the design system, really starting in investing in this infrastructure level.

You might even have to [00:26:00] go rogue a little bit in order to make it happen. What were some of those initial steps that you took?

for context, one of the things that was important was I was starting the DSS effort in fall in mid 2017, we had. Kickstarted and a process for us to do a rebrand that, was basically in like, you know, the we want the founders want to do this stage.

And so we hadn't like, you know, engaged with a design partner yet and hadn't sort of gone through that process. But I knew that was on a radar. what I wanted to do is by the end of the year, plan to actually get that. rebrand out into the world, , and I knew that there was an opportunity for the design system to be a tool for us to use in, like, you know, executing that rebrand and to then, like, get that strong adoption that.

We want it across all of our different product surfaces. I was [00:27:00] trying to race towards that milestone. what I really focused on was, okay, what is the core MVP that I need for both, the design system, Helping us, do the rebrand and then what do I need for engineers to start trusting it?

once we've done that migration, put it in front of them in all the code that they're using, all this done by January. And so what I really thought about was, okay, , can I build something that is, a good representation of our tokens? , can I do something that is. backwards compatible so we can, get all of our existing surfaces looking visually like what we want as like the new brand using these tokens, that we can then sort of leverage to migrate more things into the more official components of the design system.

and then what are some of the core like components that we need? You know, the obvious stuff, like buttons and modals and that sort of thing. [00:28:00] And so really that was what my first six months, like really focusing full time on the design system were like, the, right gambit for us because we were able to successfully use the design system and executing that rebrand, by middle of, uh, the following year.

Everything in on the website was using the design system. we were able to leverage that sort of success and organizational buy in to start investing in the design system for our other products or other platforms like iOS and and so those were kind of the ways that I thought about what we needed to do in the early days, and I always tried to see it from more of the sort of.

business and organizational lens so that, like, we could make the right decisions and the right timing, to help, take this from just a, you know, a project, which it could have been at that point to something that ended up being a practice that we continued [00:29:00] all the way until, you know, the team's still doing it today.

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers πŸ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

hello@dive.club

β’Έ Dive 2024