Building Design Systems That People Love

Nathan Curtis: Amy has managed and created design system teams, particularly at, companies like Salesforce, DocuSign, and smaller startups.

Amy is drawn to design systems to solve problems.

Good docs, good examples, good SEO, clear handoffs.

I love a good practical design system talk.

So please help us, or help me welcome Amy Lee.

Amy Lee: Clarity!

Clarity!

How are you doing?

Can you hear me okay?

Thank you, Nathan.

Thank you, Gina.

This is the community that I love.

And you know what?

I want to talk about slides.

Because slides help the visual aids for the users and love.

Isn't this the question we've been asking ourselves all this time?

What is love?

And when I mean love, I'm of course talking about love for products, right?

And what makes a product that you love?

I think it comes down to a few things, right?

It's thin, it's light, it's magical, right?

It's a thing that delights you.

It's a thing you want to keep in your life because maybe it saves you time.

There's a shortcut.

Also, it's something that you can rely on.

Imagine two o'clock in your bed in the morning and you're like, I have to have those shoes.

And you can go on to the online mall, and it's so reliable, instant saver shipping.

It'll be at your doorstep the next day, guaranteed.

Also, it's something that infuses your personal brand.

It grows with you.

One day you're more into one set of colors, next day you're into the other one.

And so it evolves your personal style.

And that's products, design systems.

Are they products, do you think?

a product is something that gets consumed and design libraries, they have designers as consumers, engineers, they have the code libraries.

Also, there's so much more in the ecosystem.

They consume docs and training.

You provide them support.

All of these things are part of the sum total of the design system product.

And if we think of design systems as a product, what are some of the things that we like in a design system?

a design system that exceeds your expectations.

It has clear docs and examples.

It gives you superpowers, right?

You feel like you're instantly productive when you use it.

Also, it's robust.

It works across all the devices you have.

You can count on it.

The new watch comes out?

Great.

It supports that too.

SEO?

Accessibility?

It handles those pains for the developers and for the designers.

And what about your brand?

Your brand, it can grow with.

One day you decide to do a rebrand and it can grow and change the tokens.

So design systems.

When people really get it, you get quotes like this.

I love how, when using the design system, it becomes trivial to make these kinds of updates.

A simple version bump in the app and voila!

All the radio buttons in the app look perfect.

Chef's kiss emoji.

An actual human said that to me.

Because this person got our design system.

Not only got it but became a super fan of it.

He started deleting code.

He started using more components.

He was super into it so much other people started using the design system.

And so I want to talk a little bit about a bunch of things that I've learned on my journey and my design system journey began, you know about 2014 and when it's when I joined Salesforce.

I've worked at very large design system teams with multiple sub teams, dedicated accessibility teams, all the way to basically a design system of one at a startup.

But, what holds true is that there's ways of communication, ways of exposing your thinking that will resonate with your stakeholders.

So I've been on this journey, but guess who else has been on a journey?

This guy.

Does anybody know who this is?

shout out the name.

From the classic Nintendo game.

That's Link, Legend of Zelda, right?

In the beginning of the game, it looks like this.

You have nothing in your hands, no tools, and yet you're required, destined to have this epic adventure in front of you.

wouldn't it be easier if you did have some tools in your hands?

fortunately, there's Cave.

So you go into the cave, and in the cave you meet the old man.

He says the words that have become famous in video game history.

It's dangerous to go alone.

Take this.

And what does he give you?

Does anybody know?

The sword?

No!

He gives you tools.

What are you going to do?

Fight all the enemies with your hands?

No!

He gives you knowledge, he gives you tools, he gives you strength.

And today, I come with you, not with one tool.

But three.

And I want to talk about how do you see what your stakeholders want?

How do you fill in those gaps?

How do you show design system value?

I want to talk about how do you do drawings to cut across and explain complex concepts, but do it in a way that has just the right level of detail, it cuts across roles.

And I want to talk about how do you get people literally on the same page with consensus collectors?

So who's ready to go on a journey with me?

Yeah [crowd woos]!

