How We Document 2022 Report - Zeroheight

1. how we
document
2022
I>
zeroheight

2. welcometo
2022
Designsystemdocumentationhasbeenmaturingatarapidpace
overthelastfiveyears.howwedocumentisanopportunityforusto
stop,reflectandlookatthebiggestchallengesthatfaceusinhowwe
documentandgrowourdesignsystems.Wespoketojustunder500
designsystemsprofessionalsfromacrosstheworldtoestablish
wherewe’reat,wherewe’regoingandwhereweneedtobe.
Design system documentation has been maturing at a rapid pace
over the last five years. how we document is an opportunity for us to
stop, reflect and look at the biggest challenges that face us in how we
document and grow our design systems. We spoke to just under 500
design systems professionals from across the world to establish
where we're at, where we're going and where we need to be.

3. contents
your design system and documentation
your design system team
your organization
who took this survey
contents
who took this survey
your organization
your design system team
your design system and documentation

4. who took
this survey

5. 460
respondents
43%
Europe
31%
United States
26%
everywhere
else
who and where?
While design systems professionals are
still predominantly Europe and US based,
design systems are emerging to be more
global, and less western-centric
oan ere?
respondents
Europe
While design systems professionals are
still predominantly Europe and US based,
design systems are emerging to be more
global, and less western-centric
31%
United States
26%
everywhere
else

6. 83%
of job titles were
Design & UX
10% engineering
3% product management
3% design program management
1% content
The “design” in design systems is still holding
strong (which is not necessarily a good thing).
Unsurprisingly, of respondents were in
Design and UX, with the majority of these being
individual contributors ( )
83%
52% of respondents
primary discipline
• • •
r1 ISCI
i0% engineering
3% product management
3% design program management
1% content
•
1ne
-
-
of job titles were
Design & UX
The "design" in design systems is still holding
strong (which is not necessarily a good thing).
Unsurprisingly, 83% of respondents were in
Design and UX, with the majority of these being
individual contributors (52%of respondents)

7. there are unique job titles when it comes
to design systems, yet only of job titles
explicitly state “design systems” and only
state “DesignOps”
220
8%
1%
job titles
76%
of people have
documentation
as a core part of
their role 1%
DesignOps
2%
product
manager
2%
content
8%
explicitly
design system
product design
21%
33%
mention UX
25%
UX design
8%
engineering
•
0
there are 220 unique job titles when it comes
to design systems, yet only 8%of job titles
explicitly state "design systems" and only i%
state "DesignOps"
of people have
documentation
as a core part of
their role
8%
explicitly
design system
25%
UX design
2%
content
mention UX
1%
DesignOps
21%
product design
2%
product
manager
8%
engineering

8. Most people who completed the survey have been
professionally working for years. Design systems
are not an inexperienced persons’ game, it seems
10+
professional experience
56%
10+ years
23%
14%
6%
1%
5 - 10 years
3 - 5 years
1 - 3 years
0 - 1 years
■
er1ence
iO+ years
Most people who completed the survey have been
professionally working for iO+ years. Design systems
are not an inexperienced persons' game, it seems
5 - iO years 23%
3 - 5 years i4%
i-3years 6%
O- i years 1%

9. design system experience
However, the average time that anyone has been working on
design systems is between years ( of respondents)
1-3 45%
29%
13%
11%
2%
3 -5 years
0 - 1 years
5 - 10 years
10+ years
45%
1 - 3 years
•
es1 ste
•
er1ence
i - 3 years
However, the average time that anyone has been working on
design systems is between i-3 years (45% of respondents)
0 - i years ii%
3 -5 years 29%
5 - iO years i3%
iO+ years 2%

10. your organization

11. how big is your organization?
30%
25%
24%
21%
50 - 200 people
200 - 1000 people
1000+ people
1 - 50 people
There was a relatively even spread across different
organization sizes, with the majority falling into the
typical “startup” or small agency size
• •
I IS
..__..
........
.....__
25% 50 - 200 people
24% 200 - i000 people
21% 1000+ people
our or anization?
i - 50 people
There was a relatively even spread across different
organization sizes, with the majority falling into the
typical "startup" or small agency size

