Chelsea Otakan: Design and build systems, not just features

This week we are joined by Chelsea Otakan, infamously also known as @chexee on most of the internet. Chelsea is a product designer and front-end developer, currently working at Lattice.

In this episode, we learn more about Chelsea's design origin story, her philosophies on product design, and why you should "build a skateboard, not a wheel".

Chelsea's design philosophies
- Ship quickly, ship for the user
- Design is continuous
- Design and build systems, not just features
- Don't be afraid to dig deep
- Critique early, often, and with everyone

Other Links from the Show
- Shopify article on creating a "quality elevator" from Kyle Peatt: The system always kicks back
- Chelsea's portfolio and work at Chexee.me

Build and Learn around the web
- Twitter: @buildandlearn_
- Colin: @colinloretz
- CJ: @cjav_dev

Creators & Guests

Host

CJ Avilla

Developer Advocate @StripeDev. Veteran. 📽 https://t.co/2UI0oEAnFK. Building with Ruby, Rails, JavaScript

Host

Colin Loretz

I like to build software and communities. Building software at @orbitmodel 🪐 Coworking at @renocollective 🎙Sharing software learnings on @buildandlearn_

Guest

Chelsea Otakan

Design systems @LatticeHQ. Karaoke enthusiast. Likes purple. Prev @stripe @sourcegraph @change @automattic.

What is Build and Learn?

A podcast about software development and developing ourselves as software engineers. Hosted by CJ Avilla and Colin Loretz.

​

CJ: Welcome to Build and Learn.

My name is CJ.

Colin: And I'm Colin.

And today we are joined by Chelsea Otakan.

Chelsea is a product designer
and front end developer.

She is also a self-proclaimed lover
of design systems, writing code, red

pandas, karaoke, and learning new things.

Welcome to the show, Chelsea.

Chelsea: Hi.

I do love all those things
that has stayed the same.

Colin: So far on this show, we've talked
a lot about software development mostly

in terms of like programming languages
and tools, culture, those kinds of things.

If you're just joining us, you can
go check those out in our show notes.

But this week we wanted to kind of turn
it on its head a little bit and dive

into Chelsea's approach to designing
and building things for the web.

So if you've been listening to the show
for a while we're gonna mix it up a little

bit and yeah, we're excited to dig in.

Chelsea: Yeah, so I, I work at
Lattice so if you're not familiar

with Lattice, we build kinda like
performance kind of software.

So software to do performance reviews,
feedback things like that at your company.

I've been there for about a year.

I joined last January.

And before that I was
working with CJ at Stripe.

In terms of things that are relevant
to me, I think the things you listed

off were, are still my interests.

But I feel like a lot has
changed in my life since then.

Mostly I have a one and a half year old.

That keeps me very, very busy.

Her name's Penny.

Yeah, I got a snotty, little toddler
to runaround after, so that's

like a lot of my life lately.

CJ: Having kids changes
perspectives so much.

I remember yeah, it kind of, I,
there's like also some research about

like how it like literally changes
the chemistry in your brain, even as

like the non birthing parent, right?

Like when you see the kid as a baby and
they're like, you know, skin to skin or

whatever, it just like changes everything.

And so, yeah, not surprised
to hear that some of those

priorities have shifted a bit

Chelsea: Yeah.

Yeah.

It might be like above red pandas, but you

CJ: Okay.

Chelsea: the jury's out.

Like it depends on the day.

CJ: Yeah,

Chelsea: day?

Colin: karaoke is just in there somewhere.

It's so something that you can do,

Chelsea: We do together.

Really?

So, you know,

CJ: Nice.

That's amazing.

Colin: get Penny into that early.

Chelsea: Yeah, I'm actually
in my basement and our home

karaoke setup is like over there,

CJ: Nice.

I guess that's a good thing
to start talking about.

What is karaoke night?

Chelsea: Oh gosh, I forgot about

I guess that's sort of kind
of related to my story too.

So background, I started off in
design, but I'm not, I'm not, I don't

have like a formal design background,
so I didn't go to design school.

I started making websites when
I was like in high school.

I was super into neo pets and a actually,
as I progressed with my career, I

found like many other people, like
that's how they got into design or

coding or tech in general is like some
neo pets was somewhere in your path.

And it was definitely in mine.

And I was like into live journal
and blogs and all that stuff.

And so I'd been doing that for a while
and then, I went to college and was

like figuring out what I wanted to do.

It was like maybe biology, but
it wasn't really feeling right.

And then I needed a job and so I
like walked into what I thought was

like the magazine office, but it was
actually the newspaper office and

someone was like, we need someone.

We need another person on our website and
let's like, wait here, I'll go get the,

the guy that runs our website and it was
Colin and he like, just gave me a job.

I was like, whoa.

Okay.

And that's kind of was the first
time I like, figured out that this

was something people would pay you
for and was like a career path.

Kind of fast forward,
sorry, I went roundabout.

I was doing design for a while and
I've always been sort of, sort of

a technical designer, but never
really progressed past, like copy and

pasting a little bit of JavaScript
and writing CSS and was starting to

get more interested in programming.