Say it with me.

It's dangerous to go alone.

Take this.

the first set of tools I love are how to unravel this, right?

Because whether you're starting a design system or trying to get more adoption for your design system, it'd be nice if there was some magic dust, right?

You could sparkle, sprinkle on things and all of a sudden everybody gets your design system.

But that's never the case.

There's always some sort of a barrier, right?

Like maybe the resources are not available until a certain time, or maybe there's a technology you must buy into.

Maybe you need the enterprise license of something.

And once you're on your journey, maybe there's a challenge you need to do.

everybody needs to learn TypeScript, or they need to, upgrade a system.

Or maybe there's time pressures, right?

Maybe you thought you had two quarters.

no, You have one quarter to do your design system rebrand.

And dragons.

Oof, there'll be dragons.

See, the, dragons, those are the things that could derail the entire project, right?

There's those potentially unexpected things that happen.

wouldn't it be nice if you could ask questions?

And get a lot of these details out ahead of time to reduce the number of surprises that you have?

I have two ways of doing this.

And so let's talk about them.

The first way is getting all the things that people know about.

And by people, I literally mean people.

Get people together and then ask them to say, Oh, you need this particular component or this particular variant.

What about those brand colors?

Yeah, we're going to increase that to four brand colors.

Really?

Yeah, four.

Then you can talk about some of the challenges, right?

These are the things that you'll know, Hey, we only have an engineer for this amount of time.

Let's go make best use of that time.

And then, you can make your lists.

And when you have your lists, you can prioritize them.

At Salesforce, we love to do stack ranked lists, where the most important things are at the top.

And then you can show the true value of the design system.

Hey, there's all those card patterns.

Let's condense them down to one.

Hey, there's an accessibility problem.

Let's solve that inside of a component instead of tasking four teams to develop it.

That's nice.

And so I do this at two levels.

I do it first with a steering committee.

And why a steering committee?

Because these are the leaders of the organization.

They understand time and resourcing.

They understand the goals of the business.

They're, like the head of design, the VP of engineering.

Yes, it's okay.

You can talk to them.

What?

You're not a manager?

That's no problem.

Ask to be included at that table.

But that's not enough.

I always love to develop a set of champions.

And champions, those are the individual contributors.

Those are the people that know the technology.

Those are the hands on, day to day designers making components, making layouts, making user interfaces.

Same thing with the engineers.

Right?

Those are the people who sweat the details.

They're gonna tell you a lot about what you need to know and together you'll have some pretty robust lists.

But what about the things you don't know or things that maybe they've forgotten to tell you?

I love a good story.

Do you?

Yeah, I love storytelling so much.

I get people to tell me a story.

Forward?

Or backwards?

I'll be like, hey, you landed on the homepage, and then you want to log in, great, you go to log in, and it pops a modal, really, we're doing modals, okay.

So maybe the modal component is one of the most important things we need to work on next.

Here's an example of something that, demonstrates all this.

So working on a rebrand, talking with the design team and coming up with, okay, here's some new colors, we're going to put them in tokens, going to hand it to the design system team.

Great.

We're gonna, package them in a JSON file, process them through style dictionary.

We're gonna map them to material UI components, and we're gonna share them with three teams.

Cool.

So go to the first team, say you might use a design system.

Sounds good.

But, oh, you're on tailwind.

We're using material.

How can you consume this?

in discussion, we didn't give up hope, and we found out, hey, they can just They can use the JSON file, we'll ship, we'll ship you not only some of the compiled type script, ship you some JSON.

You can copy it as a first step and then we can link your app later.

Then we go to the third app and say, oh, by the way, you wanna use it.

Sure.

Using material, great.

We're using material too.

Then we go to the second app.

This is the big app, right?

The most important one.

You want to use it?

Sure.

But we're on material.

Version 3.

Oh no.

Is this going to be the dragon that stops the project?

Oh, who knows.

after discussion, after a spike, after a little bit of work, problem solved.

We didn't have to wait until the end of the process, we actually figured it out in the beginning.

That's awesome.

