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]