And then I, I work somewhere that.

Sort of like paid for me to
do a front end development.

Like course it was through, I
think it's called something else

now, but it was through bloc.io.

So I did this like self-paced course
and they give you a mentor and

I really just wanted to get over
that hump of like, can I start.

Like solving problems on my own
without like just copy and pasting

something and then vaguely editing
code and like crossing my fingers.

Like, can I actually read
code and understand how it

works and, and problem solve?

And so that really helped me get over
that hump and the like little karaoke

night app, which never really launched.

But that was sort of like my
test project of like, okay.

, they give you like structured projects,
but can I make something up and then like

and, and figure out how to work on it?

And I think I got like 80% of the way
there, but never really launched it.

Like I got the shape of the app.

I got like, like a single page app
running and then I started trying to

write scrapers for like music databases
to try to like scrape the databases

and, and put together lists and stuff.

And so so yeah, I was just trying to
find something that I like was really

into at the time, and that was karaoke.

So and if you've ever tried to
use a karaoke app, it like the

karaoke DJs like, download this app.

They're really bad.

They're like, so bad.

Colin: The best way to do side projects
is to find something that you're

passionate about and you're gonna spend
more time than you would on anything

else to figure it out because you,
you want, you want it for yourself.

Chelsea: Yeah.

Yeah.

CJ: Yeah, that was a, I was gonna
say, that's like a, there's a

couple like really interesting
nuggets in that, in that backstory.

Like one is build side projects
cuz you'll learn stuff.

But the other is that you
didn't go to design school.

So like if, yeah.

I guess like, I'm curious if you
were to restart today, would you

recommend a certain design school?

Do they have like boot camps for learning
design or is this something that people

usually kind of pick up on the side?

Chelsea: It's hard for me to
say and I, I feel like I've.

I've mentored a few designers and
it's been tough for me to like,

relate my experience cuz I think that
the industry is just so different.

I'm not saying I'm old,
but it makes me feel old.

. But like I, I mentored an intern at
Stripe and she went to Carnegie Mellon

and , you know, she was asking me
questions about like, like what, in,

like what internship did you, how did
you decide where to do your internship?

And I was like, I went to journalism
school so that like we had to do

internships, but like the way I did my
internship was like, it was required,

but I just took my job that I was do,
like I had a part-time job at the museum

and I just asked them to sign my in.

Papers because like I already had a job
that they were like paying me to do.

And so I, I, I didn't go to like, I think
today you like go to like Carnegie Mellon.

They're like schools for product design.

A lot of people go to, and then they had
these like internship fairs, which I went

to Grace Hopper one year and like saw the,
they have like an internship fair hall.

And that was just like, it blew my mind.

It was like, like all these companies
like Apple and Workday and, and they

just had all these booths and endless
stripe like I was there with them.

We had the booth and it's just like these
leagues of interns like interviewing like,

like a hundred people in line to interview
at Apple and they're just like standing

in line and there's a guy at a counter
like doing an inter a quick interview

with them and they're like, next.

And then like they just go to like
50 companies that day or whatever

and try to get internships.

In turn these companies are like,
are like banging to like work here,

like we want you to, and I did not
have that experience like at all.

So a part of it is like hard for me to
say cuz I didn't go to design school.

So I actually, I can't say what the
value or not value of design school is.

I feel like I can't really say
what that is, but I think that.

I think one of the values of my path
and, and to maybe like, fill the gaps

from earlier, like, I went, I went
to work at the newspaper and then

I decided to like join the J school
which is the journalism school at UNR.

And I, I would say the
journalism school at UNR is more.

does more broad communications.

So there's like an advertising path.

There's like print journalism, there's,
so there's a few different paths.

And I I didn't choose a path.

I kind of decided to get a more general
degree and then so I got to sort of

like pick classes from any of the paths.

And one of the classes was a design
class and . Bonnie was a sort

of like design professor who had
joined the J school, I think in my,

like, sophomore year of college.

And so I just sort of like
latched on to what he was doing.

But I took her all the classes that
she taught and then did a like,

I forgot what it was called, but
basically a, a like independent study.

Me and another another designer who
was in the J school, Kevin Jones, who

I think you guys, you guys know, like
me and Kevin were kind of like doing

similar things when we were in college.

So we did an independent study with
Bonnie and just sort of like made

stuff, well, like had few peers to
make stuff and did, and she like kind

of like made up projects for us and.

and yeah, so I kind of
like chose that path.

And then and then I, while I was in
college, I was also working like part-time

design jobs, so I was contracting I
worked at Twelve Horses with Colin

again, sort of Colin got me like my first
two jobs, so hey and like contracted

around with different companies in Reno.

And then I started doing like
volunteer ui work with wordpress.org.

And so my first job outta
college was at WordPress.

I kind of had started working within the
community there and doing open source

work and then got to know everybody
there and, and got a job there.

So that was, that was sort
of how I landed my first job.

So it's a atypical path, I think.

But at the time, , the typical
paths that I've learned exist.

Like they weren't really there.

I have a hard time giving advice
on like how you would do it today.

I just like, was like,
how can I do more of this?