I love seeing this.

And that is one of the ways to build trust and reliability into your system.

You can help show that the design system has value of making sure that it satisfies all the user needs, getting them out on the table, and then reducing the surprises.

Let's talk about the next tool.

Say it with me.

It's dangerous to go alone.

Take this.

So let's talk about illustrations.

Four dev teams, each with a signed QA, with shared product owners across two organizations reporting to the VP of product.

Now some people can actually figure this out and draw the map in their head, but I can't.

I have a very small brain.

But if somebody draws me a diagram, I can get the sense of it.

I can get the sense that, oh, there's a lot of resources on one side, and not a lot of resources on another.

Maybe the more important components are over here.

And the point I'm going to demonstrate here is that drawings, they hit at a sort of very, a level where your brain loves to work with relationships and grouping.

Words, they require this processing of you see the word, you have to have a concept.

You have to map that concept, and everybody has to have the same concept.

Drawings are very, obvious to people.

Words can get misinterpreted.

Words are important.

we'll get to words.

And so I'd love to talk about simple ways to do simple drawings.

And the first one is, how do you pass work from your team to the next team?

the thing about handoffs, It's a workflow, isn't it?

And you have dependencies of which team is handing off to which team.

And more importantly, how are they handing it off?

Great.

So one of the things I love to do is draw swim lanes.

Great.

We have three teams, marketing, design, systems.

And let's say we're working on a bit of a rebrand.

Okay, so marketing is going to go away, have some concepts, come up with some colors.

And hand it over to the designers.

Designers are going to then hand it to the design system team when they're ready.

But there's one missing ingredient to this.

What if we said, hey, this is how you're going to do it.

Between the marketing and the design team, let's do hex colors.

Great.

Everybody loves hex colors.

And then between the design team and the design system team, let's do tokens.

This makes it very clear when you continue to refer to diagrams like this, it becomes obvious.

Somebody decides to do something else, you can just point them back to the diagram or update the diagram.

So let's say you want to go and add some illustrations.

Let's say the marketing team has contracted out and now they've returned some PDFs.

the designers can take those PDFs, put it in an image library, do the transformation to SVG, and then into the design system.

That's nice.

Illustrations.

Let's talk about the next thing, phase maps.

So let's talk about time.

When I think about time, I think about roadmaps.

I like to think about timeframes that are reasonable, small enough that you can be agile, but long enough that you can complete a project.

And so I like quarters.

Who doesn't like words?

They're easy.

They're about, six, seven sprints, depending upon, your sprint schedule.

And what I love to do in each of these quarters is to put some simple, high level goals.

What's your main focus?

Oh, we're going to do tokens normalization here, we're going to work on the rebrand stuff in Q2.

That's nice.

It's simple enough that an executive can come and say, Hey, can we just move that from one quarter, Q2 to Q1?

Sure.

Just edit the text, move it over.

The thing about diagrams like this, they encourage play, they encourage interaction.

These are things you can do on a whiteboard, on a post it note, in slides.

On a spreadsheet?

Sure, you could do it on a spreadsheet.

Why not?

Let's talk about near and far maps.

Let's talk about resourcing.

you might be saying to yourself, Amy, I'm a designer, or I'm an engineer.

Why would I want to care about resourcing?

I'm happy.

Because this is actually an interesting point for you.

You can see Hey, your organization may change over time.

You can be part of that voice and affect the change.

Oh, we need one more designer.

We need one more engineer.

We need a QA person.

We need an SEO expert.

You can do all those things.

And so what I like to do is say, Hey, this is where we are today.

Just draw a big box.

Today, we have two designers, three engineers, and that's what we're doing.

And then very soon we're going to split our focus.

We're going to have some people work on mobile, some people work on the desktop.

That's great.

And speaking to the designers and engineers again, this may be a good career move.

Maybe you want to move into management.

You can say, Hey, I want to lead the mobile effort.

Put me in charge.

Show, let me show you what I can do.

This allows you to grow your skill base.

To show ownership.

And then, here's some magic.

You can show where do you want to take the organization?

