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.
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
It might be like above red pandas, but you
Chelsea: the jury's out.
Like it depends on the day.
Colin: karaoke is just in there somewhere.
It's so something that you can do,
Chelsea: We do together.
So, you know,
Colin: get Penny into that early.
Chelsea: Yeah, I'm actually
in my basement and our home
karaoke setup is like over there,
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.
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
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.
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.
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.
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.
Chelsea: It's all very dated content.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
What has your experience been recently and
maybe what can we learn about how to yeah.
Critique and improve our.
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.
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.
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.
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.
Thanks so much for hanging out Chelsea.
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.