Or when, you know, when I joined
the newspaper and I was like really

into, into doing web stuff and I was
like, okay, how do I do more of this?

Either in this job ended up working
at Twelve Horses and so it was

really like trying to evaluate
like what do I wanna do more of?

And then like, how do I just like
keep going down that rabbit hole?

Colin: Yeah, the industry has
definitely gotten more mature.

I mean now we have boot camps
for all like data scientists

and design and all these things.

But like, you know, thinking back
like I was actually in the business

school because I also couldn't really
find, like, there was no program for

people who were building for the web.

And I ended up working with the
J School as well cuz they were.

They were kind of like a startup
in that like newspapers were dying.

They had to reinvent themselves,
they had to be on that bleeding edge.

And so you and I got
exposure to web through that.

There was a grad program that was like,
Hey, we're playing with this thing Google

released called the Google Maps API
like, can you figure out how this works?

And we were like doing like, like
realtime news on a map, like with

pins and stuff and like using
the first version of the api.

And I actually, they're.

, we'll pay you for this.

And it was like weird to be
like, oh, I can get paid to code.

And you're totally right.

Like now there are those, these like paths
you can follow and like little guideposts.

Your website does a really good job
of kind of doing a few things, showing

some things that you've done over your
career at different companies but then

you also outlined some philosophies
that you've clearly like developed over

all of your time from you know, from
the newspaper all the way since today.

And so I thought it might be good
for us to, to dig into some of those.

And you, in fact, digging deep is,
is one that you just mentioned.

And, and one of the ones that you have up.

Chelsea: Is that really
one that I wrote down?

And then I just said it.

Colin: It is.

Yeah.

So we'll just skip

to that one.

So, so don't be afraid to dig deep.

Chelsea: I've wrote, I
wrote these a while ago.

Colin: Yeah.

I mean, where, where I'm at in my career.

They're resonating with me very well,
so I, I appreciate that they exist here.

And we'll put a link to your website
in the show notes, so you can also

check out karaoke night and the cool
designs that are on there for that.

So,

Chelsea: It's all very dated content.

Okay, everybody.

Colin: We can jump into the first
one mostly because of this tweet

that you also linked here, which is
"Ship Quickly and Ship for the User"

and the, tweet that you link to is
building a skateboard, not a wheel.

Chelsea: Yeah.

I, I feel like this has been, I
think at the time I hadn't heard

it in a lot of places, but now I
hear, I hear this to like build

a skateboard, not a wheel thing.

And . I think at the time that I
wrote this, I just, I had just come

off working at a company where like
you were just really, really like

build fast, build fast, build fast.

But the things we were putting out in
the world were like not resonating.

And I think it's because, I mean,
in retrospect it was because

we were putting things out that
we're just like unfinished.

They weren't whole product.

They didn't provide
like, a whole value set.

We had sort of like,
okay, here's the thing.

We had sort of mapped out like, here's
the product we think will provide value,

and then we're gonna ship that part
first, and then like this part over

here, and then that part over there.

We really prioritize that.

I think in terms of like what
would be the easiest versus what.

, what is like an entire experience
that would actually deliver value?

So the like, I think a lot of people
are familiar with this, but I can

sort of like harp on it if there's
anyone who's not like, but like

if you wanna build a car, right?

Your first version might look like a
skateboard because someone can ride

a skateboard and like get somewhere.

The first version shouldn't look,
shouldn't be a wheel because you can.

If you have a wheel, you then still
have to build like the rest of the car.

Like it's not in itself valuable until
you build something else with it.

And so I think what I was
trying to say, really.

and you asked early if there's like
any different philosophies and I think

maybe I'll like add one and that one
is like everything is a trade off.

And I think this one is kind more
trying to get it at at that is like

to, if you wanna be fast and there's so
much language about shipping quickly,

and I think especially in early stage
startups that is really critical,

but you have to ship something whole.

You can't just like ship a
piece and expect people to

know what to do with the piece.

It's not their job to figure
out what to do with it.

It's your job to like show
what value you bring with it.

And so so yeah, I think that was like
particularly something I was struggling

with, like at, at the company I just
worked at, which was feeling like, not

like there, what we were aiming to build
wasn't valuable, but that we weren't

delivering like the right piece to show.

We were just giving you like a
wheel and saying like, you can

get places with this, right?

And like, no, we can't.

And so like, like I think when you're,
when you're thinking about iterative

iter, like shipping product, iteratively,
I think each iteration has to be

like a whole thing that you can use.

And thinking about that versus like, and,
and balancing that with speed, I think.

CJ: Yeah.

I think it's also kind of tricky
to do because you, we hear all of

this like harping on, oh, just do
the MVP and ship your MVP and then

get feedback and then iterate.

But I think a lot of people
take that as like, Just ship

something that's incomplete and
basic and then get feedback.

But it's like, no, you've gotta
like get a holistic picture.

And maybe that means narrowing your
scope to like a much, much tighter

group of users that you're gonna
solve for, but like solve something

completely and perfectly for the,
that, not necessarily perfectly,

but solve it well for those users.