12. in-house or agency
However, most of the respondents work in-
house, as opposed to agency, or as
freelance or contractors
80%
in house
•
1n-
in house
However, most of the respondents work in-
house, as opposed to agency, or as
freelance or contractors

13. your design org
Considering the spread in organization size,
small design orgs are still in the majority
63%
1 - 10 people
13%
5%
4%
21 - 50 people
51 - 100 people
100+ people
15% 11 - 20 people
■
our es1
i5% ii - 20 people
13% 21 - 50 people
5% 51 - 100 people
4% 100+ people
nor
·----....---
i - iO people
Considering the spread in organization size,
small design orgs are still in the majority

14. designers & engineers
3 7 25!
13
organization size 0-50 51-200 1000+
201-1000
there are this many
engineers
for every one designer
When it comes to the ratio of designers to engineers, the ratio grows with organization
size. However, how much it grows is surprising when you get into big organizations,
with organizations reaching a designer to engineer ratio of
1000+ 1:25. Is this the ratio
that works, or is design still reaching maturity in enterprises?
• •
es1 ners 1neers
When it comes to the ratio of designers to engineers, the ratio grows with organization
size. However, how much it grows is surprising when you get into big organizations,
with i000+ organizations reaching a designer to engineer ratio of i:25. Is this the ratio
that works, or is design still reaching maturity in enterprisesP
or,ganization size
for every one designer
there are this many
engineer,s
0-50
3
5i-200
7
20i-i000 i000+
13 25!

15. your design
system team

16. Surprisingly, only of organizations have a
dedicated design systems team. It seems that
we still haven’t reached the point where a
dedicated team is commonplace
39%
dedicated design system teams are
still in the minority
39%
have a design
system team
e
sti
esi n s ste tea sare
inorit
have a design
system team
)
Surprisingly, only 39% of organizations have a
dedicated design systems team. It seems that
we still haven't reached the point where a
dedicated team is commonplace

17. design system teams are more
likely in bigger organizations
Unsurprisingly, the likelihood of having a dedicated
design system team changes with the org size, with
the likelihood of an enterprise organization ( )
being much higher than smaller organizations
500+
39%
26%
scale-up
startup
58%
more likely in
enterprise
n s ste tea s are ore
in i er or anizations
-
-
more likely in
enterprise
Unsurprisingly, the likelihood of having a dedicated
design system team changes with the org size, with
the likelihood of an enterprise organization (500+)
being much higher than smaller organizations
scale-up 39%
startup 26%

18. 50%
17%
>10
of all design system teams sit within 4-9 people, with
only of teams numbering more than 10 people.
Interestingly, the amount of design systems teams with
seems to be very low, which suggests that
the value they bring keeps scaling, even when the team
size doesn’t
people
design system team size
50%
4 - 9 people
33%
17%
1 - 3 people
10+ people
■ ■
es1 tea size
4- 9 people
50%of all design system teams sit within 4-9 people, with
only i 7%of teams numbering more than iO people.
Interestingly, the amount of design systems teams with
>iO people seems to be very low, which suggests that
the value they bring keeps scaling, even when the team
size doesn't
i - 3 people 33%
iO+ people 17%

19. Similarly,thesizeofthedesignsystemteamdoesn’tseemtochangemuchasthe
organizationsizechanges.Although,thiscouldjustbeacaseofdesignsystem
teamsstillbeingontheirwaytomaturity
designsystemteammakeup
doesn’tchangemuch
organizationsize
averagenumber
ofpeopleindesign
systemsteam
0-50 50-200 200+
■
es1 n s ste tea
oesn't c an
Similarly, the size of the design system team doesn't seem to change much as the
organization size changes. Although, this could just be a case of design system
teams still being on their way to maturity
organization size
average number
of people in design
systems team
0-50 50-200 200+

