RICK VISCOMI: Hello,
everyone, and welcome back
to "The State of the Web."
My guest is Brad
Frost, web designer
and author of "Atomic
Design", and today we're
talking about design systems.
Let's get started.
[MUSIC PLAYING]
So, Brad, thanks a
lot for being here.
BRAD FROST: Thanks
for having me.
RICK VISCOMI: I
want to start off
by asking you, has the
metaphor of a web page exceeded
its usefulness?
BRAD FROST: Yeah,
it certainly has.
As web designers,
we've been thinking
about the web in terms of
pages for a long time, right?
It's been with us since
the web's beginning, right?
We scope things out
in terms of pages.
If things don't
load in the browser,
it says, this web
page hasn't loaded.
And that's had a
really big impact
on how we structure our teams,
how we scope our projects,
and how things are actually
executed from a web design
and development standpoint.
So for instance, I work with
a lot of large organizations.
And so they'll have a team
that's responsible for the home
page, and then they'll
have a team that's
responsible for
the product page,
and another team that's
responsible for the checkout
page.
And all of those
teams are doing things
independent of one another
because they're just focused
on this notion of pages.
And as it happens,
all of those pages
are actually made of
the same stuff, right?
If we were to break things
down, you have buttons,
you have form fields, you have
blocks, and cards, and heroes,
and all these other things.
And what we end
up with, whenever
you have these different teams
working on different pages
and thinking about
things in that way,
you end up with one button
looking similar, but different
than the next team that's
working on the next page,
and so on and so forth.
And you repeat that a
number of times and span
that out over a number
of years, and you
end up with a giant
mess on your hands.
RICK VISCOMI: It's
not to suggest that we
should stop using the term.
It's probably still useful
for users who only see things
as a flat page.
But from a design and
development perspective,
it's kind of outdated.
BRAD FROST: Yeah.
That's right.
Exactly.
It still comes together
as a cohesive whole.
And I think that's
important, especially
as people get into talking
about design systems.
A lot of people have
a big misconception
that, oh, design systems
mean you just isolate things
at their component level
and just design the button
and just design the
headings and just design
the card in isolation.
But that's just not true.
It's important to realize
that, yeah, things
do-- all of those
components do come together
and form a cohesive page
at the end of the day.
And that's what the user
sees and interacts with.
So it's important to--
it's not an either/or
thing, but we just
have to be more
considerate about how
we make the parts of that page.
RICK VISCOMI: As the web
and technology, as a whole,
progresses forward, how
has that changed the way
that web designers think
about serving pages
to users and the ways that
the websites are accessed?
BRAD FROST: Yeah.
Well, from an access
standpoint or from a design
and build process?
RICK VISCOMI: The fact
that a user could be--
I mean, even these
days, accessing the web
from their
refrigerator, you never
know the form factor or anything
about the user's device,
so you can't make
any assumptions.
BRAD FROST: Yeah.
Yeah, that's right.
And it's gotten
really complicated.
And that's why I think
design systems have become
as popular as they've been.
Because the devices
haven't slowed down, right?
The device proliferation
is still happening, right?
The number of contexts
and screen sizes
and form factors and
native web embedded
devices, different screens,
different mouse and keyboard,
touch inputs, and voice,
and all this other stuff.
It's just the amount of things
that designers and developers
have to consider as they're
creating user interfaces
and creating these experiences
have just accelerated,
and we can't keep up, right?
We can't create
bespoke pages for,
here's our small screen view,
and here's our tablet view,
and here's our desktop view.
So we've had to pull
back out of necessity
just because we're on the hook
to deliver more features, more
services, to more
users, and more context,
using more devices in more
ways than ever before.
And it's like, unfortunately,
our budgets haven't increased
and our resources haven't
increased with that same sort
of exponential curve.
So that's what's forced us
to step back and reconsider
how this all gets done.
RICK VISCOMI: Given that there
are so many different viewport
sizes and everything, does that
mean that the flat Photoshop
file is no longer very useful
as a means of conveying
the design?
BRAD FROST: Yeah.
Yeah.
And still, to this
day, I'm working in--
Photoshop might be a
little long in the tooth
when it comes to web design.
But same thing happens
in Sketch and Figma.
Just last week, I got,
from a client's designers,
a mobile version of a comp
and a tablet version of a comp
and a desktop version of a comp.
And a lot of that's just sort
of wasted effort, really.
Because all three of
those things in isolation
are sort of-- one,
they're already
a lie because it's a
picture of a website, not
an actual website.
But all of those
spaces in between
is where things
really fall down.
You could paint a
picture, especially
in a static design tool,
where there's art boards,
and you can just sort of move
things around in free space.
That's not how things work
in the actual browser.
There's things like source order
considerations and all that.
You can't just go,
on this size screen,
I just want to move
this from here to here.
This, I'm just going
to swap this around.
It's really important to
make sure you're considering
the actual medium that
this user interface is
going to come alive in
and do that much sooner
in your process.
RICK VISCOMI: I want to ask
you about a concept you've
used before called design debt.
What does that mean?
And how do you avoid
going design bankrupt?
BRAD FROST: Design debt
and design bankruptcy--
I've never actually heard
design bankruptcy before.
I like that.
I think a lot of places could
declare design bankruptcy.
I think, just when it
comes to design debt,
you have number of teams
working on different things
and, just as we
were saying, working
on different pages or different
products across a company.
And you can take a cross section
and see a lot of discrepancies
just in that.
But that's just
one moment in time.
When you stretch out that
process over time, especially
products that have been
around for a long time--
the Googles of the world,
or eBay, or whatever--
it becomes a little "Benjamin
Button"-like experience.
As you click through
pages, you get further back
in time in these older,
crustier user interfaces.
You're like, how did I end
up in 1999 all of a sudden?
So I think that that's sort of--
that visceral feeling of design
debt where it's, like, you
have all of this old stuff that
was created once upon a time.
And whenever that was launched,
it was the new hotness.
And the new hotness becomes
the old crusty experience
pretty quickly
these days, right?
So I think that the more
deliberate and the more
systematized you can
control and wrangle
all of those user interfaces
that are out there in the wild,
the better your
chances are going to be
at reducing that design debt.
And that's, again,
I think a big crux--
the crux of design systems is
to help eliminate that debt,
to basically take
those 1999 designs
and say, OK, we're going to
update them with the new design
language.
But we're going to do it
in a very systematic way
so that the next time
we do a big redesign,
we have actual hooks in
there that we can actually
lift up the quality of--
and you evolve that
design language,
like, flip the switch,
and roll that out
to a bunch of places
simultaneously
or in very short order,
instead of, oh, we
have to do this big
monolithic redesign.
And we have to do that for
each of our products again,
and again, and again.
RICK VISCOMI: So the
developer experience
must be a lot better when
you can have a single source
of truth for your design.
But also, the user
experience, as well,
could you describe what it
might be like for a user to be
on a site that has design debt?
BRAD FROST: Yeah.
This happens all the time.
The e-commerce example is a
great one just because I think
that e-commerce sites--
super sexy home page, the super
splashy, super current, right?
It's got the latest shop
fall trends or shop Christmas
coming up or whatever.
It's very campaign-driven,
so it's often
a very modern experience.
You click into, maybe a product
detail page or a product
category page, that
feels modern-ish.
You know, it's a little
bit more meat and potatoes,
like e-commerce stuff, so it's
like those templates probably
feel pretty good.
But then, you might get
to the shopping cart
or if you actually
log into your account,
it's, like, those things
feel way different.
And then you get to
the checkout flow,
and then that might be
way long in the tooth.
Or it might be built by an
external vendor or something
because they're
processing credit cards
and stuff like that.
So it might not actually
be integrated with the rest
of the site at all.
So what ends up happening--
why that matters, from a user
experience standpoint--
it's not just about,
oh, things look different.
Because who cares?
As long as that's
effective, then--
consistency shouldn't
ever be the number one
goal of any of this.
And I think that, when we
talk about design systems,
I think that's
another misconception
is that, oh, we
just want everything
to look the same everywhere.
And that's just really not true,
because, if your metrics are
doing well and stuff,
and the buttons look
different on the checkout page
than on the product detail
page, then that's fine, right?
No harm, no foul.
But the problem is
whenever you're a user
and you encounter, say, a
date picker or something--
and this is a
favorite one of mine
just because those
are hard to build.
So oftentimes, developers
just go and grab
something-- a library they
find on the internet somewhere.
And if you're, say, an
airline or a hotel chain,
and you have four different
developers grabbing
four different date
pickers across a site,
now, all of a sudden, every time
the user needs to pick a date,
they have to relearn
that new library.
And even if it's just fractions
of a second or a second or two,
where they're like,
oh wait, I'm used
to booking from the
home page, but this
is a different convention.
That slows down
that process, right?
And that has a negative
hit on, certainly when
you're talking about
booking flights,
or hotels, or something,
that's going to cause a dip.
So that consistency,
from a user experience
standpoint-- that
ability of, oh, yeah,
I've encountered
this pattern before,
and I know how this works.
So I could just roll
on and fill things
out a lot faster or interact
with this thing faster.
That's what we're after, right?
So that consistency
for consistency's
sake-- not so much.
But consistency from
a, mapping to what
users are used to already, like,
yeah, that's where it's at.
RICK VISCOMI: One of the
people problems on a design
and development team is not
sharing the same vocabulary
or calling the same
components consistent names.
BRAD FROST: Yeah.
RICK VISCOMI: So what are
some of the problems of that?
And how can designers
and developers
get on the same wavelength?
BRAD FROST: Yeah.
So that's one of the biggest
things that I encounter is--
and one exercise that I like
to do with design development
teams, whenever I'm working
on design systems with them,
is, right out of the
gate, we conduct what
I call an interface inventory.
So we basically go across
their entire suite of products
or whatever user interfaces
could be served by their design
system and divvy things up.
It's like, OK, you go
hunting for buttons.
I'm going to go hunting for
input fields, or whatever.
And then we sort of
do that as a group.
And then what we do is, we
get together and present
what we found to each other.
And that's where it's
really fun because,
especially whenever you
have designers in the room,
developers in the
room, QA engineers,
business people in the room,
the product owners, all
these different disciplines.
And you actually have to
articulate what your UI is,
right?
So somebody will get
up and it's, like, oh,
and here's this admin bar.
And then somebody
goes, admin bar?
We call that the
utility bar, right?
And then the developers are,
like, oh, we just mark that up
as the gray bar, right?
And so it's, like, OK,
there we go, right?
You got everything out on
the table, these inconsistent
names for the same thing.
And of course, that
means you have to have--
again, just like that
sort of user experience.
You have to slow down.
You have to have a meeting
to figure out what you're
going to call this thing.
And a lot can get
lost in translation
in between design team--
or different disciplines,
but also different teams
in general, right?
If team one is calling it
a certain name and team two
is calling it something else,
that's a big deal, right?
So again, bringing this
all back to design systems,
what a design system can do is
centralize your UI patterns,
call them names, write
guidelines around them
so that everyone is literally
speaking the same language,
right?
They know what you mean
when you say utility bar.
And you know how to use
it and where it's useful.
But also, crucially,
one of the other things
that we found really
valuable in creating
design systems for clients
is, here's what this thing is.
Here's where it's useful.
But also, maybe here's
some gotchas, or here's
where it might not be
useful, and maybe you
want to use this
other thing instead.
RICK VISCOMI: What are some
of the trade-offs of investing
in a bespoke design system
versus taking something
off the shelf, like a Bootstrap?
BRAD FROST: Yeah,
that's a big one.
And I'd say it's
tough because tools
like Bootstrap and Material
Design are already made.
They're there.
They're well-tested.
They're in use by
giant companies
like, this company called--
have you heard of Google before?
It's a pretty big one.
RICK VISCOMI: It
sounds familiar.
BRAD FROST: Yeah.
So a lot of these people
who are using tools
like Bootstrap and Material
Design, they're like,
oh, this has been tested
by these giant companies,
so I could just sort
of grab this and go,
and I don't have to do
all that work myself.
And that might be true, and
there are instances of that.
I think one of the
big things that
is important to
recognize and consider,
whenever you're reaching
for these tools,
is that, it's like,
you don't own it.
And it might be attractive from
an efficiencies sake at first.
But as time goes on, at the
end of the day, your boss
or your product owners or your
clients or whoever they are,
they're going to say, oh,
we need to do this this way,
or we need to add this feature.
And all of a sudden, you
have to learn and become
fluent in this other system
that did that you didn't write.
So it can work, and you
can do things and extend
things and customize
things that works
with the grain of
these frameworks.
But oftentimes,
what I found is, I
work with clients that end
up working against the grain.
And they end up having
to undo a bunch of stuff
and write a bunch of
other custom stuff.
And then they end up in this
weird, messy, middle ground
where it's, like, oh,
this our hackey stuff
that we've done to
make things our own.
But then, also,
crucially, I'll say
that from a more of a front-end
architecture standpoint,
I think that it's safe.
You've got good
bones to build upon.
But Material Design
and Bootstrap actually
offer an aesthetic, right?
They provide an aesthetic.
And that can be helpful because,
again, it's, like, oh, here's
some good looking buttons.
Here's some good
looking form fields.
Here's some good looking
components that I could use.
But if Nike, Adidas,
Puma, Reebok, whatever--
they were all to use
Bootstrap for their redesigns,
they would look
frighteningly similar, right?
And that's not what
they're going for.
So it's, like, there is
this branding aspect of it,
this ownability that gets
lost whenever you're all
using the same thing.
RICK VISCOMI: What are
some of the challenges
or unsolved problems of design?
BRAD FROST: Of design?
I mean, tons.
I think, specifically to
design systems, a lot of--
there's some things that are
around tooling and figuring out
how to keep design tools and
tools like Sketch and Figma
and stuff in sync
with what's in code.
That's definitely one of almost,
I feel, tangible problems.
But there's a bunch of
teams doing a lot of work
to try to solve that
and startups and stuff.
They are really exciting, and
a lot of them look promising.
And I don't necessarily
think that that's
far and away the biggest
problem that's out there.
I think so many of the
problems with design systems
have to do with the people,
have to do with communication
and collaboration,
and figuring out,
how do we get this stuff adopted
into our products, right?
How do we communicate
when things
aren't working as planned?
How do we establish
solid processes
for releasing new versions
of the design system
and letting everyone
know, here's
when you want to use
the design system.
Or here's when it's safe
to deviate from that system
or build upon it or extend it,
and how do you roll that back
into the system?
So a lot of that coordinating
a bunch of different people
who are all suddenly relying
on this design system
product, that stuff, I
feel, is still very tough
to crack because
it involves people
and the health of your design
and development culture
and how well everyone
collaborates together.
And of course,
that's tricky, right?
I could say things like, here's
how I would create a governance
plan for a design system.
And here's how I would get these
teams to work and communicate
more, but it's easier
said than done.
RICK VISCOMI: So how much
of a design system's success
depends on the designers as
opposed to the developers?
What is their role
in the success of it?
BRAD FROST: I think--
and this might be a
little controversial--
design systems is
an unfortunate name
because design systems are
like, oh, this is about design.
And it's really not.
Design system is, as I define
a design system, is how--
the official story of how an
organization designs and builds
digital products.
And there's a lot of
ingredients to that story.
And yes, the design language--
what the brand colors are
and the rounded corners or
not of the buttons and stuff
like that-- sure, that matters.
But that's actually
a pretty tiny slice
of what a design system entails.
So when it comes to the
success of a design system,
so much hinges on that
design system living in code
and living as a thing that
engineers and developers can
pull down into their application
and import a component
and see that design
system's button
or whatever show
up on their screen.
And then they're able to pipe
in whatever attributes and click
handlers and whatever to breathe
life into it and make it real.
But they get that
stuff for free, right?
If all you have is
a Sketch library,
or some Zeplin file or
some little style guide
thing where it's, like,
here's our colors,
and here's our whatever--
there's so much that gets lost
if all the developers are doing
is copying and
pasting some hex codes
into their crappy
development environments.
And it's just, you end up
with a bunch of spaghetti
even if they're all using
the same color blue.
It's not systematized, right?
So what you want to get
to is, you want to say,
if we change our
brand color blue--
and this actually just
happened on a project of ours.
I have brand color blue.
And actually, it wasn't
passing the accessibility level
that we wanted it.
And so they actually had to
sort of tweak the color blue
in order to make that pass and
cut the accessibility muster.
With the design system, you
literally have variables file,
or these design tokens.
And you tweak that value there.
And then that ripples out to
the entire design system, right?
And then that gets packaged
up in a new release
of the design system in code.
And then, next
time the developers
pull that down, they'll
see those updates.
So coming back to--
it's like, yeah,
the design language part of it,
the look and the feel of it,
that matters.
I'm not going to say
it doesn't matter.
But it's almost just,
like, do your thing.
Make it look good.
I trust you.
Be systematic about it,
thinking about motifs
that are going to translate
well to different components.
But so much hinges on getting
that stuff into a place
where it's consumable by
the actual environments
that users will be interacting
with your products.
And that's what
we spend probably
the overwhelming majority
of our time and effort
on is actually building out
those libraries with components
and HTML, CSS, JavaScript--
bundling that stuff up and
working with development teams
to make sure that
they have what they
need in order to use
the system successfully.
RICK VISCOMI: So to what
extent should a design system
anticipate the chaos of
user-generated content
like errors and long names?
What is the actual breaking
point of a design system?
BRAD FROST: Yeah.
Well, I think that the breaking
point of a design system
has everything to do with
how well you consider
all of that stuff, right?
So if it's
user-generated content
that you need to
account for in your UIs,
then you have to consider
things like character limits
and things like that.
But there's many other
flavors of that as well--
internationalization,
right-to-left languages,
or German will wrap onto
multiple lines and things
like that.
And this is where,
I think, again,
designing and
building components
in isolation is a bad idea.
Because you could fall
into the trap of saying,
here's this perfect scenario
where everything's filled in,
and the card has this nice
image I found from Unsplash,
and it's really nice looking.
And as it happens, the
user's name is Sara Smith.
And Sara doesn't
even have an H on it.
So it just fits so
nicely onto one line.
And of course, the reality
of our user interfaces
is anything but that.
And this also comes
back to the trap
of relying on these static
designed tools to handle that.
Up until very, very
recently, there
weren't even conventions in
place to handle dynamic data.
So that's how we handle that.
This is where atomic design
as a methodology, I think,
really shines.
So what Atomic Design
does is, basically,
helps people consider the whole,
the pages, the actual product
screens in various states
and configurations as well
as the parts of that whole--
so the underlying components
that build up those screens.
And at the page level
of Atomic Design,
what we're able to
do is articulate,
here's what our home page
looks like with this--
the fall campaign with the
leaves and this tagline in it,
and this call to action button
that takes people to this,
and whatever.
But then you're also
able to say, OK,
and then here's what that same
page looks like in German.
Or here's what that same page
looks like with the Christmas
campaign.
And oh, that image
that we're using that
has a bunch of Christmas
ornaments, that actually
is impacting the readability
of the text that's
sitting over that image or
something like that, right?
So you could start seeing where
the UI starts falling down.
And then, what you're able
to do is take that, and learn
from that, and go back to
that hero component at a more
atomic level and
say, OK, we're going
to maybe add a variation
of the hero component
that adds a little
gradient overlays
so that the
legibility of the text
always pops over the
image a bit more.
So how we do things, like in
our own workflow with that,
we will create--
try to represent the
whole bell curve.
So it's, like, what
does a card look like?
What does a kitchen
sink card look
like with the maximum
character count
that you might be able to
upload as a user or something?
Or what happens if the user
uploads a profile picture?
What if they don't, right?
And so all those various states
and mutations of a component
get that commonly used
case down, of course,
as a starting point.
But you really do have to
represent, here's the extreme,
and here's the empty, and
everything in between as well.
And the only real way to
test if that actually works
is by plugging in
real product scenarios
into your user interfaces.
And by having that atomic
design system wired up,
where the pages informs and
influences the underlying
components, you're
able to make changes
to those components, which
then inform and influence
the actual page design.
So it's sort of like
a virtuous cycle
between like the design system
and the pages and screens
that that system builds.
RICK VISCOMI: [AUDIO OUT]
BRAD FROST: Oh, there's a lot.
I feel like I have a hard time
keeping up with them anymore.
There's a number of
really great resources.
One that I help maintain is a
resource called styleguides.io,
which is a collection of--
I think we're over 250 examples
of public design systems
and style guides that are out
there in the wild, as well
as talks and books and resources
and tools around design
systems.
So that's just an open-source
resource repository
that people contribute to and
submit [? poor ?] requests to.
There's design.systems,
which is maintained
by Jina Anne, who's done so
much work for the design systems
community.
She has a Clarity Conference,
which is a conference dedicated
to design systems.
We have a podcast, which
is a little bit in hiatus,
but where we
interview people that
work at different organizations
who have spun up their design
systems and what they've
learned and struggled
with as they've as
they've done it.
Stu Robson has a really
fantastic design systems
newsletter that's part of the
design.systems universe there.
And then there's also a Slack
group all about design systems
as well.
So I'd say that that has
me covered, for sure.
And again, there's a
lot of activity there.
And new stuff's
happening every day.
And people are learning
from each other
and plugging them in
at their organizations
and sharing what
they've learned.
And that's really, for me,
the most exciting part of all
of this is is just,
here's some concepts.
Here's some things that
we've found useful.
Share those.
People take them,
learn from them,
validate or invalidate
them, and then
share what they've learned.
And then everyone
benefits from it.
RICK VISCOMI: Your book
is also available for free
to read online, right?
BRAD FROST: It is.
RICK VISCOMI: Where
can people find that?
BRAD FROST: Yeah.
So you can read it at
atomicdesign.bradfrost.com.
RICK VISCOMI: Great, Brad.
This has been great.
Thank you so much for coming.
BRAD FROST: All right.
Thanks so much for having me.
RICK VISCOMI: You can
check out the links
to everything we talked about
in the description below.
Thanks for watching.
We'll see you next time.
[MUSIC PLAYING]