And then start widening your
scope to iterate and like

pull in more and more users.

Chelsea: And I think something that
happens in practice, like I think

everybody always has the intention
to do that, and we just forget about

the like, , the V and the P in that
term is like viable and product.

Like you have to build a whole
product and it has to be viable.

It can't just be minimal . Like those
other two letters are important.

I think what happens a lot, like,
at least what I've seen happen

practically is that like , like people
are scared to have to repeat work.

So like, okay, if you build like the
wheel, if you build a skateboard, those,

I'm gonna keep going with the metaphor.

If you build a skateboard, you
can't use the same wheels in a car.

Like it's a different thing.

And so like, be like, okay, but we
need to make this so it is usable

when we make our big product.

But I.

Argue, and I feel like this is something
that I've always also learned the hard way

in design systems that like you actually
at this point in the process, you don't

know what people need out of the car.

Like you don't know what
kind of wheels they need.

You don't know, like the reason
you're building this skateboard

is to figure out what they need.

So you like assuming that you can predict
what that product will look like, what

that car will look like is , I think is
just kind of like a, a fool's errand.

And so like if you're trying
to build car pieces to fit on a

skateboard, it's not gonna work.

And then like you.

. Like you just have to admit that
you're probably gonna have to rebuild

this piece, but you'll do it with
like a better knowledge of what

it should be every time you do it.

And so if you try to design the car
without building the skateboard first,

you just don't have enough information
to know what it should be like.

And so so I think that is something.

at MVP stages, you just kind of have
to let go of like you might throw

all of this away and that's fine.

Like that's okay.

You should probably throw all of it away.

If you haven't thrown most of it away by
the time you're at car stage, then yikes.

Colin: What I like about this,
and I'll put it in the show notes

for sure, is that, you know the
first one is you build a wheel.

No one's happy.

You build two wheels,
no one's really happy.

You build the body to
put on top of the wheels.

No one's still happy because.

The car's not put together
yet, but in the other one, it's

like you've got a skateboard.

That was something you can
locomote on, you can move around.

Then we're gonna add like a handlebar
to get a scooter, and the scooter is

the new product, the new iteration,
and people can get around on that.

And then you have a bike.

And then we added a motor to the bike.

And then we're like, oh, people actually
wanna sit in a car with four wheels

and the engine not between their legs.

Chelsea: Yeah, I I feel like the
scooter to bike thing is like really

important too, cuz you basically
have to throw out all the parts.

Like you're like none of these parts
that we used before matter and like,

you should totally be fine doing that.

CJ: I think, yeah, like all of
that is actually kind of also

about the second point, which is
that design is continuous, right?

I mean, the, the fact that
your product isn't done until

you've got you know, an actual.

Product that is in someone's hands.

And then you can figure out what's
good and what's bad about that product.

And then iterate, like after you ship
something, figure out what's good and

what's bad, and then make it better.

I think that's another thing that I think
we forget about is shipping something

and being like, yay, we made a thing.

And then, you know, never going back to
see how it's doing in the world, but.

Chelsea: Yeah, I think My, my second
job was at an agency and that's where I

started like, I don't know, just feeling
really hungry to understand how the stuff

I was making was doing in the world.

Cuz as most people know, like
agency work, it's like you do it,

client takes it, and then you don't
really get to see what happens.

And sometimes you have continuous
clients, but at the time I didn't

really, I didn't really have many of
those and so I, I didn't know if I.

getting better.

Like, I think that was
almost like a personal thing.

Like, am I, is this better than
anything that I've made before?

Like I had an idea of like, taste wise,
I, I think it's better, but like actual,

like ux, usability wise, like I didn't,
I didn't know if anything I was making

was better than what I was doing before.

And so I think that's sort of like
how I landed in, in product design

is just, really being able to live
with the products that you create.

And I think that's been like, design
systems is an extreme of that cuz you both

have to, you also have to use that product
and you're like, oh, why did I do that?

Like, yikes.

And now everybody has to use it.

Everybody you know is using
this thing that you made and

telling you what's wrong with it.

And you're like, oh wow, it's a good crash
course in like listening to your users.

Cuz when you, your users are your
coworkers, like they're gonna tell you

Colin: and you, in this case, you're
talking about like a literal design

system that you've implemented for
your team to build with, right.

Chelsea: Yes.

Yeah.

So a design, like an internal
design system for your company

to build your product with.

I feel like that's been the most,
the, like fastest and most aggressive,

aggressive isn't the right word,
but just like like powerful feedback

loop in terms of, of user feedback.

CJ: It also seems like a, a really
powerful skill to have both like

the design experience and being a
front end engineer because you can

sort of build these components.

That then enable a product team to go
out and build faster without having to

think about, oh, you know, what, is the
shading supposed to be on this input box?

Or what color am I supposed to use
for the call to action button versus

the like secondary button or whatever.

And so I'm curious too, I mean, we've got
a, I mean the, the next bullet is, Design

and build systems, not just features.

And so maybe we can talk a little
bit about like what you consider a

design system and like what is in
scope for design systems versus what

is, I don't know, part of the brand
and is there a like line between the

