droidcon San Francisco 2019
| Tweet |
|
droidcon News
Implementing a Design System
By
Nathanael Silverman
droidcon San Francisco 2019
Design systems can help teams move fast and create coherent products. On paper they are productivity nirvana. In practice they are hard to get right. The efficiency of reusing resources and setting thoughtful constraints often clashes with creative requirements.
In this talk we’ll explore how Airbnb’s Design Language System (DLS) is implemented on Android. We'll take a look at component libraries, scaling, testing, and internal tools that Airbnb's Android engineers use every day.
Transcript
English
00:00
[Music]
00:12
welcome everyone thank you for coming
00:15
I'm really pleased to be here today to
00:18
talk about Design Systems and so here's
00:25
our agenda for the next half hour so I
00:31
will start with a quick intro about
00:34
design systems in general what they are
00:37
with what purpose they serve then we'll
00:42
take a closer look at air B&B design
00:45
system and some of its more distinctive
00:48
features then we'll talk about Sun of
00:52
challenges of using a design system and
00:56
some possible solutions and finally
01:01
we'll end with a brief mention of server
01:03
driven uija
01:04
but first just a little bit about me my
01:10
name is Nathaniel I've been working on
01:13
Android for about seven years now and I
01:18
spent the last three of those at Airbnb
01:21
and I've been on the design system team
01:23
for most of that time and our main
01:26
responsibility on that team is to make
01:29
it easy for other engineers at the
01:32
company to develop quality features
01:34
quickly so that's basically what I'm
01:38
here to talk about today Design Systems
01:45
so raise your hand if you think that
01:50
your company has a design system so
01:53
raise your hand yeah okay looks like
01:56
maybe close to half and I raise your
02:01
hand if you think your company does not
02:02
have a design system no design system
02:06
okay it looks like basically the other
02:08
half and if there's anybody anybody just
02:11
doesn't know or isn't sure
02:13
yeah a few great so what is a design
02:20
system anyway right and first I'd like
02:25
to know what you think so to make it
02:28
simpler I'll just ask for things that
02:30
you would put in a design system
02:33
I just wanted to words shout it out
02:38
standard colors and sizes yes absolutely
02:42
anyone else widgets yeah we'll take one
02:48
last one what was that common UI
02:54
components and security sure great so
02:60
here's just my quick definition of a
03:03
design system a set of design principles
03:07
applied in a systematic manner across
03:10
the entire product so no surprise there
03:14
in fact this definition I think kind of
03:17
boring but what I'm trying to convey
03:19
here is that design system is a very
03:22
broad term and so a design system could
03:27
actually be something quite small for
03:31
example if an application has a primary
03:33
color that's the beginning of a design
03:36
system and so in reality most products
03:41
have a design system and your company
03:44
likely has one even if you don't refer
03:47
to it that way but not all companies are
03:51
as intentional about developing and
03:55
leveraging their design system some
04:01
organizations they have systems that are
04:04
large and complex you can read about
04:07
them one that most of us are probably
04:10
familiar with here would be Google's
04:12
material design system and as you may
04:16
have guessed Airbnb also has its own
04:19
large and rather complex design system
04:25
so in fact Airbnb from what I understand
04:28
has a rather strong reputation in the
04:31
design community and so this design
04:34
system that we've come up with is
04:36
regularly referenced outside of the
04:38
company and before I dive deeper into it
04:43
and some of the tools that power it's
04:46
I'd like to talk just a little bit about
04:48
why so why would an organization invest
04:55
in developing their design system and I
04:59
can think of three reasons so having a
05:05
well-developed design system means that
05:08
your designers never truly start from a
05:12
blank canvas and often parts of the
05:15
design system can become part of the
05:18
engineering infrastructure and so then
05:21
your engineers are never starting from
05:23
scratch either so in short it's about
05:27
reusing as much as possible and that's
05:30
how we get speed because design systems
05:36
are meant to be reused we can reinvest
05:40
some of the time that we gain into
05:42
thoughtful design principles that stand
05:46
the test of time
05:47
and don't live don't leave sorry
05:50
minorities of users behind you know I'm
05:52
thinking of things like accessibility
05:54
and so that's quality and finally by
06:00
applying these design principles
06:02
systematically we naturally achieve more
06:05
consistency across the entire product
06:08
and I like to think of this as a sort of
06:12
macro quality right with consistency
06:16
were improving the usability of our app
06:18
because we repeat the same patterns over
06:20
and over so now do any of these things
06:23
sound like they might be useful to you
06:26
or to your organization right speed
06:30
quality consistency you know anyone
06:34
so this brings us to air be in these
06:38
design language system which we refer to
06:41
as DLS for shorts and so I'm an engineer
06:45
not a designer so I'm not gonna go into
06:48
too much detail here but I will provide
06:51
just a little bit of context before I
06:53
talk about the engineering driven tools
06:55
that help make the system successful and
07:00
I'm also going to limit my scope and
07:02
focus on the mobile side of things your
07:05
think that's what's most relevant to us
07:08
all but there's sort of a broader design
07:10
system at Airbnb that also includes web
07:13
and I'd also like to note that this is a
07:16
design system that's meant to power
07:18
hundreds and if not thousands of screens
07:21
and of course every single app is
07:24
different so the things I talk about
07:26
here may be more or less useful to you
07:28
and the apps you work on of course all
07:33
right so like many design systems
07:35
DLS includes Calder guidelines so
07:38
somebody was mentioning that earlier and
07:40
so again I won't go into too much detail
07:42
here except to say that a lot of
07:44
attention in the choice of collar is
07:46
paid to things like readability and
07:49
accessibility another common set of
07:53
guidelines in design systems
07:55
that's large is around typography and so
07:59
here in this system we have a set of
08:01
text sizes and line spacing or grouped
08:04
by categories and so forth but of course
08:07
there's many ways to organize something
08:09
like this a little bit more unusual
08:15
Airbnb fairly recently came out with its
08:18
own typeface named cereal and so it was
08:22
designed it's meant to convey our brand
08:24
to be particularly legible and to work
08:27
across all sorts of mediums from phones
08:30
to billboards now one of the most
08:36
valuable aspects of the system in my
08:39
opinion is Rho components and it's a
08:43
level of abstraction which is unusually
08:46
high for the design system
08:48
and let me illustrate this with an
08:51
example screen so here are parts of the
08:57
Airbnb listing detail screen and some
09:01
design systems at their highest level
09:03
would provide guidelines around all of
09:05
these elements so the system it would
09:10
help you design all these elements
09:11
individually here highlighted in orange
09:14
and then perhaps it would have rules
09:16
about how you place them relative to one
09:19
another
09:19
and so based on those rules and those
09:22
elements you would assemble a 2d layout
09:25
like this and you'll repeat with the
09:28
next screen that you need to create of
09:30
course Airbnb system also has to work
09:33
out all these details but it goes just a
09:37
little bit beyond by defining rows and
09:40
so constructing a screen using DLS looks
09:44
more like this see so we're stacking
09:49
rows and a single vertical dimension and
09:53
many of these rows already exists
09:56
they're reused across the application
09:58
across many other screens and so clearly
10:01
when we're looking at it this way right
10:03
this already looks much simpler and it
10:07
can seem like a subtle shift and the way
10:11
that we think about building screens but
10:13
I think as you'll see in the rest of
10:15
this talk this concept of a row
10:17
components is actually the foundation of
10:20
the LS and a lot of the engineering
10:22
tooling that we've developed to support
10:24
it so looking at a little bit of Android
10:30
code here on Android each of these row
10:33
components corresponds to a custom view
10:37
the layout for these views is generally
10:40
defined in XML and this component class
10:43
would just bind data to the view or some
10:46
of its sub views most of our screens are
10:50
powered by a recycler view and we've
10:54
created a framework named epoxy that
10:57
makes it extremely easy to use our
10:59
components
11:00
recyclerview and it uses an annotation
11:06
processor so all we need to do is
11:09
annotate our component class and the
11:12
relevant setters as you can see here and
11:14
this will generate a model and some
11:17
common extensions that we can then use
11:20
and so this is what creating a new
11:25
screen using our components looks like
11:27
at Airbnb all the recyclerview setup is
11:32
hidden under the hood that includes
11:35
different components and the properties
11:37
when the data or the state changes the
11:40
system figures out exactly what changed
11:43
and what needs to be refreshed and so I
11:45
didn't write this framework so I can say
11:47
that it's truly excellent and luckily
11:51
it's open-source and so I highly
11:53
recommend that you check it out if you
11:55
haven't already
11:57
it's called epoxy you can find it on
11:60
github and has many more features and
12:02
use cases than the ones I've highlighted
12:09
so some of my previous slides may have
12:12
made all of this look very neat but
12:15
there's actually quite a lot of
12:18
messiness that can happen when you have
12:20
dozens of designers and engineers
12:22
working on the same product hundreds
12:25
thousands of screens and so forth and so
12:28
for example you know you're working in a
12:29
system with these RO components and if a
12:34
component is used by a bunch of
12:36
different teams across a bunch of
12:38
different features once it okay to
12:41
change it to update it because that can
12:43
have a huge ripple effect across your
12:45
application and vice versa if you know
12:49
that a component that's here and
12:51
available might change what it looks
12:55
like from one day to the other then what
12:57
you use it for your features you know
12:59
maybe not
13:01
and so to address these issues we came
13:05
up with two distinct categories of
13:08
components so here on the left side we
13:11
have core components
13:13
and those are meant for very generic use
13:16
cases there are meant to be widely
13:18
reused across app and they're rarely
13:22
modified only by or with approval of the
13:25
DLS team which maintains the system and
13:29
on the other side of things we have team
13:32
components and so those range from
13:35
somewhat generic to very specific they
13:38
might be used in a single screen for
13:40
example and then it's the team that owns
13:44
each of those components that decides
13:47
when they should be reused when they
13:49
should be modified and can have rules
13:51
and documentation about that and so this
13:55
sort of simple splits enables product
13:59
teams to create components that they can
14:01
heavily iterate upon without impacting
14:04
anyone else no other team no other
14:06
features and it also enables product
14:09
teams to contribute very reusable
14:11
components they can simply document them
14:15
as such or they can contribute them to
14:18
core and the core components those are
14:22
always safe to use and meet very high
14:24
quality standards since they're reused
14:26
so often so here's an example of how the
14:33
screen that we were looking at before
14:34
might be split most components here in
14:39
green are very generic we have a
14:41
carousel of images a title text a map
14:47
and a few of them in yellow or a little
14:49
more specific we have details about a
14:52
host we have sleeping arrangements
14:55
amenities and so those are more likely
14:58
to be owned and maintained by a specific
15:00
product team that owns this this screen
15:03
in this feature and we represent these
15:10
categories of components in code using
15:13
annotations so it's very clear this is
15:17
how Android does it other platforms have
15:19
a comparable system and this serves both
15:23
as documentation people can easily see
15:26
what's--what when they're looking at the
15:28
components but it also supports a lot of
15:31
tool laying that I'm going to talk about
15:33
in just a few minutes and even with a
15:39
design system like Airbnb is the
15:42
designers they're still very regularly
15:44
feel the need to customize existing
15:46
components you might be familiar with
15:49
the practice and so often enough all
15:53
they need is just push a few pixels or
15:55
change your color make a font a little
15:58
bit bigger something equally simple and
16:03
so creating new components in all those
16:05
instances would not scale well so we
16:10
make it possible to restyle components
16:12
with some constraints so here this
16:15
change you're seeing perfectly fine
16:16
we're just changing a background color
16:19
of a button but if the layout is
16:23
different like in this example then our
16:26
rule states it must be a separate
16:28
component and so this helps keep
16:31
components simple and it also has
16:34
certain performance benefits as you may
16:37
know though working with Android styles
16:39
kind of hard and so we created a
16:42
framework named Paris to make it easier
16:45
and so first it makes it easy to add
16:49
custom style attributes to components
16:53
like epoxy it uses an annotation process
16:56
or so here in this example we're adding
16:60
support for a title color basically just
17:04
by annotating a setter so then we can
17:12
declare styles for this component which
17:13
include a custom title color Paris also
17:19
makes it possible to explicitly link
17:21
styles to a specific component view so
17:26
here I can create a link to a style
17:28
define an XML or if I prefer I can also
17:31
declare Styles programmatically within
17:35
the component class
17:37
which looks like this so one of the
17:44
advantages of doing this is that I get
17:46
access to advanced functionality so for
17:49
example I can inherit from multiple
17:51
styles I can combine them and pretty
17:54
much anyone I want I'm sorry I'm adding
17:57
a style and then I'm changing a
17:59
particular attribute of it and by the
18:02
way many of the default Android style
18:04
attributes are already available as for
18:07
this framework so they don't need to be
18:09
added here I can easily change the
18:11
vertical padding or other things and
18:13
have multiple sort of utility methods so
18:15
I can provide a resource I can provide a
18:18
density pixel value or a straight-up
18:21
pixel value and epoxy the recyclerview
18:26
framework dead we were just looking at
18:28
earlier integrates really well with
18:31
Parris and so I can very easily apply my
18:34
style as I'm building my screen with the
18:36
stack of components just one function
18:39
call as you can see here Paris is also
18:44
open source I can't praise it quite as
18:47
much as epoxy because I actually wrote
18:49
that one but I humbly invite you to
18:51
check it out so to quickly recap so
18:55
we've seen that Airbnb build screens
18:57
using a vertical stack of components on
18:59
mobile we've seen how writing them using
19:03
them customizing them pretty easy now
19:06
what if I told you that as of today we
19:10
have about 700 distinct components not
19:15
even counting different styles so you
19:19
may wonder how we're keeping track of
19:20
what's available and this is where
19:24
discoverability comes in and there are
19:28
many ways to tackle this problem we have
19:32
tried to make it as easy and automatic
19:34
as possible so that engineers and
19:36
designers can focus on building features
19:38
they don't really have to worry about
19:40
their components becoming discoverable
19:44
or documenting them and so forth so for
19:49
starters
19:50
on each platform I know Android iOS web
19:54
has its own internal component browser
19:57
app on Android it looks like this and
20:00
you can see components are split by a
20:02
category and my team actually you can't
20:06
see it on the screenshot but they are so
20:09
here we're seeing a subset of core
20:12
components they can be searched for by
20:14
name and yeah this is a screenshot of
20:19
core components as I was saying and so
20:21
components themselves also often include
20:25
multiple example usages right they can
20:28
be set up in different ways with
20:30
different styles and so forth and so
20:32
here on this screen we're looking at a
20:35
single component and the list of
20:37
examples is actually much longer than
20:39
I'm able to show on a single sign and so
20:42
we'll get back to this particular screen
20:44
in a bit for now you may be wondering
20:48
where all of these different examples
20:49
come from right part of the answer here
20:52
is in gene engineers to find them in
20:55
code so I enter it it looks something
20:59
like this here I would be in a
21:02
particular component class and so I have
21:05
one function for example again we use
21:08
annotations here and so the combination
21:11
of the component category annotation
21:13
core team that we were looking at before
21:15
and an example annotation that we use
21:19
here those are used to automatically
21:21
generate the component browser app so
21:24
our engineers just get all that for free
21:31
we also have overlays that can be turned
21:35
on by employees inside the amp and they
21:39
show the name of the component as well
21:40
as their type they can be used by
21:44
engineers but also designers or product
21:46
managers so this also works
21:50
automatically engineers don't need to do
21:52
any additional work so to achieve this
21:56
on Android specifically we used a custom
21:60
layout inflator and the view overlay API
22:06
finally
droidcon News
Tech Showcases, Developer Resources & Partners
EmployerBrandingHeader
https://jobs.droidcon.com/
jobs.droidcon.com
Latest Android Jobs
http://www.kotlinweekly.net/
Kotlin Weekly
Your weekly dose of Kotlin
https://proandroiddev.com/
ProAndroidDev
Android Tech Blogs, Case Studies and Step-by-Step Coding
/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
Zalando
Meet one of Berlin's top employers
/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
Academy for App Success
Google Play resources tailored for the global droidcon community |
Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.