Analyzing zeroheight's “How We Document“ 2023 Report

Hey friends, you know that I am all about the new design system and design tool things and I just found out that Zero Height just released their 2023 version of their How We Document report. They've been releasing that annually. I figured we could just open it up together, see what's inside and see what the state of documentation holds for the next year. Let's take a look. Well first up here we have their fancy schmancy microsite. This is the Howie Document second Edition brought to you by Zero Height. This is not a sponsored video or anything like that. This is me just being nosy and curious to see what's going on in the design system space. So cool little micro site here. We can download the full report which I had that downloaded. But first let's just see what's on the site here first. Last fall we launched the second edition of a Howie Document survey. Cool. I love looked through that last year. We're excited to share with you the how we document 23 report. A few of the report highlights 518 total respondents. That's a pretty good sample size. So curious to see what's in there. What else we got Design System Experience Most of our respondents have been working on design systems between one and three years. 44%. All right. Lots less people have been working for a longer amount of time. So an interesting stat here. A lot of people are sort of. I consider this maybe a junior or starting to get into a mid level range in careers. So a lot of people that responded are a bit earlier in their careers or at least design system experience. Kind of an interesting fact about this. Cool. What else we got? Design system and teams go beyond designers and developers. Design system teams don't just include designers and developers. Regardless of design systems age, there's at least 1pm and one content writer on the team. I'm so encouraged to hear that. I know a lot of design systems start with designers and engineers, but oftentimes grow to be larger than that as they should. Any good product can't just survive on a designer and an engineer solely, even though those are important roles. They do need product management, project management, business analysts, strategists, you know, things like that. So I'm glad to see that that's being reflected in here as well. So we've got here. I guess this makes sense. Heavy, heavily weighted to design and engineering, especially for the more mature teams. But we see more PMs and content people coming in here. That's really great and encouraging to see. I hope that trend continues we're not even in the report yet, but this is all good, promising data. I like this. All right. Happiness and documentation maturity. Most respondents, 34%, noted their design system documentation was partially mature. About a fifth felt their documentation was mature. When comparing maturity with documentation happiness, we're not surprised with our findings. Those with very mature or mature documentation were overwhelmingly happy. Documentation that wasn't very mature had significant unhappiness. This isn't a surprise to me. I was on a webinar with zero height last year to talk about the correlation between documentation and happiness. And honestly, mostly just completion and and maturity and happiness. Doesn't surprise me that there's a big correlation between those two. So not surprising again that that trend would be continued the next year. Here. 5 to 7 tokens is the sweet spot for a design system. I love this. This is so awesome. When I teach design tokens, one of the big things that I teach that takes a lot of people some time to change their minds about is that they should build a small design token system and just a small design system in general because they're easier to maintain. They can be very powerful. They follow the sort of Pareto principle that 80, 20 split that, you know, 80% of your task could be made up with just 20% of your assets. So design tokens fit into that. Design systems fit into that. I love that this is in here. That's a really great surprise for me to see. Five to seven tokens is a sweet spot. So defining six types of tokens seems to be the popular choice. And the most popular token combination included borders, colors, radius, shadow, spacing, and typography. The no surprises there. That's the common stuff, which I think design systems should be the common stuff. So awesome. Most respondents use between five and seven tokens. Not many just dabble with a few tokens or go all in with over eight tokens. Love that. Curious to see some of the details around that when we open up the report, but awesome. Very, very cool to see. Documentation is great for truth, onboarding and confidence. Okay, cool. I have some opinions about this source of truth idea. Maybe I'll get into that a little bit later, but I'm really thrilled to see onboarding and confidence in here. I think that's a really important thing to design systems, so let's see what they say about it. We added this question this year to get a sense of people's sentiment. Respondents feel that their current documentation serves as a single source of truth. Okay. Helps with onboarding. Excellent. And informs teammates so that they can do their job confident. I love that they feel differently about using it as a recruiting tool where most are neutral or disagree. Interesting. Okay, this is overwhelming to me so I'm going to skip this. We're going to go past this and we'll see what is in the report. Alright. So cool. Microsite. I love that there is a very simple way to kind of digest the findings as a whole. And overall, let's see what's in the details of this report. See if there's anything juicy in there. Alright, so the details of this report, we see here that it is a 63 page report. So a good chunk of things that we can look into here. We've got how we document 2023 report. My face is blocking the Brought to you by zero height. That's an important thing. Thanks for making this. All right. Maybe my face is on the wrong spot. Let's put over here. Welcome to 2023. Design system documentation continues to gain momentum every year. How we document is an opportunity to reflect on the changes. Blah blah, blah. 500 over 500 participated in where we're at to establish where we're at, where we're going and where we need to be. Very exciting. Okay, who took this survey? Organization, Design system team documentation and happiness. What I'm interested in seeing through this, just looking at this table of contents is. I don't know what's my favorite part here. Design system team. That's always interesting to me. Documentation. I'm interested in zero heights findings because that's what they do as a company. And then you know the correlation between happiness and documentation and maturity level. Yeah, I guess everything in here is pretty interesting. All right, let's roll on. Who took their survey? 72% of disciplines were design and UX. Okay. Engineering is separate. Interesting that design ops is split out here as not part of Design and ux. I would have expected either way. Either that's rolled into design and UX or as a separate thing. But just notice that that's called out here. Product management as a separate discipline makes sense to me. Content as a separate discipline makes sense to me. All right, 518 respondents. Right. Let's see what else job titles. There were 238 unique job titles from our respondents. Interesting enough. Interestingly enough, 16% of the job titles explicitly state design system. This is a question that I get a lot when I teach. Recently a lot of people are wondering about the job market in design systems. Especially as our industry is having tons of layoffs. People are learning more about design System skills. And a lot of people are asking like, are there actual job in design systems? A lot of them are not seeing anything anywhere. I've seen a ton. But that might just be because my echo chamber is a design system echo chamber where people are talking about that more and more. But this is a good affirmation of that. 16% of job titles explicitly state design system. I think that's a pretty high proportion there. It's not, you know, in the single digits. I can imagine that that'll get larger and larger as that happens. 77% is in within. Was within the designer group, which makes sense. It's got the word design in it. Like design systems. Again, engineering makes a lot of sense. I wonder what this other is in here. You know, product manager makes makes sense to me. Design ops and content. I can see those growing. I wonder what this other bucket is. I wonder if they'll have more about that later in the report. But lots of good encouragement that 16% of job titles explicitly state design system. That holds pretty well for and fares pretty well for a lot of people. Aha. Here they are. Design system job titles. Thank you. Zero height. So within the disciplines in design, Design system designers and leads and product leads and lead design. Okay. All these different permutations here. Operations, design ops and design system manager, Management, product management, engineering. And if I move over here, other roles. Design system specialist. That's interesting. I wonder what that role entails. Senior design system analyst. I love this. I love seeing the roles of strategy and business analysts being included in design systems. Again, that just adding to the signal that design systems should be treated like real products. So if a product that you're working on or a feature you're working on is going to have an analyst or strategist on it or writers, why wouldn't a design system so really encourage to see that in design system land? Awesome professional experience. Okay, we looked at this a little bit earlier that most people have. Oh, what does this say? Most people who completed the survey have been working professionally for over 10 years. That's different than what we saw in the in the microsite, isn't it? I thought we saw that most people who completed the survey were in this one to three year mark. All right, let's see what this says a little bit more. That's interesting to me because that's not. That's sort of the opposite of what we just saw. But maybe not. This is what we saw. Most of our respondents have been working on design systems between one and three years. Wait, that doesn't make sense. How does that. Let's go back. So this previous slide says professional experience. 50. Okay, so all right, I kind of get what this means now. I think what this means is people who took this survey have been in the design or engineering game for 10 plus years, but maybe only have one to three experience in design systems specifically. Maybe that's the correlation they're trying to make here. So I missed that nuance going forward, but I think that's the case and if that's the case, that makes sense. I think design systems are a relatively new industry compared to UI design, product design, visual design, you know, product engineering, software engineering. So it makes sense that people that have engineering experience or design experience would then be moving into design systems as a relatively new field. So cool. Makes sense to me if that's accurate. Age doesn't equate to design system experience. All right, that makes sense too. Most people had only one to three years of design system experience. Most people with three to five years of experience were 35 to 44 year olds. One could guess the timing was right in their career, they likely had enough professional experience to explore design systems when it was new. What's encouraging is that regardless of age, most people are relatively new to design systems, so the playing field is pretty even. Again, really great info for people who are just starting out in design systems. Even though you are perhaps competing for spots with people who have a lot of experience in general in the field. Just about everyone's new to design systems, so no one really has that much more of a head start over anyone else. Yeah, I agree with what zero height is saying here, that that's an encouraging thing. Very cool. Women are well represented in design systems. This is excellent. This is one of the things that I really love about design system work is that from a gender equity perspective, this is what I found to be true across the teams that I've worked with is that I seem to work with an equal amount of men or people who represent as men as well as women. People who represent as women. Interesting here that 2% non binary, genderqueer or gender non conforming. Love to see that increase a bit more. I wonder how we make room for more people like that. That's something that is interesting to me and important to me in my work. I wonder if there's anything else in this report about some of those things too. Cool. So gender equity. I'm glad to see this in here. Most roles are dominated by men, so I assume that this means in general over the fields of design and engineering, not specifically design systems. So I think that's what this says. You know, content 76% women design and UX 51% men design ops engineering PM other so I guess what that's saying is design systems as a subset has a much more equivalent or, or, or much better equity in terms of gender. Whereas the larger umbrellas of the disciplines, design, ux, engineering, things like that, are much less equitable in that way. So it means some work to do. Men only slightly outnumber women and in some levels. And again, okay, so this is from a, I guess a role perspective. Executives, founders and owners, freelancers, individual contributors, managers, these all hover around the 50, 60% mark. So very interesting. I'm not sure what this has to do with design systems. I don't know that I have a particular opinion about that. But interesting data in here nonetheless. Ethnic identity isn't very diverse. Yep, that's not surprising as well. A lot of the teams that I've worked with, there are usually only a handful of people in a lot of these particular ethnicities, from Asians to Hispanic, South American, multiracial, Indian, African. This tracks to me with the teams that I work with. Oftentimes I am the person on those teams that is probably this 6% or 1% or 2%. So again, lots of work to do there. I wonder if this report states about whether that is growing or shrinking or holding. I wonder what the trend is there at least compared to last year's report. I'm not sure if they reported on this last year. So let's see what else we've got. Respondents were overwhelmingly white or European. So okay, a lot of this is self, self selecting too in that these are really about the respondents, not necessarily about the industry. Although I wonder how representative the respondents are of the industry. So curious about that here. All right. Your organization, how big is your organization? Most people who replied worked at companies under 100 people. That's surprising to me. I would have guessed that most of the people who responded were in this kind of enterprise size. So interesting that it's sort of the lowest tier here. Design systems tend to be most obvious at enterprises and keeping design at scale managed. So in those 100 person company, I wonder what kind of scale they're working with. Design. But maybe that's what makes design systems manageable at that size as opposed to, you know, if you work at a company of a thousand people, perhaps, you know, a design system is just an overwhelming task and maybe hasn't even got started at that point. In house or agency? 85% in house. Okay, that makes sense. I specifically get a lot of people who are asking me from agencies how they build design systems. But I think a lot of that is the fact that I have agency background. I ran my own agency, I worked at a bunch of agencies before. So I think a lot of people maybe look to me to know a little bit more about that particular use case. It does make more sense to me. And a lot of the teams that I work with with design systems are in house teams because the need is just so great. At an in house team you need internal tools, whereas lots of agencies don't have a lot of homegrown internal tools because a lot of the work that they're doing is handed off to their clients and their customers. All right, design org, 54% of people work at design orgs of one to 10 people. This is such an interesting trend to me. I'm seeing this a lot in my own work in that I'm getting a lot of inquiries from people on the smaller team size. Maybe because design systems tend to live here in the thousand people orgs in the big enterprises or maybe at least got their start or at least are more popular there and more talked about there. The people at smaller organizations are going well, how could that kind of work for us? So again, I would be curious to see this trend, the trend line of the people who are responding, are they, are they trending to conversations with smaller and smaller teams? Or is this something that is held for a while? I wonder. Designers and engineer ratio. So what's this saying? When it comes to designer engineer ratio, that ratio grows with organization size. The increase is fairly steady, but jumps significantly with organizations over a thousand employees. So organization size for every one designer there are this many engineers. So for organizations that have about 50 people or less, there's about one designer to every four engineers. For organizations that have 100, there's one designer to seven engineers. Okay, I see, I see how that goes. For every hundred for every one designer at a 500 person company. So the larger the company, the more the ratio of one designer to more people, it gets more and more. And so this kind of tracks with the stuff that I was talking about earlier in that at larger enterprises you need design systems to help scale design because the ratio just grows. I wonder if there's a bell curve somewhere here as it gets to larger than the size. But again, this sort of tracks in terms of how many designers work at an organization and to how many engineers. A lot of the Tech industry is engineering heavy. I know there are exceptions to that, but this kind of supports that, that data or that theory. All right, design systems. We're a third of the way through page 20 of 21 of 63. So design system teams are more likely in bigger organization. Okay, we were just talking about that. Seems like they were leading up to this. In this report, 61% have a team, 31% have a team with full employees. 30% have a team that's partially resourced. Right. So more likely at bigger organizations. Makes sense. Design system team size, four to nine people. That's great. I have worked, I've rarely worked with teams that have 10 or more people. And honestly, I'm not sure what you would do with a team of 10 or more people on a design system. That's not to say that there isn't that much work to do. There's a ton of work to do. But I find that larger than 10 people, you start to have the law of diminishing returns in terms of you trade efficiency problems for communication problems now, because now you have to keep everybody aligned, you know, so I'm not. I don't know that you gain any efficiencies over 10 people, but I'd be curious to talk to more people who are working on teams of design systems that have more than 10 people. I do find that this is the sweet spot. I like a team of six, you know, six to eight generally. But and this kind of tracks in that design system team size increases with company size. Okay. This is related to what we saw before about the designer engineer ratio, you know, at 1,000 plus people, you know, teams of 11. 11 people. Again, so there's an interesting trend line here. It looks like six people. Yeah, interesting. I would imagine at an organization of 10 people, six of them are on a design system team. And that's probably because these six people aren't just exclusively on a design system team. They're probably doing design system work in addition to all the other kind of work there too. So I'd be curious to see. You know, I wonder if this question was worded about exclusively on the design system as opposed to, you know, I imagine that these people here are probably exclusively on a design system, are not working on product teams or feature teams or anything like that. Whereas this is a little bit different, but I don't know, I wonder if that's represented in the data at all. Design system teams go beyond designers and developers. Cool. We saw this a little bit in the landing page as well. Your design System and documentation. Okay, all right. Zero height in your documentation platform. Let's see, let's see what you have to say and report. Design system are gaining traction. Excellent. A bit self serving here because. Because of who zero height is, because of who I am and because of who are responding to this. But good data nonetheless. Most design systems are under are one year old. A majority of design systems are under three years old. Safe to say if you don't have a design system yet, not too late to start. Excellent. I agree. Documentation has become a natural part of the process. Where, where though? That's the thing that I'm interested in. 89% of design system docs are between 0 and 3 years old. The difference between starting your design system and documenting it is relatively low. Interesting. This year 87% of design systems start documenting within one year of starting their design system. See this worries me. I like this makes sense, but I don't like this. What I try to teach teams is, you know, not within one year. That means. Does that mean that within the first year there's a time where you don't have documentation with your design system? That's terrible. That's awful. How do you expect people to use it and know how to use it? That's where I see a lot of design systems atrophy or just never get picked up because of the lack of documentation. I think there's easier ways to do documentation so I'd be curious to see if that's part of this report. Somewhere in here code and code first tools are leading the charge. No surprise there. And very exciting note taking. Tools Design tool itself. Okay, so my guess is I wonder if they will name some of these tools in a couple of slides. But my guess here is that these are the web flows and wordpresses of the world and framers and things like that. I see a lot of people lately building their reference sites in those kinds of tools as opposed to a zero height or actually I wonder if zero height and Supernova and tools like that. I wonder if they count themselves as code and code first tools or if they're one of these. Maybe they're more third party design system managers or things like that. Be curious, let's see if that's in here somewhere. Design tool itself. I imagine this refers to figma. So you're designing in Figma, perhaps you document in Figma or Storybook, something like that. Self built solutions. I wonder where the trend line is on this one too. You know, self built solutions, is that trending downward? Are people just no longer spinning up their own, you know, Gatsby sites or anything like that. I know I was doing a lot of that work the last couple years ago. Now almost every design system I work on with a team tends to be we spin up a zero height site or a supernova site or a, a notion site, you know, something like that. You know in order to work with with documentation very quickly. So let's see if they name some of the tools here. There we go. There it is. The most popular documentation tools. The design tool itself. All right, so Figma Sketch XD Storybook is next. Okay so Storybook is, is part of that design tool. Next up, Zero Height Confluence. Yep. Self built solutions. 15% encode documentation. I wonder if this is like readme files or code comments or things like that. Again with a lot of these. I wonder if these are, I wonder where the trend lines are. These increasing, you know notion is a tool that people are using a lot now there's a big renaissance in note taking tools and things like that. So I wonder if we'll see more of that, more of the notions, more of the crafts or obsidians or things like that in here. GitHub pages again no wondering about trend lines for some of these tools. Tool combination Bingo. I love this. I love that they introduced this and included this here like last year. Organizations continue to use a combination of tools to get the job done. Our top combination this year is Zero Height and Storybook. Teams also rely on just their design tool in Storybook even though not a specific design system documentation tool Confluence is in combinations that round at the top five. So this is something that I see a lot and honestly I encourage teams to, to do especially as teams are larger, more on the enterprise side. The combination of tools is like, it's just realistic. I talk to a lot of tool makers that really want to be the one stop shop for you know, we want to be the design system manager. There have been a lot of tools in the past that way, a lot of tools coming out in the future and I'm just not hopeful for that. I don't think that one tool is going to do everything that has to be done in design system really well and I just don't think it's realistic to organizations. You know I like using tools that are small and well built to do the job that they're supposed to do. No coincidence then that that's how I like my design systems to be as well. You know I like small design systems that do the job really well. 2020 components 10 components that are awesome, I think is better than a design system that has 200 components that are not so awesome and not so well maintained, not so well contributed to, you know, not so well adopted, anything like that. So this tool combination that fits much more in line with my style of how I like to work on design systems is combine the tools that work for you, even if, you know, even if the integrations aren't quite there. I think people are more resilient than that and will figure out their own solutions. Whereas putting all your eggs in one basket is a bit tough from a tool standpoint. All right. Very few have their systems 100% documented. That makes sense. It's hard. Documentation is hard if it's not part of the process. And I think part of good design system work is figuring out where it is in the process. So under 25% of the design systems document, 36% of respondents said that, yeah, I think it's realistic. I wish it were more. I bet everybody wishes it were more. But this is cool to see kind of the reality of it. And what I like about reports like this is that I think it just helps people to understand what's normal. Because when design system teams work on design system stuff in a vacuum, you know, they might feel really down on themselves for being like, ugh, only a quarter of our design system is documented. But it's the reality, you know, you're not doing any worse than anybody else. Look at this. You know, and for a lot of people, that gives them comfort. You're not. You're not any worse. It could always be better. Right? So there's always ways that you can make it better than this. You know, perhaps. I wonder if in this report they get into process, you know, where documentation lives in the process and maybe even suggestions and recommendations. But this is. This is a good reality slide. This is a good slide that says it's normal, it's okay to be here. You know, you can always do better, but don't worry that, you know, you're doing it worse than anybody else. You know, this is a good, normal, normalization slide. What does your documentation include? Lots of stuff here. Color. Yeah. Makes a lot of sense. Atomic components, typography, brand guidelines, you know, all the common stuff. Design tokens. Okay, cool. I'm not sure that I have a particular opinion about this slider, what it's saying to me, but good to see this lay of the land here. I may come back to this sometime in the future to figure out what this means for my work. Most of our documentation is monolingual. Yep. 80% do not localize. I think that makes sense. I think that's just where we are in design systems. You know, it's hard to do two things well if you can't do one thing well. So I wonder if this will change in the future. Again, I wonder about trend lines here. I wonder if this is more than they found last year. I wonder if we'll find more in the coming years. But again, some trend lines would be. Would be cool to see in the next version of this report. Version control is a sign of maturity. 42% do not have version control. Interesting. I wonder how you could use a design system without version control. I mean, I guess it happened. I guess that those are in the way that I talk about them. Those are design systems as projects instead of design system as products. If you do a design system as a project, you make one, you finish it, you know, you ship it and then you use it for a while, I guess, and you don't improve it. And if you don't change anything, I guess you don't need version control. That seems like a risky proposition to me, especially with the amount of investment of work you have to put into design systems to get them up and running. But. All right, again, this might be just a reality slide that, like, this is where it is. This is where we're at, how people contribute to your design system documentation. Okay, good stuff here. About a third of respondents have a contribution model and about a third are creating one of those that have a contribution model. Very few have a model they feel is effective. That makes sense. Contribution models are hard because it's process stuff. And this is what I was talking about earlier. Hopefully we get into some more process stuff here. But we are getting into it. I think it's because people don't know when to document or where. And when I said where earlier.