So working with other people, maybe you can talk about the fire feature.

Yeah, we've been wanting to do that watch out.

That's great.

Let's set up a sub team.

Maybe you start managing two teams, or maybe you're on a team and you say I really want to work on the watch.

So these are ways to communicate what people are doing, how to expand your team.

How to take on more responsibility and how to show the value, business value to the organization.

And the reason why I think people like this a lot is because it shows very simply in diagrams that anybody can understand.

Here's how information moves, here's how responsibilities move, here's how we get products done.

It's clear, simple planning, and you can inspire the future not only for yourself, but for the organization.

You ready to move on?

I do.

Say it with me.

It's dangerous to go alone.

Take this.

Consensus collectors.

have you seen PRDs?

I know it's spooky season.

These things are very, important.

I am not upset at PRDs, but in the beginning, if all you do is make the PRD, you've not aligned people properly.

You've not prepared them.

You've not gotten their consensus, right?

In the beginning, I like to use simple language.

I like to use plain language.

I like to go bite sized.

And here, consensus is the first of three steps, right?

You motivate people, you get them on board, and then, once they're on board, then you hit them with the PRD.

Then you hit them with the tech spec.

Then you start playing out your Gantt charts that go all the way to the floor and then some.

And, once you're on that journey, you're executing.

Then you can make the argument of how you want to continue that investment.

So let's talk about three tools that I know about.

First thing is the one pager.

A one pager should be a document so simple you can read it maybe two or three minutes.

The kind, the time it takes to microwave a burrito.

So think microwave burrito length.

In it, you're going to just talk about what is the main objective.

In this case, set the headline.

a couple of key points.

Note, this is not OKRs, KPIs, use plain language.

The OKRs will come later.

This is consensus collecting.

Then explain the idea.

Use maybe one, two paragraphs at most.

Explain the business value, explain what's going to change, what will be true when the feature ships or the project ends.

You can use simple diagrams again.

I love box diagrams.

And then, this is optional, add the roles table.

Say who is doing what, and get them to accept.

But when they've read it, they must sign.

Put their initials, put the date, yes, thumbs up, whatever works for you.

The point is that things like this, people can, their eyes can glance over and not really understand, but when you know you have to put your name down there, your brain goes, wait, let me store some of this, think about this.

And then, you can do your resources.

You can link out to the full text back at the end, the full PRD, but save that to the end.

This is like the, your, your, resources list, your, the backend index, and that's one pagers.

Let's talk about chat.

Chats are everywhere, aren't they?

chat, Slack channels everywhere.

Teams channels.

That's nice, but the problem with this And the other thing is that there's too many chats, and so I love to have one single design system chat.

I like Design System Central, Design System Guild, Design System I don't know.

Excellent.

And in this, you direct everybody to that specific channel.

Have a new release, direct people to the channel and say, yeah, we'll launch and announce the release there.

You need a question?

Go to Design System Central.

And then the magic happens.

When there's enough people talking and looking at the channel.

They started helping each other.

Oh my goodness.

All those chats, all that energy gets collected into one place and then suddenly you start noticing like, hey, where's that icon?

And then somebody else not on your team will say, Oh, yeah, that's in that particular Figma library.

It's on that page.

Go ahead.

It's called this.

Okay, cool.

Or that component.

Oh, yeah, that's actually a variant of this other thing.

Use that, and that's when you know that people really got your design system is when they start helping other people use it.

Let's talk about the last one, the replay.

One of my favorite techniques is doing a summarization.

Now, if you've been in a meeting with me, you'll know that probably near the end, I'll be like, all right, it's about half an hour.

Let me play this back to you.

Let me see if this is what I heard, and I'll recap what was the problem we were trying to solve, and some of the solutions people talked about.

Just make sure everybody understood that there was more than one solution, but then we'll talk about what is the agreed upon solution, and who's doing what.

At the end, you want to a thumbs up at the end of meetings, long chat threads, right?

Because this, much like the one pager, it basically says, hey, I agree.

It's a low effort way of getting consensus.