two or, yeah, kind of like how, how do
you see those things coming together?

Chelsea: Yeah, I, I feel like
this is like something that

design systems people nerd out.

It's, this is the core question
that design systems people are

like, nobody understands us.

Like what, where are the
bounds of a design system?

And like, what is a design system
for and I would say the like primary.

, the primary conceit of a design
system is to provide like UI

primitives to the rest of the
company as like base building blocks.

I think some people would say like, the
goal of a design system is consistency.

And I think I would say that like, a good
if if you're building your design system.

Well, a good side effect is consistency,
but it's not necessarily the goal.

I think the goal is like efficiency for
designers and for engineers and also like

alignment for designers and engineers.

Cuz you're using the same, ideally
the same set of building blocks.

And so you can sort of have
this like shared language.

And the reason I make that distinction
between like consistency being

the goal is that like, I think.

in the times where I've worked on a
design systems team and we've made

consistency, our goal, the scope of
what we had to do was just impossible.

Like, and I don't think it's a good
system to have a design systems

team, almost like in charge of.

Decisions for individual products.

It, it creates this like really big
tension between product teams and

designers and engineers on product
teams and the design systems team.

And ultimately, I feel, I think this
is one of the most, the strongest

opinions that I have, , is that.

The team who are closest to
the customers should be making

most of the product decisions.

And a design systems team is at least like
two degrees removed from the customer.

Like the product team hears from
customers, they do the user research,

they're like accountable to metrics
that have to do with customer happiness.

And the design systems team is
accountable to those product teams.

And so, , I should be able to
ask questions, I think on like,

Hey, do you really need to use
like different style tabs here?

Or is using the same style gonna be
like better because it's consistent?

But I don't think I should have like
decision making power over, like, you may

not use these kinds of tabs because maybe
there's a really solid user choice for.

That team is doing it.

And like, what do I know?

I don't build that product every day.

And I think it's, it can be a little
contentious when a design systems team

takes more of that hard line stance
because you don't have the context and

and it's like quite disempowering and
I think can sometimes lead to like,

like a lowest common denominator.

Thing for a user experience where like
you're using all the same components

and you've got like a baseline, like
I think the floor, I forgot, I think

Shopify wrote an article about this,
but like, thinking of design systems

as a quality elevator is important.

Because like if you raise the
floor, but like you limit the

number of things people can do, so
you're never raising the ceiling.

You're like lowering the ceiling.

You become more of a, they
described it as like a trash

compactor is what they were seeing.

And so you need to.

Like agency for those individual teams
and designers to like, explore and, and

drive solutions that are like specific to
their use cases, but give them a baseline

where like if I, I don't, I shouldn't
have to refigure out the tab design

like, so I'm gonna fall back on that.

I can but if I really need to like
drive this new pattern because it's

good for my customers, I should need to
ask design systems like for permission.

CJ: it almost seems like you could,
you could technically implement

almost every single web application
with just like a text input box.

So if you're a home and you're trying
to like listen and think about what

like this design system might look
like, imagine starting with you're only

allowed to use text boxes and that's it,

But like maybe your design
system makes like the most

badass text box you've ever seen.

It's got like crazy shades and like, you
know, these fancy borders and things.

What you, what the customer
really needs is a date picker.

But like you're making them enter in
some date that's slowing them down and

like making their user experience worse.

But like you've got a
really sexy text box.

It just happens to not
actually solve the user's need.

And so, yeah, I think I, yeah,
one of the things that comes to

mind too is like why not just use
an off the shelf design system?

For a long time used Bootstrap,
and I feel like all the websites

on the internet from like 2012
to like 20, I don't know, 19.

Were all basically look the same.

And now I'm using Tailwind ui, which
like, are these design systems, how

do you see these like sort of UI
frameworks fitting into like that role?

And, I don't know, is it like bad
that people are using those or Yeah.

What, what are your thoughts?

Off the shelf.

Chelsea: I don't think it's bad.

The latice design systems actually
use a chakra under the hood, so

uses chakra UI under the hood.

I like that those things exist.

One, because they're
like a public reference.

Two, because it's very clear that
there's like, a set of components that

like literally every company needs that

Like there's just a baseline set
in like how you're gonna start

off with your design system.

So why are we inde independently
rebuilding them like at

every single company?

Like text boxes, inputs,
buttons, tabs, redo buttons.

Like the set of pro, probably like 30
components that like every, everybody.

kind of needs.

And so it does seem silly that we're
like building them all independently.

And it makes sense to
have like a core to start.

So I like that these things exist.

I do think that, I think Rune Metson
kind of talked a little bit about this,

that like, I, I think like he felt like
there was a, there's like a sameness

about the web that design systems.

I think his design systems is kind of
like driving, and I think he takes the

word design system slightly differently.

It's like designing with a system.

So like he'll create these like graphic
and visual systems and like generative

art or like generative ways to build
things that are like somewhat unique.

I think I take a little, a slightly
more practical stance, which is.

largely, I think the things people
wanna do the web are like roughly

the same . Like they're not.

It's just like you need to like
tipity type your text into something