20. design system team makeup
changes over time (but not much)
designers engineers PM content
2.5
2.5
3
3
4
3 10
3.5
0.5
1
1
1 1
0.5
0.5
0-1 years
2 - 4 years
5- 7 years
7 years
When you look at the breakdown of roles in a design
system team, it stays relatively consistent with regards
to design, product and content. The main difference
with mature teams is the amount of engineering
resource required to keep the wheels turning
3
3.5
2.5
2.5
n s ste tea
es over ti e
7 years
10 1 1
5- 7 years
4 1 0.5
2 - 4 years
3 1 0.5
0-i years
3 0.5
When you look at the breakdown of roles in a design
system team, it stays relatively consistent with regards
to design, product and content. The main difference
with mature teams is the amount of engineering
resource required to keep the wheels turning
designers engineers PM content

21. your design
system and
documentation

22. Design systems are still in their infancy, with of
systems being 3 years or younger, and only a small
percentage beyond the 5 year mark
74%
most design systems are
relatively young
14%
25%
5%
4 years old
3 years old
1 year old
44%
2 years old
12% 5+ years old
ost esi
re ative
5% i year old
25% 3 years old
i4% 4 years old
i2% 5+ years old
sare
2 years old
Design systems are still in their infancy, with 74%of
systems being 3 years or younger, and only a small
percentage beyond the 5 year mark

23. However, a promising sign is that the difference between
starting your design system and documenting it seems to
be relatively low, with of systems starting to
document within 1 year of starting
90%
documentation is no longer trailing
behind the system
53%
2 years old
21%
13%
8%
5%
3 years old
1 year old
4 years old
5 years old
ocu entation is no on er trai in
e t es ste
13% 1 year old
2 years old
21% 3 years old
8% 4 years old
5% 5 years old
However, a promising sign is that the difference between
starting your design system and documenting it seems to
be relatively low, with 90% of systems starting to
document within i year of starting

24. third-party documentation tools
are leading the charge
In terms of documentation, the majority
of respondents spread their
documentation across multiple tools, with
the majority of organizations ( ) opting
for third-party design system managers
(DSMs) such as zeroheight or Invision
DSM. Code-first tools are common as well
( ), with Storybook being the most
popular by far
66%
63%
62%
code and
code-first tools
55% the design tool itself
48% notetaking tools
11% self-built solutions
66%
third-party
DSMs
ii% self-built solutions
entation too s
62% code and
code-first tools
55% the design tool itself
48% notetaking tools
third-party
DSMs
In terms of documentation, the majority
of respondents spread their
documentation across multiple tools, with
the majority of organizations (66%) opting
for third-party design system managers
(DSMs) such as zeroheight or lnvision
DSM. Code-first tools are common as well
(63%), with Storybook being the most
popular by far

25. the most popular
documentation tools
zeroheight
58%
In-code
10%
The design tool itself
55%
Storybook
50%
Confluence
22%
Notion
8%
Google Docs
7%
Self-built solution
12%
Invision DSM
3%
t e ost o u ar
ocu entation too s
-
zeroheight
58%
Confluence
22%
N Notion
8%
Pfl The design tool itself
55%
~ Self-built solution
12%
Google Docs
7%
Storybook
50%
( ) In-code
10%
•
m lnvision DSM
3%

26. Organizationsuseacombinationoftoolstogetthe
jobdone,especiallywhenitcomestodocumenting
forbothdesignanddev.Infact, offolksstill
haveseparatedocumentationforthedevand
designsideofthesystem
Whenitcomestothemostpopularcombinationof
tools,it’sstillcommontoseeahomefordesign
documentation,ahomeforcodedocumentation,
andsomewherethatsitsbetween
61%
toolcombinationbingo
6%
4%
3%
3%
9%
too co ination
i>t•0
..----...........__
i>0
Organizations use a combination of tools to get the
job done, especially when it comes to documenting
for both design and dev. In fact, 6i% of folks still
have separate documentation for the dev and
design side of the system
When it comes to the most popular combination of
tools, it's still common to see a home for design
documentation, a home for code documentation,
and somewhere that sits between