And what's nice about this, maybe you didn't summarize it correctly and somebody can correct you very quickly.

I always like that.

And so the way I think about consensus collecting is do it in a way that reaches a lot of people and then make sure people know what to do next.

So in summary, design systems, if we think of them as products, we want them to be the thing that we want in our lives, that grows with our organization, that shows the value.

And that's always there for people.

And we show three different ways to do it, about getting the expectations into lists, reducing the surprises, using simple diagrams that anybody could draw on a whiteboard, on a post it note, on a slide, and ways to get consensus collected into chat channels, into simple documents.

There is one more thing.

There is one more thing.

Passion.

I hope the reason why you are here at Clarity, or you're watching this video later is because you're excited about design systems.

and you've seen the proof that design systems help people.

They bake in the best parts of accessibility, SEO, scalability, robustness.

They allow common language between designers and developers.

They show clear connection between concepts of design to actual delivered product value.

And the more energy that you put in drives the interest in your own design system.

And the more you talk about design systems, the more it drives the conversation in, the internet.

And so the real thing is when you are the fan, but then they become the fan, they become your voice and they take the lessons that, that they've learned from you and they, spread it to a wide audience.

And so the way I like to think of this is that this is an energy multiplier.

The more that we invest and put into our design systems.

The more love comes out.

And on that note, thank you [applause].

Nathan Curtis: Thanks for that.

you were, your talk was so full of practical tips.

I just want to dive into all of them.

And so the first thing that, you had just on a slide, but I feel is really important is, how do you get a user of your design system, a consumer of the system, to feel instantly productive?

How do you know when they're, your design system has too many bumps that is inhibiting them from feeling instantly productive?

Amy Lee: The way I look at it is, do they see themselves in your design system?

Do they see their concerns represented?

maybe your design system doesn't have the, the, card that has, the image and the title that they really need, They, feel like, oh, I have to go and build this myself?

Why, should I use the design system?

But then when you show them these great examples, and you show them the page and say, this is the user experience that we want, this is the thing that the organization wants to build, they go, oh, it's there, in that pattern, that list, that scrolling list, great.

They feel like they're home.

Nathan Curtis: What you covered were in the gap glasses section, all the different, ways that you try to get input from different stakeholders.

You talked about lists, you talked about using challenges and so on.

Do you have any go to prompts or questions that are your favorite that yield the most impactful responses?

Amy Lee: One of the first things I'd like to do is Show me the feature you want to launch, and then let's pick apart the design.

Let's pick apart the user flow.

And in that, I'll just watch and ask questions and guide the conversation to, Oh, is that a component, or is that even part of our team?

Is that another team?

Oh, we need another team in the conversation.

Yeah, we didn't know that they split off from our team.

you start asking these questions.

It's you get them to become storytellers, even though they didn't sign up to be one.

Nathan Curtis: You talked about two different groups, the champions and the, I think you called it steering committee.

But, I'll call them the champions versus the steerers.

how do you, balance the input?

Who do you get, ultimately, the input that drives where you end up going?

And if it's in conflict, what, how do you, ferret that out?

Amy Lee: it depends.

the, if you are very close to the steering committee, maybe this is the chance for you to be the voice for the champions.

if you're very close to the champions, maybe this is the opposite, where you're the voice of the steering committee.

I think that it is a little bit of both.

the business often doesn't see all the fine details what we work on because our details are so small sometimes.

And they're so particular.

It's the, is, what you're doing for a design token actually affecting the market that they're trying to enter?

And being able to draw that connection between the work that people do to the actual value of the product.

I think that is the way you, bring the two groups together.

Nathan Curtis: I love the handoff map where you were illustrating different teams producing different things and then the connection between the two being the format or how you said the how.

They're going to hand it off.

Do you have a best story of where you broke open a conversation that yielded an opportunity?

Or do you have the opposite of that, like a horror story where you revealed an intractable dispute between two teams?

Amy Lee: I don't think that there has been an intractable dispute, but in the case of, say, a recent rebrand, there were a lot of teams involved, right?