and like see it somewhere else and
you need to click this thing and

like have something like calculate.

And so I think the fact that we have
like patterns for that are make sense.

And I, I like that.

Something that, like having a few big
design systems and pattern libraries

does it, like, it really identifies
like, which things are almost like canon,

like so many people have done them.

They're obviously a thing that like
everybody uses and there's, and, and we

can collectively like build best like a
baseline of best practices around them.

But again, like the other example is
like, but someone could take that and

like take the baseline of that and put
it in a completely different direction,

very specifically to what they need.

Like maybe I need a carousel, but like,
okay, I'll take this base carousel

and it works kind of like a carousel,
but I wanna make it go a bunch of

different directions for some reason.

Like that would work for me.

. And so I think it's almost like,
when you're like an artist, like

you have to learn how to paint, like
everybody learns how to paint and

then you can start breaking the rules.

I feel like a lot of these design systems
just kind of like put down with the,

like what are the core skills and then
like give you an idea of where you.

start breaking the rules.

So generally I think they're also
pretty good and pretty amazing.

Like, I think it's having worked at a
company where, like Stripe was when I left

like 6,000 people and right now Latice
is like a couple of hundred and earlier

in my career I was like, I was working
more at like 50 10 person companies, like

the difficulty level in creating a system
that works for a 6,000 person company.

It was like quite different.

Like just even like figuring
out what scope you needed to

sit at and like how specific you
wanted to get with your patterns.

So the idea that like, like Tailwind
and bootstrap created things that

work for like entire industries
is just like really impressive.

Colin: Is there a point to that
point, like at which you would

recommend someone sit down and design.

Or come up with their own design system.

Like if you're a four person startup,
it's probably not your main directive

to go build your perfect design system.

Right?

But is there, you know,
is it 10, is it 20?

What, what point do you think it starts to
make sense where that, that is important

or, or does it, you know, it does.

It depend.

Chelsea: Yeah, I don't think I have
like a strong opinion on like a specific

point, but maybe I can tell a story
of trying to do it at like a 10 person

company and then deciding that like it
was probably stupid . I was, so when I

was at Source Graph, I was like, okay, I'm
gonna like put together a design system.

And I had worked at Change.org where we
like had one , that company was like a

hundred people and I had like, contributed
to it, but I didn't like create it and I

wasn't there when, when they created it.

And so I started with a baseline set of
components and kind of like made a little

website and, and people were like, cool.

Yay.

And then as folks started using
it, like literally only 10 people.

It was just like, why
does this work this way?

I'm like, oh yeah, okay, so maybe
this should work a different way.

And that's where I really learned
like how when you have a design system

that people are using, you have a
product that you're now supporting.

And when you have this product
that you're supporting, you

better have time to support it.

And, and like I think design systems
creates a lot of efficiencies at scale.

But at that size it just was like, you
know, you need to take time to support it.

You need to take feedback.

I think that's even where I really learned
like like any API change you make to

a component is like very important to
like get right when you're putting it in

the, because once people are using it,
changing it is then like really hard.

I mean, it depends on the API change,
but like, it's one of those things

where like it's a type two decision.

It's a hard to reverse decision.

So when you are ready to make it,
you better be ready to make it.

It wasn't quite that type two E at a
small company, but again, it created like.

Work for me to maintain,
to develop, to support.

And at, oh, like 5, 6, 5, what
became like a 10 person company.

She's like, I had other stuff to do and
it wasn't creating, it was creating some

efficiency, but like between 10 people,
just like not enough that it made sense

for me to also be spending like 20, 30% of
my time like answering people's questions.

And I was like, so I, I think at that
stage, It's like more helpful just to

communicate more, to align, and then at
some point, like the communication gets so

hard, you should create systems around it.

And I think those systems should probably
like scale with like, like how much

efficiency is it creating versus how much
work is, is it to maintain and support.

Colin: Right, and you mentioned
having a design system team, which I

imagined like a 6,000 person org would
have, whereas a 10 person org just

know what you're signing up for if
you're gonna bring it into the world.

CJ: I was gonna ask, so.

It sounds like maintaining a design system
inside of a small company is as if you're

an open source maintainer of a popular
library, and you're all by yourself,

, and you're still having to Yeah.

Respond to all these changes and making.

Product decisions about the design system
so that it is customizable, flexible,

and can expand into all of the needs that
might arise in the future, which can be

really tricky and I think it actually
takes like a sort of different mindset

to maintain a library that people are
then gonna use to build other software

because you have to think about all the
different ways that it might be used

and cover all those different edge cases
instead of just being like, oh, here's

how I would use it to build X, Y, and z.

So, yeah, definitely sounds challenging.

Chelsea: Yeah.

I, I think the open source Comparison.

It's one I make a lot and
I think it's like spot on.

Like working on a design system is more
like working on an open source library

than it is like working on a product.

And I think that like sometimes.

At least in my experience,
like often I think the company

expects the design systems team
to work more like a product team.

It's like, are you gonna ship, like
shipping more components is the goal.

And I, that's a goal that I often I'm
like, that's actually not the goal.