27. A pressing problem seems to be documentation coverage,
with documenting of their overall system
59% < 50%
documentation is not covering
enough of our system
27%
18%
17%
6%
3%
25 - 50%
51 - 75%
76 - 99%
100%
0%
29%
1 - 25% of the design
system is documented
ocu
enou
3% 0%
entation is not coverin
o ours ste
27% 25- 50%
i - 25% of the design
system is documented
18% 51-75%
17% 76- 99%
6% 100%
A pressing problem seems to be documentation coverage,
with 59% documenting < 50% of their overall system

28. UX
research
13%
motion
guidelines
16%
sound
guidelines
1%
complex
components
52%
grids
59%
spacing
61%
layout
53%
design
tokens
42%
forms
75%
buttons
87%
color
92%
typography
87%
principles
61%
release notes
or change log
31%
code for
components
41%
brand
guidelines
42%
tone
& voice
32%
UX Copy
guidelines
30%
illustration
guidelines
20%
A11y
guidelines
27%
example
page
29%
code usage
guidelines
23%
contribution
model
18%
what does your documentation
include?
oes
e?
our
color
92%
spacing
61%
brand
guidelines
42%
example
page
29%
motion
guidelines
16%
buttons
87%
grids
59%
code for
components
41%
Aiiy
guidelines
27%
ux
research
13%
ocu
typography
87%
layout
53%
tone
& voice
32%
code usage
guidelines
23%
sound
guidelines
1%
entation
forms
75%
complex
components
52%
release notes
or change log
31%
illustration
guidelines
20%
principles
61%
design
tokens
42%
UX Copy
guidelines
30%
contribution
model
18%

29. most of our documentation
is monolingual
Localizing your documentation is still a relatively niche
thing amongst respondents, with only localizing
their documentation into other languages
Surprisingly, the size of your organization has little
bearing on whether you’re likely to localize, with of
enterprises localizing their documentation. Similarly,
maturity doesn’t seem to have an effect, with of
self-identified ‘mature’ design systems being localized
30%
27%
30%
30%
do localize
osto
■
IS
our ocu entation
ua
do localize
Localizing your documentation is still a relatively niche
thing amongst respondents, with only 30% localizing
their documentation into other languages
Surprisingly, the size of your organization has little
bearing on whether you're likely to localize, with 27%of
enterprises localizing their documentation. Similarly,
maturity doesn't seem to have an effect, with 30% of
self-identified 'mature' design systems being localized

30. 45%
version control is not as
common as it should be
use version control
Surprisingly, only of respondents use any kind
of version control on their documentation. Tool
usage and organization size have little impact on
this number
However, the self-identified ‘mature’ design
systems have a much higher chance of version
controlling their documentation ( )
45%
85%
version contro is not as
co on as its
use version control
Surprisingly, only 45% of respondents use any kind
of version control on their documentation. Tool
usage and organization size have little impact on
this number
However, the self-identified 'mature' design
systems have a much higher chance of version
controlling their documentation (85%)

31. how people contribute to your
design system
Only of respondents believe they have an
effective contribution system, with having
one, but not feeling it is effective. Either their
contribution system is not understood ( ) or
contributions are low ( )
In terms of how many people contribute to the
design system and the docs, then numbers are
relatively similar, with and of design
systems and documentation respectively being
contributed on by 1-10 people. This is in line with
average design system team size
7%
53%
25%
28%
95% 89%
60%
have a
contribution model
ow
■
es1
eo e contri
ns ste
have a
contribution model
uteto our
Only 7% of respondents believe they have an
effective contribution system, with 53% having
one, but not feeling it is effective. Either their
contribution system is not understood (25%)or
contributions are low (28%)
In terms of how many people contribute to the
design system and the docs, then numbers are
relatively similar, with 95% and 89% of design
systems and documentation respectively being
contributed on by i-iO people. This is in line with
average design system team size

