RICK VISCOMI: Hello,
everyone, and welcome back
to The State of the Web.
My guest is Adam Argyle.
He's a developer
advocate at Google
and creator of the
VisBug design tool.
And today we're talking about
the state of design systems.
Let's get started.
[MUSIC PLAYING]
Hey, Adam, thanks
for being here.
So I want to ask
you, what purpose
does design fulfill
on a web page?
What are its goals?
ADAM ARGYLE: That's
a good question.
At a high level, I feel like
design does a couple things.
We have-- it's supposed
to be guidance.
You want to have credibility.
So it's like the
better designed it is,
the more credible
it feels, right?
You don't want to
spend money somewhere
where it looks like there's no
design, even though that might
not accurately
reflect the product
or what you're investing in.
But I like thinking about, at
a very, very high level, what
design is doing is we
have affirmative design
and we have critical design.
And critical design
is the type of design
that is exploratory, that
sort of provokes you.
Brutalism is a good example of
critical design, where you're
looking at something
that's like, wow, this
is like stark and shocking,
even though it's sort of retro,
in a way.
So design can do really
interesting things
to your psyche, in terms
of challenging you.
Or we can see more of this
affirmative design, which
is kind of getting more
popular, it's safer,
where you're sort of piling
onto the social norms of what's
going on in design, because
it's safe and it's familiar.
And so folks will
visit your site
and they might feel
lulled into an action,
because they visited and
it's beautiful and airy.
And they might be looking
at something terribly not
attractive, like, let's say,
a scrubber for your sink.
You can make a scrubber
and a sink look very nice.
So you visit the
site, and it says,
do you have problems with your
sink feeling dirty and nasty?
Well, we've got the
scrubber for you.
So it's like every
design states the problem
and then brings in the solution.
And that's sort of lulling
you into this behavior.
They're like, ah,
isn't this familiar?
You're here.
It looks like a normal ad.
It has the normal flow.
Let me guide you down
this path and we'll
take you through this
excellent experience.
So design does
both those things.
That's really high level, too.
It does a whole bunch
of other stuff, too.
But yeah, I think that's sort
of what it's trying to do
is credibility,
flow, somebody else
has done the work to
organize it for me.
So it's supposed to be easy.
I'm supposed to be here
to consume quickly and get
a task done.
RICK VISCOMI: Guiding the
user towards the solution
for that web page.
ADAM ARGYLE: Yeah.
And in that case, it's
usually the solution
that the web page
wants you to go down,
which is where design has a
little bit of cunning in there.
Some people say design is a
type of trickery, as well,
which, right, we have
like dark patterns that
are like legit trickery, or we
have a light pattern switch,
where it's trickery where
we're just sort of like,
no, this is just a
healthy guidance.
You can diverge.
It's OK.
But yeah.
RICK VISCOMI: So in terms of
the tools that designers have,
what is a design system
and what are its goals?
ADAM ARGYLE: Ooh.
So a design system,
that's sort of--
that's a hard one to nail down.
It's gone through
all these phases.
My current opinion on
what a design system is,
is where we previously had
design deliverables that
were sort of like
a design system,
and then we had engineering
deliverables that
were kind of like
a design system,
what we have with
a design system,
it's a merging of the
two, where designers
have their symbols
in their files
that generally represent the
same components that engineers
are making.
And there's like this
[MAKES ANGELIC NOISES]
coming together moment
in a design system.
That's what I think we're
currently personifying that as.
Where before, engineering
had like a pattern library
or component set and then the
designers had a style guide.
RICK VISCOMI: So what are
some of the principles
of a good design system?
ADAM ARGYLE: Ah, yes, OK.
So at a high level, I
think a design system
intends to make future
us have easier decisions.
Like in the future, I shouldn't
have to invent a new button.
I shouldn't have to
invent a new log in form.
Like these things should
be solved already.
So at a high level, that's
one of its most valuable
propositions is that
future you-- or even,
if you're being
really considerate,
like other customers
of your design system--
customers being maybe
other development teams,
other designers, maybe
even the marketing team.
You have people that
want to use that.
I call them your customers.
So a good design system
is considerate of them
and it empowers them.
But at a low level, when you're
implementing a design system,
you should have things like
reusability, extendability.
You should have
accessibility built in.
Essentially these
LEGO pieces should
have solved a bunch of problems
for other people already
and be battle tested
and have gone through--
OK, I'm gesturing right
now, but the gesture
is, imagine a rock that
I'm tumbling into a pearl.
Like we'll take and then we'll
have a bunch of pearls to give,
so that other people can
get their task done easier.
RICK VISCOMI: And
also, there's something
about that where you
need interactivity
as part of your design system.
ADAM ARGYLE: I have seen some
design systems that don't just
talk about the component.
They give you levers to pull.
So you can visit a page--
and there's some tools
out there that do
this, like a Storybook is one.
We have other tools coming
out, like Framer X. So there's
design tools that are coming out
either very focused on this one
particular use case,
or you have ones
that are a little bit more
documentation focused.
So they're less like
compose and build, and more
like, no, tinker and play
and assess what component
you need beforehand.
And I like that
tangible learning.
It's really nice, especially for
someone visual like a designer,
to come into a
design system website
and peruse and find a component
and be curious and play.
It helps to get really
sticky the features
and the capabilities of that.
RICK VISCOMI: In terms of the
life cycle of a design system,
is it ever really done
or is it more iterative?
ADAM ARGYLE: Ha ha, done, ha ha.
No, I think they
really only grow.
I have seen them be reborn.
Or we've seen them
be reborn with brands
or they're reborn as
complete redesigns.
But no, I don't
think they're done.
I think they're growing.
I think we're making teams now
to facilitate these things,
because they are so difficult.
And they only grow
in complexity.
Because, well, there's
considerations that
are often lost, like mobile.
A lot of design
systems are like,
look at our sweet
desktop design system.
And you're like, cool,
what's it do on mobile?
We're like, we'll get there.
Same with accessibility
and layouts.
And anyway, there's
a few other things
that I think some
design systems can
do to grow and be even better.
And I think that's just what
we're discovering right now.
Folks are playing,
and they're trying
to figure out what aspects
of the design system
are really meaningful
and what's crufty.
And we're a young industry.
We're all still learning
what this means.
RICK VISCOMI: Do you
have any examples
of older design systems that
we draw inspiration from today?
ADAM ARGYLE: Ooh, yes.
OK.
Ooh.
OK, so old design systems.
I have a bunch of them
that I'm a big fan of.
We could go back, in terms of
like inspiration and things
that are influencing
what we're doing today,
and go back to print,
and be like, print,
you made beautiful style
guides or brand guidelines.
You would give
LEGOs to a client.
And that client could go
put them on an envelope.
They could put them
on some stationery.
So that was a very early
set of LEGO deliverables
that had some rules
and some intentions.
Then you have operating
systems that feel very much
like design systems, as well.
Right?
The first iPhone had a
design system for sure.
They even had a
document, the HIG, right,
the Human Interface Guidelines.
I would like to see more
design systems have a HIG.
That'd be super cool.
All right.
And then we had
Android with Halo-- oh,
these are inspirations to me--
Android with Halo.
Remember that one?
Dark and glowy.
Everything looked like it
had like lightning bolts
or like neon around it.
Actually, you know
what it looked like?
It looked like that Batman movie
with the-- it was like a UI
based on that.
It was just, it
was kind of cool.
That's right.
We had platforms.
We had--
RICK VISCOMI: Web kits.
ADAM ARGYLE: Oh, yeah.
So this is like Material,
Bootstrap, HTML5 boilerplate,
JQuery Mobile.
Yeah, those were-- and
what did they call those?
You're right, those
weren't design systems.
They were component libraries.
RICK VISCOMI: Like
a UI framework.
ADAM ARGYLE: UI framework, yeah.
Pattern libraries.
They had all these
interesting names.
I think we also take
inspiration from fashion.
We have this kind
of goal right now--
I have this metaphor I like to
think about a design system.
It's like you're trying
to make a capsule wardrobe
that everyone else in the
company should want to wear.
You're like, OK,
I'm the designer.
We need to make uniform
looking things across our site.
And they should be familiar and
elegant, and blah, blah, blah.
So what they do is they go
make this design system that's
essentially like making
a set of wardrobe,
like you can't screw this up.
Just walk in the closet, grab
a shirt, grab some pants,
grab some shoes, grab a hat.
Who cares?
It all goes together.
And that's a term from--
well, I learned
it from Pinterest.
But I don't know where
else it came from, though.
But the capsule wardrobe idea
is this grab-and-go wardrobe.
And we're trying to make a
grab-and-go design system.
I'm gonna hop in, grab a couple
things, make a new layout,
be on my way.
So fashion, I think,
is influencing us.
In that way, too, they
want to be very minimal.
Right?
It's almost like Marie
Kondo your wardrobe.
Like go in and pull
all the stuff that
doesn't fit in the capsule,
make a reduced set.
Reduce your anxiety by
reducing your options.
RICK VISCOMI: But I have
a question about that.
When you limit your wardrobe,
or you limit your UI elements,
is it true that you can have
one size fits all UI elements?
Or sometimes you
need to reach out
and do use new and different.
ADAM ARGYLE: Ooh.
Right?
Because you don't want to
wear my clothes, do you?
RICK VISCOMI: No.
ADAM ARGYLE: You should like,
dude, your wardrobe is--
well, it looks
like your wardrobe.
Like what if I want to have
my own looking clothes?
And this is where it comes
down to like, well-- and have
two opinions here.
One is I don't
think designers want
to wear other people's clothes.
So to me, it's a
little interesting
that we're trying to unite.
I think the goal is
super right, like that we
do need to make reusable
LEGOs that are extendable
and are helpful for
future problems.
But at the same time, the more
you try to abstract and reduce
these very subjective
visual emotional things
into little units, they start
to feel very functional.
They lose some of that
excitement, that creativity.
And I think people want to start
breaking out of your design
system at that point.
They feel trapped.
So there's like a--
there's a struggle here
with design systems, which
is we want to empower everybody,
but we want to not be trapped.
We want to be able to
pick clothes every day
that are really easy for us.
But then we want to be able
to go out to a fancy dinner
and not look like we're dressing
from our capsule wardrobe.
And especially if
we have customers.
Customers want to have
unique aspects of the site.
And so naturally, they're always
pushing on the design system
to extend even more.
This is a good shout out to
Material and Google Material,
the new version looked at what
their customers were doing,
which the customers for
Material is tons, right,
people all over
the world using it,
from dashboards to mobile apps.
And in that case, they looked
at how people were using it.
And people were
constantly customizing it.
They didn't want
Material vanilla.
They wanted Material with my
flair, whatever that flair was.
Like I want grunge Material--
well, doesn't exist.
But maybe I should make it.
But yeah, they looked
at their customers
and they empowered them
to customize and extend
Material as a base.
I thought that was
really observant.
And it was research based.
It's just a very, very nice
plan for the next version
of a design system to so
heavy into customization
and enablement of
people to fork.
It's almost like
they're letting people
fork to manage their own, and
they can still pull updates.
RICK VISCOMI: That's
a really great segue
into my next question,
which is, there
was a comment on
our previous video
in March, the State of CSS,
with Una Kravets, our guest.
And this commenter--
ADAM ARGYLE: She's cool.
RICK VISCOMI: --Twisted TV says,
the problem I'm seeing lately
is that most websites
now look the same.
It's like they all have this
standard template or something.
Unlike back in the day
when Flash was a thing,
people use to create out of
bounds designs along with tons
of nice animations.
But nowadays everything
is flat, all gridded up
the same way, with a few
minor positioning tweaks
here and there.
I miss those kinds of designs
that today we rarely now see,
all because everyone is now
into this flat and blocky design
look.
Slap a few fonts on a page
and add a few pics and color
on the background
and you're done.
That's 2019 for you.
What do you think about that?
ADAM ARGYLE: Working
in an agency,
even working at startups, we
couldn't take a lot of risks.
And we're moving so fast
that the only thing to do
was affirmative design.
I think what this
question is kind
of poking at is affirmative
versus critical design.
And they're upset that
everybody's gone affirmative.
They're like, ah,
you're just piling
on to the currently
socially acceptable design
patterns and strategies.
That's so lame.
Which I agree, cause I built
a lot of Flash websites.
And yeah, you could land
on one of my experiences
and it was like
you're in a fishbowl.
Right?
It's like fish-- yeah, you can
hover over the treasure chest
and it would pop open and
bubbles would come out.
It was way more critical design
and way more experimentation
and creativity.
It was like you were unfettered.
But at the same time, if
we think back at that--
because there's, I think, a lot
of joy and fun that was there--
it was less serious and
it wasn't really achieving
inclusive design, as well.
I think one of the reasons
folks, other than being safe,
is that flat and choosing
these modern strategies,
they really make
accessibility easier.
Because you're not
going critically.
You don't have to go undo
something to be inclusive.
So I think inclusive
design, which
is a really impressive
and great push that we're
doing right now, is
also kind of inhibiting
some of our
exploration, because we
want to be able to reach
as many people as possible.
And affirmative
design is lulling.
You visit it and you're
like, all right, well,
I don't really have to
stress while I'm here
or do very much deep diving.
There's the navigation menu.
There's my primary
action button.
If I scroll down, yup,
there's three little things
that tell me about the feature
the features of this products.
Oh, Harry Roberts, today.
Harry Roberts today
writes this thing--
basically he's like
re-quoting this person.
RICK VISCOMI: Yeah.
I have the quote here.
"Flat design and the
rise of more and more
digital 'products' does
seem to have killed off
a lot of that exuberance
and experimentation, which
is a huge shame.
I miss the days of
seeing what adventurous
and out-there things people
were trying to create."
ADAM ARGYLE: You would
log in every day just
to see what crazy
stuff people built,
whether it was Flash or web.
I feel that.
And I think, there's
another tweet,
I can never remember
the guy's name.
I think it's John Gold.
[GASPS] I remembered
someone's name.
Wow.
RICK VISCOMI: We'll have it--
ADAM ARGYLE: I know
your name, too.
Yeah, Rick Viscomi, um.
That's a great name.
This tweet, though,
had two images up.
And it was like, which
site are you building?
The one on the left or
the one on the right?
And they're pretty
much identical.
They're like big.
There's a nav bar at the top.
There's a big header image
with big ginormous text in it
that's like, there's a problem.
And then underneath that, it's
like, we got the solution.
Right?
And they're both there,
and they're the same.
They're like practically
the Bootstrap templates
that you could get for free.
They're practically the theme
for every WordPress site is now
looks like this.
And the coolest and most
creative and critical ones
might have a video playing,
right, with text over top.
Like ooh, they put some
extra effort into that one.
That picture is animated.
RICK VISCOMI: Do you
consider Bootstrap
to be a design system?
ADAM ARGYLE: I do.
I don't think they do.
Well, and maybe this
comes down to where
I'm curious about what
a design system is
and how it's different
than a pattern library.
I think, I think it's that
designers were more involved
in a design system,
whereas like Bootstrap
is very developer led.
I think design kind of
came in a little bit
later, after their LEGOs
got really popular.
And so yeah, I think
they're a design
system that just kind of got
there in a different way.
The result, the
thing that they have,
the tangible thing I can
go pick up off the shelf
and just like place in
my tool belt, right--
I'm Wayne right now
from "Wayne's World."
So I just grab my-- from
the back of the car.
If anyone remembers
the shockers.
Anyway, whatever, that's
Bootstrap right now.
I could go get
that off the shelf
and be immediately
useful with it
and solve my future problems.
It's like the same
value props that I got,
and we're sharing
about a design system,
you could get them
from Bootstrap.
But it doesn't call
itself a design system.
I can't remember what
their home page says.
I think they're one.
RICK VISCOMI: So according
to the http archive,
Bootstrap is used on one out of
every four websites, at least
in some fashion, which
is a surprising stat.
ADAM ARGYLE: Kudos to y'all.
RICK VISCOMI: But could that
contribute to this feeling
that websites are all looking
the same, if 25% of the web
is using Bootstrap with
the same type of layout.
Is it possible that Bootstrap
is a victim of its own success,
in a way?
ADAM ARGYLE: Woo.
I like that phrase,
victim of its own success.
Yeah.
Yes, I think they are.
This is funny.
This reminds me of two
metaphors that I want to share.
Like Bootstrap is funny.
Like if you think
back to high school,
there was probably
a super cool band
that their album just came out.
And you were like, love
that band, so cool.
And you listened to them a ton.
They made a second
album, Bootstrap 4,
made a second album.
And you're like, this
band's still cool.
Or Bootstrap 3.
And then, it gets
really popular.
And everyone's
listening to them.
And it's like some fool
who you don't like shows
up wearing the band shirt.
And you're like, OK, that's it.
Done with this band.
And you start calling
them a sellout.
And the reality is, it's
like, they're now popular,
they're now making money,
they're successful.
You should be happy for them.
But instead, you're
turning your nose up
in like this defensive
disgust, like, eh, I
don't want to use it anymore.
Even though all the stuff
you've built with it was great.
All the music and moments
you had with that band
were really nice.
But it's hard for anything to
stay in fashion for too long.
That's kind of like the second
metaphor is like the wardrobe.
We all had favorite stores we
shopped at back in the day,
whether it was Zoomiez or
Gap or whatever, right.
And these were places we went
to go make easy decisions that
helped us get on with our
day, and that we were still
picking something relatively
cool and meaningful.
But then it just gets old.
We're kind of rude as humans.
We burn through
stuff all the time.
We consume it, and we're
like, this is so good
and then we throw
it in the trash.
So I think bootstrap is a
victim of its own success.
But it's also very
much still a success.
I think being
successful is hard.
I mean, look at any
big framework of like
whether it's a JavaScript
framework or a big design tool,
as soon as you hit the big
shots and you're the cool one,
everyone wants to take you down.
And that's a hard life to be in.
So Bootstrap, stick it out.
I think it's still
a great product.
It's obviously just
reaching a different market,
almost like the pop band.
Right, the pop band Green Day.
Loved their first couple albums.
Third one came out, pah!
I didn't want to play
that band anymore.
But they reached a
whole new set of people.
And those folks fell in love
with them in a way that I
didn't.
And I shouldn't say
that Green Day is bad.
I should say that
Green Day is successful
and they're reaching new people.
And I still like their "Dookie."
RICK VISCOMI: So you've
spent a year as a UX engineer
at the Google Cloud
team, as a design systems
engineer, so to speak.
What was your
experience on that team?
ADAM ARGYLE: Yeah,
that was really--
that was, oh, it
was so illuminating.
So yeah, I was a--
my title was really long.
You ready for this?
I was a UX engineer on the
design systems team of GCP
through a design lens.
So they have two different
types of UX engineers.
There's a UX engineer engineer.
And then there's
UX engineer design.
So I was on the design side.
I was in a team of
four or five other UX
engineers who were supporting
the design system, which
had a big team.
And this was really cool, to see
how much commitment Google had
to their design system, in so
much that this team was made up
of three teams.
There was a trifecta.
[MAKES ANGELIC NOISES] It's
like the tri force of folks
were managing that
design system.
That design system
is creating jobs.
And it was really interesting
to see how all of them
were working together, what
problems they were solving.
And there's two things
I want to point out.
The first one, I think is
really interesting in meta,
which is Google--
here, I'll just start
with the first one.
It was built on Angular.
So it was Angular, which was
transitioning from Material one
to Google Material.
And Angular was doing a
good job at this work.
The struggles that they had were
with how many customers that
they had.
So this is where I like
this meta comparison.
You have Google Clouds
and their design system,
which they call their design
system a condensed version
of Material.
So it's like a child theme.
It's like they forked
Google Material
and made an enterprise
condensed version that's
not as airy and fluffy.
That's interesting
because that means
Google Cloud is a customer
of another design system.
Simultaneously, they have
hundreds of customers.
So they've got customers
that are internal.
App Engine.
There's like various products.
And each one of those
products has a team.
Each one of those
teams are consumers
of this design system.
That's crazy.
Then you have
third-party players.
People that want to add plug-ins
or other support and other
features into GCP that also
want to use your design system.
So they had this really,
really unique scenario
where they were simultaneously
a customer of a design system
and a producer of
a design system.
But anyway.
Yeah, it's meta.
I liked it.
And they were really
adamant and very good
at listening to all of
these different customers
and trying to make this
thing work for everybody.
But it's a very difficult task.
They're hiring.
They have tons of headcount.
Because this is--
GCP is humongous.
And they need help.
And the UX teams there are
really fun and really cool.
So if anyone's looking
for roles, GCP in Seattle.
RICK VISCOMI: We'll put a
link in the description.
ADAM ARGYLE: Yeah, sure.
RICK VISCOMI: So you
mentioned something earlier
I want to come back
to, inclusive design.
What is that?
And what is the purpose of it?
ADAM ARGYLE: Ooh, man.
This is-- so inclusive
design, we want--
this is so funny it
has a name, because I
feel like it's the
thing that everybody's
wanted the whole time.
We want our content to be
accessible for as many people
as possible.
Right?
Like why did we have
to put a label on that.
I think the label is there--
and what it means is you need to
have a site that's accessible,
which really means you
just need to test first.
Testing your site
for accessibility
is always this awesome empathy
experience where you're like,
oh, no, my site's
probably fine on that.
And then you go tap
through, you're like,
it works, it's not elegant.
And that's sort of like
inclusive design is taking
that extra step to empathize,
research, ask folks, and adjust
your design to be
more inclusive.
So this can come down to
things like contrast ratios,
font weight thinness, tab
flows, and stuff like that.
RICK VISCOMI: So
looking ahead, what
do you see the role of
components in future design
systems?
ADAM ARGYLE: I think
we're only going to get
more complex as things go on.
We're noticing now that
our components aren't good
enough yet, still,
especially once you
get to inclusive design
areas where you thought
you were done, and then you
go test and you're like,
oh, we're not done.
Sometimes those can shake
the whole foundation
of your application.
And I think it's healthy,
though, that people
are investigating that.
Other future things I
would love to see voice.
We have so much voice
interaction coming in.
Why don't we have a
design system for voice?
I think that would be
really interesting.
Green lines.
I would like to see design
systems providing green lines.
RICK VISCOMI: What are those?
ADAM ARGYLE: Green lines are
an accessibility indicator.
So where a red line
is you just saying,
I intend for this avatar
to be 45 pixels wide and 45
pixels tall with a border
radius of 50%, so it's a circle.
Like it's a traditional way
of marking up a document
to encourage or be precise about
the presentation that you want.
Accessibility is a similar push.
Where you're like, I'm
going to go in here
and I'm going to look at
this little form input.
I'm going to look
at this form button.
I'm going to go and indicate
that these three areas should
be tab indexed this way.
And it's sort of
a designer taking
control of the accessibility
experience and saying--
and just being very deliberate
and clear about what it is
they expect this to do.
And yeah, it's nice.
It's the designers making
those decisions, as opposed
to leaning on
front end to do it.
RICK VISCOMI: And
how about mobile?
ADAM ARGYLE: Mobile is
usually forgotten, too.
So we got components.
Or it's funny, Material
almost did the opposite.
Material is mobile first.
And then you sort of have
to expand on a couple things
to get desktop to work.
Most design systems I see
these days are desktop focused
and then they start to squish
things down as things go.
So I'd love to see mobile
included more in components.
Yeah, good call.
RICK VISCOMI: How do you see the
relationship between designer
and developer evolving?
ADAM ARGYLE: I want to see
them communicating a lot more.
John Maeda recently had a very
provocative titled article,
but ultimately
what he was pushing
for is a switch in strategy,
where traditionally he
was a proponent of design led.
He was like, yeah,
the designer should
be at the top of the
company, maybe even
like making all the decisions.
Like if you do
that, then elegance
is sure to be achieved.
And that's successful
in a lot of ways.
But what he's seeing now,
after a few years of this,
is that engineering is
really, really important, too.
Engineering is required in
order for elegant design
to even be achieved.
So what he's saying
is no designer--
I'm probably going to
butcher this title--
but no designer will
be more successful
than another designer unless
they're integrating themselves
richly with engineering.
The pitch is the designer
isn't necessarily
the leader of the show anymore.
He kind of says you should be
a supporting actor or actress.
And even though that might be
a little hurtsome-- hurtsome--
hurting to your
ego, you can still
go see a movie where the
supporting actor or actress was
the star of the show.
There's just a
relationship that needs
to happen here that's just
richer and deeper integration.
Designers need to
be included more
across the wide array
of design decisions
that are getting made.
And a lot of those design
decisions are made in code.
So designers, get in
there, meet those folks,
sit with them every
day, and try to have
rich conversations about the
engineering side of things,
and get ingrained.
They'll ask you.
And they'll want your opinion.
I think, I feel like engineers
make a lot of decisions today
that they'd rather not make.
And it's just because
no one is there
to do the decision making
for them or to tell them
what it is.
So they have to make
it up as they go,
which puts the front
end engineering
to an interesting predicament.
Wait, I just thought
of something else.
This one is-- this
one's huge for me.
OK, so we, in have the
front end, especially,
the dependency graph is
getting really popular.
And we have back end
dependency graphs.
We have CI/CD dependency graphs.
There's no designer
dependency graph.
So what I want to see is
like two really weird things.
First off, I want
to see design files
Pub/Sub, where I want a design
follow to publish the colors
and publish spacing
units and some
of these really atomic units.
Like think of Tailwind.
Tailwind is this phenomenally
reduced design system.
They have a file.
And I love it because
it's almost like
if you were to-- did you
see the movie "Perfume,
The Story of a Murderer?"
RICK VISCOMI: No.
ADAM ARGYLE: Oh, it
was a creepy movie.
But he did something
interesting,
which he was trying to
distill the essence of beauty
into a thing that he could hold.
I feel like Tailwind did that.
They took a design
system and they
looked at all the
different pieces,
and they started just like
organizing and plucking
them and putting them
into a nice list.
And I like that JSON object.
It's not Jason, actually.
It's JavaScript, which
is another cool feature
of Tailwind.
Anyway.
It's JavaScript file that
is the most reduced design
system into like atomic
units than I've ever seen.
And what I want to see is I want
to see design files publishing
something like that for
a front end to consume.
And then I want a front
end to publish data models
and other things for the
design file to consume.
I want to see a bi-directional
communication happening
between design apps and
front end development.
I want designers in that
dependency graph, publishing
values.
This is like why I
want them in CI/CD.
Like I want designers
reviewing PRs.
I want them creating PRs.
Like, imagine this, like
you're in your design file,
you changed a base
color because it
didn't pass a contrast ratio
over here in some other test.
So you push and
you save a change.
You publish the change, which
creates a PR that other people
can go review.
Designers making PRs.
RICK VISCOMI: Bypass
the developer.
ADAM ARGYLE: Bypass
the developer.
I think it's a decision the
designers were already making.
It just was like this
long winded feedback loop
to get that work in there.
Like, I've got other
crazy ideas, too,
where I think your
design system should
be a dependency graph,
where it clearly articulates
what dependencies it has and
what dependencies it creates
for other things to consume.
I'd like to see designers making
Kubernetes canary deployments.
I'd even like to see--
I pitched GCP on this--
I think there needs
to be a design focused
cloud integration, so that
you've got really rich cloud
dev tooling.
But we don't have rich
cloud design tooling.
Like why aren't there little
design tabs over there
that a designer can go
in, create an A/B test,
which essentially makes a canary
Kubernetes container that gets
deployed to 5% of the users.
Now, designers can be in control
of features of the front end
through some epic and really
cool cloud integrations.
Yeah.
I want designers-- well,
here's a challenge.
I don't know how to get
designers into the back end
dependency graph.
I have like pretty clear ideas
on how to get the front end
and how to get them in CI/CD.
But I'd love it if service
designers were included
in API design and somehow there
was, again, a Pub/Sub mechanism
between these two,
where like the API
team is publishing something
and the service design
team is publishing something.
There's just so much,
so much opportunity
in this space for
designers to get more
richly integrated into the
processes that are happening
on the development side.
It's not creepy.
It's super rad.
Like I want designers
doing [INAUDIBLE]..
Their design systems should be
versions, just like the app.
And optimally,
they should match.
It'd be really cool if the
design system was at v 1.0.21,
and so was the front
end, right, because it
was consumer of that version.
There's a lot of opportunity.
RICK VISCOMI: I think
developers would
like to have relinquished
control over things
like changing colors.
And if the system is built
well, changing the value in one
place, like this
master file, and having
it applied downstream to every
button and everything else that
depends on that color, I
think they would love that.
ADAM ARGYLE: I think so, too.
I think we just
need some tooling.
There's a bunch of
people working on apps.
Last time I did research,
there was like 15 of them.
But it's sort of developers
taking a design system,
building it, and then publishing
those LEGOs in like a design
app.
And so that's what we're seeing.
I was seeing a bunch of
design apps coming out
where developers
are saying, hey,
I've exposed the levers to
these components for you
in this cool tool,
where you can now
go compose our LEGOs together
and build something new
and play in an almost production
feeling like design tool.
But really it's still
kind of prototype-y,
because the code it's
making is kind of, eh.
Anyway, I think we're
headed towards a really
cool integration layer
there between designers
and developers, where they're
going to be richly working
with each other.
And designers will
start to get more
intimate with minor
details about a component,
like what a Boolean is
and why a Boolean is
different than an [INAUDIBLE],,
and why they should care.
Because those things are cool.
I don't think
they're scary at all.
RICK VISCOMI: Does VisBug
actually fit into that vision?
ADAM ARGYLE: VisBug.
Yeah, so VisBug's goal is--
it's got a few of them.
One of them is designer
developer communication.
You know, a designer is
often in their design tool
land over here.
They've got an art board
and everything's placed x-y,
which made it
really easy for them
to highlight multiple
and drag and delete.
They had this
direct manipulation.
But what is a bummer
about that world
is that it doesn't
translate well.
Somebody is always
translating it.
So as a front end engineer,
I would receive one of those
and I start looking at and I
start translating it to code.
And what VisBug does
is it sort of takes
what the developers are making
and lets you inspect their work
like it's an art board.
And I'm seeing folks
that are having
better communication
with their engineers
because they can feel things.
There's like an empathy
that's starting to happen,
because the complexity
that is the front end
is now something that
designers can contribute to.
They can go poke and
inspect and modify
and experience why some of
these things are complex,
or experience how easy
some of the stuff is.
And so VisBug is
definitely in there
in the game to help designers
and developers communicate
better.
It has some features where
if you modify some CSS,
you can show what changed and
screenshot that and send it
to an engineer.
So there's an opportunity to
even be like super articulate
to a developer about
what it is you need.
But it's also, VisBug
has this other goal.
So VisBug is kind of like
Firebug for designers.
Its goal is to
provide the same thing
that Firebug did for developers,
but something for designers.
So give me tooling
that's familiar to me
in the end environment that can
help me make better decisions.
And it does that, I
think, really well.
It has a bunch of
cool features, too.
I'll just breeze over
them really quick.
But there's guides, so
you can hover and see
lines and detect measure--
you can do measurements.
You can hover and instantly
see any styles that are there.
And I've done a lot
of work to make sure
that those styles that you see
are the ones that designers
want to see.
You're not going to
see all the cruft.
There's an
accessibility inspector.
Same deal.
You click it.
You just start hovering
on stuff and it'll
tell you accessibility details.
There's margin and spacing
visualizations now.
So you can hover and see
padding and see margin separate.
So the dev tools
shows them together
and mine shows them separate.
And I support multi select.
So you can multiple
select multiple things,
and as a designer,
or an engineer,
see how the spacing is
creating all that white space.
Like where's the white
space coming from?
Is it a margin?
Is it pushing?
Or is it-- so it's
very interesting.
You can also create--
or, you can't
create, well, now you
can create-- but you can delete.
You can cut.
You can copy.
You can paste.
You can double click
any text to change it.
You can change any
foreground color.
You can change any SVG.
You can-- there's
a position tool.
You can just select
something and then drag it
around the screen and totally
ignore the document flow.
So there's tools to help you
work with the flow, tools
to help you work
out of the flow.
It's about you feeling
unfettered and getting an idea
out right there.
And it should feel fun.
Like I wanted--
it's almost like I
wanted to break the glass
for designers on a web page.
Like we're constantly
pulling down
these magical pieces of paper,
and they feel so far away
for designers.
Like, ah, I can't change that.
I'll just go back over here.
I'll just screenshot it.
I'll come over here.
I'll add a white box
and cover up that
and then, you know, like make
this little Franken-thing,
and then ship that
back to the developer.
And be like, please, can
you do this thing here?
And I'm hoping that
folks start to do
that in the browser, which kind
of comes into another value
prop.
But I do want to
cover really quickly,
like VisBug wants to be more--
well, I have this phrase,
it's democratize the dom.
And really what that means
to me is I want the web
and designing on the web
to be more inclusive.
I remember when it was easier
and we were on Myspace.
And anybody could
just go grab some CSS
and paste it on the page
and be like, oh, that's
fun, that makes my brain
tingle in a nice, fun way.
RICK VISCOMI: For
better and worse.
ADAM ARGYLE: For
better or worse, right.
VisBug's the same way.
For better or worse, people
can go visit a page and play.
But I think what that does
is it opens up for children
and adults to feel
like they can play,
like it's now kind of a
sandbox, which simultaneously I
think we start to-- like when
you start to learn by playing
at first, there's just
something different
about starting that way
than going to school
and starting all serious.
So I'm hoping that this can
help people who are serious
but also help people
that aren't that serious,
be more inclusive.
And I forgot whatever the second
thing I was going to say was.
But yeah, I mean there's lots of
interesting features of VisBug.
But it's trying to help,
wants to be the design
debugging tools.
Des tools, perhaps.
Ooh.
RICK VISCOMI: I like that.
So what resources
would you recommend
for people that want to learn
more about design systems
and everything else
we talked about?
ADAM ARGYLE: Yeah,
design systems.
OK.
So who-- there's folks--
there's three folks
that I'm a big fan of.
Dan [INAUDIBLE],, Una
Kravets, and Brad Frost.
They're super articulate,
vocal public figures
that are passionately
talking about these topics
and helping you ramp
up, or ramp down.
Dan [INAUDIBLE] recently
has been helping people
not over focus on the atomics
of their design system.
Because you can get super
wrapped up in a button.
And he did this really funny
thing at [INAUDIBLE] Park
recently.
He showed-- this is so good--
he showed a button on the screen
and then showed four companies
that that could potentially
be the button for.
And he's like, whose
button is that?
And everyone's like, oh, I
don't know, maybe that one.
It was a blue button, right?
And so the point
was, we can over
focus on these little things.
And that's not your brand.
And he's essentially pushing you
to real step back a little bit
and determine what's
unique about your business
and make components
and design system out
of those, like your value prop.
Like how are you different?
Because the atomics are atomic.
I thought that was really nice.
Una has a bunch of
really cool things
that she's been
pitching, as well.
She's pitching accessibility
in your components, which
I think is really healthy.
And she's advocating for
maybe you don't need one.
So sometimes, and
this is something
I'm a believer in,
too, which is often
we want to be the
top dog like now.
And so we go do whatever
the top dog's doing.
We're like, all right, I need,
you know, legendary armor,
I need a sword of the
gods of the 10,000 XP.
And so we're like, we show
up and we're like level 1,
but we've got all the gear.
And we're like, this
will make me good, right?
And it does, to a point.
But it can also be
a bunch of baggage.
And like you can't even
make it through the door
of the first dungeon, because
you're too covered in gear.
You've got like magic
shooting out of each fingers.
Pew, pew.
So I like that
advice, too, which
is like, look at the phase
that you're in as a team,
look at the phase that
you're in as a product.
Notice that GCP, which is
a very, very large product,
has an entire team
dedicated to this now.
It's that complex.
There is absolutely value
coming out of a design system.
But you've got to
look at the ROI.
Like how much are you putting in
versus what you're getting out?
And I think that's
what that warning is
is like, you can spend
a whole lot of time
on the atomics of
your design system.
You can spend a whole lot of
time making it really robust.
And then nobody uses it.
So you've got to make
sure you have customers.
And anyway, those
three folks are really
good to go look
up and listen to.
They've got plenty of
material for you to study.
RICK VISCOMI: Well, Adam,
this has been great.
Thanks for coming on the show.
ADAM ARGYLE: Absolutely.
That was really fun.
RICK VISCOMI: You can
check out the links
to everything we talked about
in the description below.
Thanks for watching and
we'll see you next time.
[MUSIC PLAYING]