Like the first goal should be that
all our components are like solid.

We take our components that people
are using the most and make sure that

they are like extendable accessible,
that they're like super high quality.

Before we expand our surface
area of the things that we make.

Cuz like you, if you ship 10 components
and you ship them all with an

api, that doesn't work for anyone.

And then peop that doesn't work well or
is extendable and then a lot of people use

them and then you figure that out later.

Your job now to fix those is
like a hundred times harder

than it was before you started.

And so I think that like, like.

because you need to sort of like
predict this large set of use

cases and you also have to have to
accept that there are gonna be use

cases you can't possibly predict.

You have to be ready to deal
with the network effects.

of making it available.

Cuz as soon, at least this was true
at Stripe, like, because a lot of

people use the design system, as soon
as you dropped a new component in

there, people would start using it.

And once they started using it,
you had to be responsible for

how you were gonna change it.

And we later like figured out, you
know, like versioning and, and Penny.

And that's in itself is its own
like, you know, you have to manage.

versions, people are on,
recommend, choose what you're

gonna support, all those things.

But we did have a situation where
like there was a pattern that

someone wanted to contribute.

And it had the potential to be
used in a few use cases and some

designers were trying it out.

And we had a lot of pushback.

We didn't wanna pull it into the
design system until we sort of like

had more time and validation that this
was a pattern we wanted to propagate.

but we got a lot of pushback and, and
like, they're like, well, we don't

wanna build this a bunch of times,
so just put it in the design system.

And so we did it.

And then a couple months later,
one of the products that was using

it did user testing and found
out it was just like horrible.

Like, it, it did not test well, like
people did not know how to use it.

It was confusing and was causing
some like bad effects and

actually some other products.

But because we put in the
design system, like four other

products, were already using it.

And so at that point, You know, you
don't just have to be like, okay, we're,

it's not even like we are changing the
pattern and updating it to, for everyone.

It's like this entire design
pattern should not be used.

And now we have like, We have to, I
mean, we don't have the power to make

people do this, but like a thing we
have to do is just like, Hey, we don't

recommend you use this pattern from it.

Like you should redesign
this in your product.

And like, I don't know, teams
are like up in the air whether

they have time to do that.

So you, you kind of have to
be ready to be responsible for

everything you put out as well.

Like if it's bad, it's gonna propagate.

If it's good, it's gonna propagate.

And so you have to, yeah,
you have to account for all.

you know, network effects.

Colin: It sounds like if something
makes it into the design system, it's

like a design seal of approval and
then people are like, well, I'm gonna

use this thing that you said I should
use, and then it gets propagated

and you know, you have to have, it
sounds like a design system designer.

Engineers, product people who
are working on that have to think

about the end user, but then also
the developer experience too.

Like yeah, it's a what a time to
be alive on the internet for sure.

Chelsea: I'm generally in favor
of like experimentation and seeing

what happens, but also if it's
not working, it's not working.

. But yeah, I think that like, like.

The comp of, like the skateboard and wheel
situation also applies to design systems.

And I think it's one of the reasons
why like often people are like,

I think we have this pattern.

I think it'll work for a lot of use cases.

So I wanna put it in the design system.

And my first instinct
is be like, let's wait.

Like let's, why don't you guys
use it for a while and maybe

another product might copy.

and yeah, that's some duplication
of work and they'll use it.

And then we have so much more
information, in those two cases about

how we should design the API design,
the component, which pieces we should

bring in just in like two cases that
when we bring into the design system.

I guess the comp would be, I think
we at least wanna get to bike

stage of something, of a component
before we bring it into the design.

Like all the skateboards and scooters
and shit, they should be like in the

product, but like we should at least be
a bike by time we get the design system.

Colin: Oh my God, I love that so much.

CJ: It, it also like kind of rounds
out your philosophy here, your last one

of critique early and often and with
everyone it's like, yeah, critique and

make sure this is gonna work before
it actually ends up in, in the system.

But also just like generally
probably seems like a good

way to learn and improve.

But yeah, I would love to hear maybe
like tactically how you go about

seeing if something is working or
not working in the design system.

I think it was, yeah, it was like nice
to hear about your experience at the

agency and how sometimes you'd work on
a client project and then it's kind of

like throwing it over the wall and being
like, I don't know how well that did.

So yeah.

What has your experience been recently and
maybe what can we learn about how to yeah.

Critique and improve our.

Chelsea: Yeah.

I, well, like from a design,
design design standpoint I.

I think I've gone back on this one a
little bit in that like, it really depends

on who you are and your personality.

I think I've I'm like pretty outgoing
and so I'm pretty comfortable like

talking to anybody about feedback
and like critiquing with like, With

engineers, with designers at any stage
in the process and being able to like

say like, actually that's not relevant.

Like just like sort through
all the crap like on the fly.

I think I'm someone who like thinks
through speaking a lot, so that's

like helpful in critique situations.

I have now worked with a lot of like
more different styles of people and

I think there are people who just.

Need that time away.

And so if you, if you're critiquing
like all the time, if you like, and I

have these phases too personally, where
like, , I need to think in private.