marketing is not just one marketing team.

It is there's copywriters and people that do design and people that think about, the SEO angle of this.

who is doing what?

And when you say marketing, okay, we're talking maybe about the visual design.

Okay, so then, the visual design is the part that gets passed to maybe a specific design team.

not all designs, a specific team.

And then, how are they going to do it?

we're going to use this particular PDF that has all the new marketing colors.

Oh, you're not going to do hex colors?

No, we didn't have time.

Just go look at those, sample them in, check back with us.

If the hex colors that you found out will match the CMYK or Pantone colors.

Nathan Curtis: When you describe the path from going from the PRD section of your talk where you said small bite sized chunks, simple language that yields, do we all agree around where we want to go?

And then you talked about, I think, dependencies and plan and approach in the second column.

which to me is like the point where, okay, now the team is unlocked.

We can start doing all the Asana tasks and start cranking away to make stuff.

But that leaves the third column.

Oftentimes not well served, the support, the rollout, the communications, and so on.

And so as a leader of a design system, I'm often caught, one, trying to prevent us to not under invest in the third column.

But also, when do I need to start doing that work?

Do I need to do, essentially, plan the support and the rollout when I'm planning everything else?

Or do I start that somewhere further down the road?

Amy Lee: Great question.

I think when you're first just trying to get a concept out there and get the general buy in, you can lead to support, to a later date.

You can actually watch people build out the one pager.

You can sit in a meeting and just say, yeah, we're just going to go down to roles and say, then we're going to break out and do some, maybe some technical explorations.

We're going to do some spikes.

That's actually a good breather point, just, gauge the room and see how much of people absorbed.

Maybe it's too much.

Maybe the, just the summary of what are we trying to accomplish?

Maybe that takes 25 minutes out of a 30 minute meeting.

Don't rush.

You have a lot of time.

I, I think that the, you will save more time if you plan well.

So getting specifically to your question about like, when should you focus on support and those things, I'd say once.

If the organization is really committed to, yes, we're going to do this project, then let's talk about support.

That support could actually be its own one pager, but not just support.

I think we should be thinking about deprecation.

Not all things need to live forever.

I remember, I think it was, a Dan Mall presentation where, a design system had, over a hundred components, but it didn't really need all of them, and there's a way to, bring them down to, what do you really need?

It's okay to say thank you and let it go.

Nathan Curtis: I just want to react personally, because I'm going through that now with a team that's changing their very large Figma library to have, from having a prop for color modes light and dark, to using variables for light and dark, which means half the objects in their library immediately deprecated.

We're spending about 5 percent of the time on the stuff we're keeping, and 95 percent of our time on how we Get people off the stuff that they can't use anymore.

So that's really good advice.

the last question I have is, your three major categories you walked through.

And then you put one more thing of passion at the end.

Given how you structured your presentation, was there a fourth and fifth category?

Do you have a library of these things behind the scenes?

And how did you choose or what was your journey to arrive at the three main, Chunks that you took us through today.

Amy Lee: My journey is basically, I'm frustrated.

I want everything, and I want it now.

But, an, executive once told me, Amy, you can't give everybody every single detail, every single answer.

You can't say the whole plan at once.

The, lead them, maybe 10 percent at a time.

Because that's all that the team can digest.

The team has so many other concerns.

for you, your design system is the world.

For other people, the design system may be like 20 percent of their particular purview, right?

And you want to be able to communicate all these things.

Are there more categories than what I put up there?

I think there's more ways to see the gaps.

There's more ways to do diagrams.

In preparation for this talk, I was working with somebody else.

And diagramming time of hey, here's how, I, I see this in terms of energy levels.

Oh, that's really funny.

That's a little bit like, okay, maybe want to add some humor in this part of your talk, right?

And so there's emotion graphs and all these things.

Anything that demonstrates how you think in a way that somebody doesn't have to have technical knowledge to digest.

I think that is the key thing.

Nathan Curtis: That's a great place to leave us off.

What great advice.

Please join me in thanking Amy Lee.