32. Whenitcomestowhodocuments,it’sstilldesigners
holdingupthefort.Infact,among ofrespondents,
itisonlydesignerscontributingtothedesignsystem
documentation. haveboththeengineersand
designers,anddesigners,engineersandPMs
contributetogetherin oftheorganisations
47%
25%
5%
whodocumentsyoursystem?
engineers
25%
productmanagers
8%
contentstrategists
5%
documentationspecialists
3%
marketing
3%
designers
56%
ocu ents
25% engineers
8% product managers
5% content strategists
3% documentation specialists
3% marketing
ours ste 0
■
designers
When it comes to who documents, it's still designers
holding up the fort. In fact, among 47% of respondents,
it is only designers contributing to the design system
documentation. 25% have both the engineers and
designers, and designers, engineers and PMs
contribute together in 5%of the organisations

33. When somebody is contributing to your docs,
only of respondents provide content
guidelines or templates to work from. However,
this goes up to on “mature” design systems
36%
54%
not many have content guidelines
for their documentation
36%
do have content
guidelines
not
ort
•
e1r
ave content
ocu entation
do have content
guidelines
When somebody is contributing to your docs,
only 36% of respondents provide content
guidelines or templates to work from. However,
this goes up to 54%on "mature" design systems
•
UI

34. 27%
17%
56%
of respondents don’t have any governance
at all on their documentation, with only
having a formal process. Most respondents
( ) opt for an informal review process
governance is almost commonplace
have a review
process
73%
■
overnance 1s a ostco ace
have a review
process
27% of respondents don't have any governance
at all on their documentation, with only i 7%
having a formal process. Most respondents
(56%)opt for an informal review process

35. measuring the success of your
documentation
Surprisingly, only of respondents track metrics on
their documentation, with having KPIs that are directly
associated with the success of their documentation. This
feels like it should be one of the most pressing concerns
with design systems teams in organizations
9%
12%
91%
don’t track metrics
on their docs
88%
don’t have KPIs
for their docs
easurin t e success o
ocu entation
don't track metrics
on their docs
Surprisingly, only 9%of respondents track metrics on
their documentation, with 12% having KPls that are directly
associated with the success of their documentation. This
feels like it should be one of the most pressing concerns
with design systems teams in organizations
our
•
•
•
•
don't have KPls
for their docs

36. Out of those who have KPIs, most center
around coverage and adoption, with team
productivity ranking highly as well. Reduced
support requests were the lowest ranked KPI
adoption is the key concern
documentation coverage 54%
team productivity 54%
team happiness 37%
viewer growth 20%
NPS or similar 12%
71%
design system
adoption
tion is t concern
design system
adoption documentation coverage 54%
Out of those who have KPls, most center
around coverage and adoption, with team
productivity ranking highly as well. Reduced
support requests were the lowest ranked KPI
team productivity 54%
team happiness 37%
viewer growth 20%
NPS or similar i2%

37. 90%
typography
70%
spacing
58%
shadows
48%
radius
47%
borders
17%
animation
18%
grouped
styles
color
96%
59%
of respondents
currently use design
tokens in some way
design tokens are
on their way
While design tokens are still relatively new,
over half the respondents use design
tokens at some stage in their pipeline.
Unsurprisingly, most of these were
standard tokens like color and typography,
with very few organizations tokenizing
animation or creating composite tokens
•
es1
ont
•
e1rwa
While design tokens are still relatively new,
over half the respondents use design
tokens at some stage in their pipeline.
Unsurprisingly, most of these were
standard tokens like color and typography,
with very few organizations tokenizing
animation or creating composite tokens
of respondents
currently use design
tokens in some way
47%
borders
spacing
shadows
color
17%
animation
18%
gr,ouped
styles
typography
4~
radius