And I think there's people I've worked
with who are like brilliant that like

they work best when they have that
time to think in private and process.

And so I think I've shifted a
little bit and like, why doesn't

everybody share all the time?

Like even if it's messy, even if it's
nothing even, and I'm like, oh, that

just like doesn't work for everybody.

but it works for me.

But to get at your question,
which is like, how do you figure

out if something's working or.

If you have a Slack channel, you
figure out pretty quickly, cuz

everybody complains like immediately.

So, like I said, that like if you're
working on a design system internally,

that feedback like, like if it's
adopted, I think there's different

stages where like some people are
like working on adoption, so they

have to do a lot more advocacy.

Most of my experience has been starting.

On a design system that is like, already
in place, at least to a certain extent,

and then like, like working on the
things that it, that are already in use.

And so when you're at that stage you get
the feedback like pretty constantly and

immediately , it's like, what's wrong?

And so I feel like the, the challenge.

For me has mostly been how to prioritize
because you get like such a big

volume and everything feels important
because everything is scaled up.

And so it's been like a
struggle for me actually.

Personally having like a, like a medium,
ADD spectrum kind of brain is like,

that's important and that's important and
that's important and that's important.

And then like having a hard time, like
really getting to focus on any one thing.

And so I think a lot of, at that
stage for a lot of design systems,

it challenges prioritization.

It's like you have so many things
that you could be doing because

nothing is ever perfect because
it doesn't work for everybody.

And so I think you really have to figure
out like what what individual change

will have the most the most impact.

For your first line users, so your, your
internal users, engineers, and designers.

Like, like if I were to work on one
component, how would that change the lives

and efficiency of designers and engineers?

And then you also have to think
about the second order impact.

So how is that gonna affect users and
I think often those things are in line

where like if you make something easy to
implement and it is the right pattern,

more people will use the easy thing.

So if it's also the right
thing, then that gets to users.

So often they're in line, but
it doesn't always feel like it.

And sometimes you really have to like
bend your brain to figure out, you

know, where the effects are because
the, the effect is also like slow.

So the feedback is fast.

But the seeing it like, like if you
introduce a new pattern that you think is

good, you have to wait quite a while for
like, engineers to use it for then to make

its way to users for then you to collect
feedback on how users are reacting to it.

Like it doesn't, it doesn't,
it happens pretty slowly.

So like a side effect of that is
actually that, like, I think the,

like quarterly like reviews and
evaluations and goal setting and OKRs

have been tough for me personally
in design systems because often the.

Metrics change in usage or the the, like,
the feedback from users doesn't happen

in the same quarter that you do the work.

CJ: Mm-hmm.

Chelsea: And so that's been a challenge.

CJ: I wonder if like a
shortcut that I've seen?

Oh, a shortcut that I've seen recently
is people just like designing something

in like Figma or Sketch or whatever,
and then jumping on user calls and

showing them pictures like it doesn't
actually work yet, or it might sort

of work, and then trying to get
early, early feedback like that.

But yeah, I, I totally.

Understand that like the long term,
long tail seems like it would be

sort of exhausting and very different
from like that really quick iterative

feedback loop that you want.

Like when building stuff on the web, it's
like, oh, I, I made a change and next

js just refresh my browser over there.

So

Chelsea: Yeah.

Yeah, I think like in product
that works really well.

I'm actually like in the
middle of doing that right now.

I have like these really early wire
frames, so I'm like talking to users.

I'm like, this is, this is a mess.

So like it's fine.

Just tell us everything like just no
judgment, like this are just rough ideas.

Trying to understand the flow and
mental model and just showing those.

I think for design systems, there's
so many, like there's how it looks.

, there's how it works for a user and
there's the developer experience

that often I think those things
are like, sometimes there's so many

things you have to get feedback on.

We started this process at Lattice that
I think has actually worked pretty well.

It's not super fast, but like I
basically put together a a design

doc which, you know, means one thing
to engineers and a different thing

to designers, but it's like one
doc that does both of those things.

So, articulating like what the API
of this thing will be, what the, and

then like showing mockups of like what
the actual like spec of the component

will be, and then sending that round
to like, all of the product teams and

all of the designers and saying like,
this is how we're gonna build this.

And, and having like a period
of, of like an like request

for comment sort of period.

And that's, that's worked pretty well.

So like before we roll out a, a big
system change, like put together

one of these design docs and just
like tell all the teams, here's what

we're thinking about, what should,
like, are we missing anything?

And then giving them an idea
of how we're gonna roll.

Colin: Awesome.

Well, I think that's a great
place to wrap things up.

We can leave our listeners
wanting some more.

They can head over to check chexee.me.

We'll put that in the show notes.

So you can check out where you can
find Chelsea and all of her work.

Maybe she'll add some more philosophies
as she develops them in her future roles.

And yeah.

Thanks so much for hanging out Chelsea.

Chelsea: Cool.

Thanks for having me.

CJ: Yeah, thanks ton, Chelsea.

You can find the show notes
and all of the links to the

resources at buildandlearn.dev.

Thanks so much for listening,
and we'll see you next time.

Colin: Bye friends.