38. 71%
design tools
55%
code
1%
a custom solution
18%
a token management
platform
Token definition is still primarily done in
design tools and code. However, specific
token management platforms (like zeroheight
or Theo) are clearly growing in popularity.
With design tools starting to build this into
their products, will this continue?
but where are tokens defined?
utw
design tools
a token management
platform
code
1%
a custom solution
0
■
Token definition is still primarily done in
design tools and code. However, specific
token management platforms (like zeroheight
or Theo) are clearly growing in popularity.
With design tools starting to build this into
their products, will this continueP

39. design tokens and continuous
integration
How the design tokens work from design to code is still relatively
fragmented, with only syncing design tokens both in and out of
design tools. Similarly, less than of respondents who have
tokens have continuous integration with their tokens, with only
having CI that runs both ways from design to code and back again
12%
50%
8%
yes, from design to code
yes, and it syncs both ways
yes, from code to design
34%
8%
5%
53%
design system
adoption
•
es1 nto ensan
ration
continuous
inte
design system
adoption yes, from design to code 34%
How the design tokens work from design to code is still relatively
fragmented, with only i2% syncing design tokens both in and out of
design tools. Similarly, less than 50% of respondents who have
tokens have continuous integration with their tokens, with only 8%
having Cl that runs both ways from design to code and back again
yes, and it syncs both ways 8%
yes, from code to design 5%

40. Measuring the maturity of your documentation isn’t
easy. However, of respondents have mature design
systems, integrated with engineering, with some form
of governance and working contribution model
19%
maturity is a pressing concern
with documentation
55%
feel their documentation is
functioning well enough
aturit
• •
1s a ress1n concern
wit ocu entation
feel their documentation is
functioning well enough
Measuring the maturity of your documentation isn't
easy. However, i9% of respondents have mature design
systems, integrated with engineering, with some form
of governance and working contribution model

41. what are the hallmarks of mature
design system documentation?
85%
have version control,
compared to as
the average
45%
69%
have dedicated
design system teams,
compared to as
the average
39%
Unsurprisingly, larger
companies are more likely to
have a mature design system
1000+
200 - 1000
0 - 200
26%
16%
16%
92%
have a contribution
model, compared to
as the average
60%
85%
use design tokens,
compared to
as the average
59%
w
■
es1
i6% 200-i000
i6% 0-200
Unsurprisingly, larger
companies are more likely to
have a mature design system
1000+
so ature
entation?
•
•
have version control,
compared to 45% as
the average
•
•
use design tokens,
compared to 59%
as the average
have a contribution
model, compared to
60% as the average
have dedicated
design system teams,
compared to 39% as
the average

42. Happiness is an interesting one. We expected a bell curve that sits
somewhere around “meh”, with people not feeling particularly
happy or unhappy with their documentation. However, there
were decidedly more people who were unhappy ( ) with their
documentation than happy ( ). So, what are the hallmarks of
someone who’s happy with their documentation?
40%
31%
design systems teams
need a hug
29%
28%
28%
3%
12%
■
es1 stea
nee
Happiness is an interesting one. We expected a bell curve that sits
somewhere around "meh", with people not feeling particularly
happy or unhappy with their documentation. However, there
were decidedly more people who were unhappy (40%) with their
documentation than happy (31%). So, what are the hallmarks of
someone who's happy with their documentationP
3%
28%
28%
i2%

43. happiness with the design system
vs job role
I’m not sure whether it’s a sad fact or quite
funny that it seems the further removed
you are from having to actively manage a
design system on an ongoing basis (ie being
an in-house IC), the more likely you are to be
happy with the system you’re working on
100%
founder or owner
57%
44%
41%
39% individual contributor
executive
manager
freelancer or consultant
iness wit
■
es1 ste
founder or owner
57% freelancer or consultant
44% manager
4i% executive
39% individual contributor
I'm not sure whether it's a sad fact or quite
funny that it seems the further removed
you are from having to actively manage a
design system on an ongoing basis (ie being
an in-house IC),the more likely you are to be
happy with the system you're working on

44. Similarly, we saw a slightly happier bunch of design system professionals
when we go to agencies or in-house. Could it be something to do with not
having to maintain a system over time? Interestingly, we saw very little
difference in happiness levels when it came to design system age, the
different job roles or the different organization sizes.
Now to move on to the features and processes of the system itself...
is happiness related to being
in-house?
55%
agency
50%
self-employed
41%
in-house
•
IS
•
1n-
a iness re ate
ouse?
agency
to
•
e1n
self-employed 50%
in-house 4i%
Similarly, we saw a slightly happier bunch of design system professionals
when we go to agencies or in-house. Could it be something to do with not
having to maintain a system over timeP Interestingly, we saw very little
difference in happiness levels when it came to design system age, the
differentjob roles or the different organization sizes.
Now to move on to the features and processes of the system itself ...

45. Firstoff,theredoesseemtobeacorrelationbetweenhavingadedicated
teamandhappinesswithyourdocumentation
happinessinyourdesign
systemteam
36%
arehappywhodon’thave
adesignsystemteam
56%
arehappywhohave
adesignsystemteam
■ ■ ■
a 1ness 1n our es1
s ste tea
First off, there does seem to be a correlation between having a dedicated
team and happiness with your documentation
are happy who have
a design system team
are happy who don't have
a design system team

46. happiness in contribution
Similarly, we see a big correlation between having a functional contribution
model and happiness with your documentation. Interestingly, when you
break this down, it’s more about having your contribution model
understood and less about having active contributions
57%
are happy who have
a contribution model
22%
are happy who don’t have
a contribution model
iness in contri ution
Similarly, we see a big correlation between having a functional contribution
model and happiness with your documentation. Interestingly, when you
break this down, it's more about having your contribution model
understood and less about having active contributions
are happy who have
a contribution model
are happy who don't have
a contribution model

47. happiness in governance
Similarly, not having a governance model for your documentation
correlates with unhappiness with the documentation overall
58%
are happy who have a
formal review process
48%
are happy who have an
informal process
25%
are happy who don’t
review changes
■ ■
1ness 1n overnance
Similarly, not having a governance model for your documentation
correlates with unhappiness with the documentation overall
are happy who have a
formal review process
are happy who have an
informal process
are happy who don't
review changes

48. how much is covered in a happy
design system?
Finally, it isn’t surprising, but the more of the system
that is documented, the happier the team seems to
be, with the happiest teams covering an average of
of their design systems, compared to an average
of for unhappy teams
65%
25%
65%
average documentation
coverage 25%
ow
■
es1
■
uc 1s covere
n s ste ?
average documentation
coverage
Finally, it isn't surprising, but the more of the system
that is documented, the happier the team seems to
be, with the happiest teams covering an average of
65%of their design systems, compared to an average
of 25%for unhappy teams
■
1n a
25%

49. That’s a wrap for how we document 2022. We’ll be back at the end of
the year to see how we’ve improved over the next twelve months.
Will we start measuring the success of our documentation more?
Will tokens continue to be the hot talking point? Will we finally break
out of our monolingual documentation?
until next
time
That's a wrap for how we document 2022. We'll be back at the end of
the year to see how we've improved over the next twelve months.
Will we start measuring the success of our documentation moreP
Will tokens continue to be the hot talking pointP Will we finally break
out of our monolingual documentation?

50. This report was brought to you by zeroheight, the design system
documentation platform that makes it easier to collaborate between
design, engineering and product.
The how we document survey was conducted from Sep to Oct 2021
across social media, industry Slack channels and in emails to design
system professionals.
try out zeroheight today
This report was brought to you by zeroheight, the design system
documentation platform that makes it easier to collaborate between
design, engineering and product.
The how we document survey was conducted from Sep to Oct 202i
across social media, industry Slack channels and in emails to design
system professionals.
try out zeroheight today