The State of Design Systems in The Netherlands 2019
We researched the state of Design Systems in The Netherlands in October 2019. The participants were a beautiful mix: big A-level brands, small companies, freelancers and agencies all participated. With this survey we aim to give organizations a benchmark for their own work on Design Systems.
With this article we want to share our results with you.
Table of Contents
This article scratches the surface. We have more analysis waiting to be downloaded! Our slidedeck has over 50 (!) pages of findings.
How are these organizations doing?
Last year 63% of participants indicated they had a Design System and about 17% was working on it. These numbers changed a lot, but not how we were expecting!
Question: do you have a Design System?
Of the participants working in-house in an organization 40% indicate they have a Design System (down from 63%) and 43% says they are working on it (up from 17%). Only 10% indicates they don’t have a Design System (down from 20% last year!) and 7% is not sure (we’ve excluded this 7% from further analyses).
This means now more people than last year indicate they are working on their Design System, instead of having one. Looks like more people come to realize that a Design System is never finished.
Most organizations are still working on getting Design System code into production code
Question: How much of your application/website uses Design System code?
The maturity index
The Design System maturity index was created by Marcelo Somers and John Gully. It’s a nice visualization to see how Design Systems are doing.
We can see that a lot of organizations are already past stages 1 and 2 (no system or a PDF). Most companies are currently in stage 3 (having a UI-kit and component library), and 15% is already transitioning into stage 4. To those 9% already in stage 5: congratulations!
Question: How much of your application/website uses Design System code?
Not all participants consider their Design System a success
We were surprised to see that 27% of participants answered ‘no’ to this question. But, taking a closer look that’s mainly because of the Design System still being in development. Also mentioned a lot is adoption.
Question: Do you consider your Design System successful?
In boosting the design proces, transfer to development and overal consistensy in UI and patterns within the product it certainly has been already succesful. But the real power of the system comes when we make further process in translating de system to reusable code in the application. We have made a good start, but we must further expand this side of the design system.
We have a lot of products within the company in different countries. Creating the Design System is a big step for us to start to keep consistency across all the products and make UX Design transparent across UX teams. There is still a lot of work to do including internal training how to use Design system (not all the teams use it at that moment).
10% of participants say their organization does not have a Design System
The main reasons these 10% of participants do not have a Design System are budget constraints or a lack of skills (in design or development).
Interestingly, one person mentioned a Design System is not necessary in their organization.
We just employ a design strategy, principles & process. Beyond that, the products we design & develop are focussed on different markets en persona’s. A low-level front-end framework is part of the company’s standard development stack which does provide some code and to a certain extent UX consistency.Survey participant
When; Design Systems are (still) relatively new
Surprisingly, the Design Systems are still very new in our group of participants. We had expected the numbers to have grown from last year, but this was not the case.
The large majority (57%!) has worked on their Design System less than a year. That’s down from last year, but not as much as we expected. Did people start again?
What’s more, almost 30% indicated they just started working on it. So Design Systems are still a hot topic!
|More than 2 years||15%||11%|
In most organizations the Design System is very new. That’s very similar to last year: the people indicating less than a year was 66% then and only 57% now. The 1-2 years has grown tremendously going from 19% to 32%. Longer than 2 years went from 15% to 11%.
Large organizations have Design Systems longer than small organizations.
This one is as we expected: 68% of the big companies have had a Design System over a year, while only 21% of small companies (< 500 employees) can say the same.
The process of creating a Design System.
We asked “In your own words: What was the process of creating the Design System?” from the many different answers we could distill two situations. A naturally grown DS (there was a style guide / UI-kit that grew into a system) and the ‘on-purpose’ DS where a process was followed.
Some common elements of that process:
- setting fundamentals (such as type and colors)
- decide on tools
- auditing current UI
- define flow with design and development
- … and “just start building”
Surprisingly only two participants mentioned “defining the needs” as a starting point. Researching existing Design Systems was only mentioned once, while researching existing tools and flows was mentioned three times. While we agree it’s good to just get started, it’s also a good idea to make sure you define your success criteria and do an inventory of existing tools and processes (you can use our free tool ‘Grand Perspective‘ for that).
Overall, there’s a lot of focus on tooling and implementation in the answers and less on people and alignment. Looking at the struggles with Design Systems (see later on), we need to transition to a more people-focus!
The process of creating my Design System was…
- “An adventure”
- “a bumpy road”
- “a long process”
- … it “took a while”
Why; Motivating the existence of a Design System
Most Design Systems are started by the design team or the senior designer: 66% of Design Systems project start that way. Most other participants indicate that it was a combination of design and development. Only 12% said the management started the project.
A quarter of the participants indicated having external help with setting up their Design System. Of those that had help, the main help consisted of knowledge about Design Systems or extra visual designers.
The main reason by far our participants indicated for starting their Design System is UX/UI consistency. A whopping 75% indicated that as the high-priority motivation. On second place are increased design and development efficiency and code-reusability.
Note, this correlates broadly with the global averages, although we apparently value UX/UI consistency more in The Netherlands than the rest of the world (75% vs 61%).
Differences between designers and PO/management.
Product owners / management value “Maintaining brand standards” as an important motivation for starting the Design System, much more so than designers.
Although both groups value UX/UI consistency and efficiency, product owners are also much more value code reusability.
It’s important for designers to keep this difference in motivation in mind when convincing their managers of the need for a Design System.
How; Design Systems in use
Like last year, the roles involved with Design Systems are mainly designers and front-end developers. Design Systems are used daily or weekly and provide benefits in consistency and speed of development.
Maintaining Design Systems
We are happy to see that almost all organizations in the survey indicate that they maintain their own Design System. Only one participant indicates an external company maintains their Design System (note: surprisingly the participants from agencies/freelance paint another picture, see later in this report).
Design Systems are usually maintained by employees during their normal work (59%), or by a separate Design System team (29%). One in ten participants (11%) mentions maintaining the Design System is the responsibility of one person.
Design Systems are usually updated weekly (48%) or monthly (38%). This is a huge transition from 2018, where most Design Systems were updated monthly.
|Monthly (or more)||66%||38%|
note: this analysis excludes those that mentioned ‘other’
Roles involved in maintenance
The usual suspects are involved in maintaining the Design System: UX designers, UI designers and Front-end developers.
One in four participants say a product owner is involved in maintaining the Design System.
Other roles mentioned are the brand manager, tester, scrum master and A11y expert (accessibility expert).
Using the Design System
We see a similar distribution of roles, but interestingly, more people use the Design System than those involved in maintaining it.
Question: Who uses the Design System?
Especially development teams use the Design System daily. Designers and product-owners/management weekly to daily.
Comparing usage to last year it appears usage has stabilized into weekly usage (from daily usage).
|Monthly (or more)||14%||14%|
note: the option ‘never’, which was mentioned 4% in 2019, was not possible in last years survey
Updating your website
It’s great to have beautiful components, but they have to be used in your website or application as well. Interestingly, most participants (32%!) don’t know how code is distributed to their live-site (we’ve removed those from the detailed analysis).
We saw [earlier on](How are these organizations doing) that most organizations are still transitioning to using Design System code in their production-code.
|How is DS-code distributed to your live site?||World||NL|
|In an external codebase and consumed via package manager||38%||26%|
|On a standalone documentation site where users primarily copy + paste or download files||26%||10%|
|Included in the main codebase||17%||16%|
|In an external codebase and consumed by the main codebase’s build pipeline||15%||10%|
|Other / no DS-code in production||4%||22%|
The world-results are based on the Design System survey by Sparkbox
There is a clear top three in tooling: Sketch (60% mentioned this), Storybook (36%) and Figma (23%). It appears Design System-specific tooling has grown up: less people use homegrown solutions.
Compared to last year, there are four big surprises: – Storybook grew tremendously (from 4% last year to 36%) – Figma made a huge entrance (from 0% to 23%) one participant mentioned “a good idea to try out Figma” in 2018 – Zeroheight made an entrance (from 0% to 11%) – Homegrown solutions are down (from 37% to 12%)
FramerX, Axure and Affinity Designer were mentioned once
To the person that mentioned using Powerpoint to maintain their Design System: please contact us. We need to know!
Compared to global mentions, we use less Invision DSM and Patternlab, but much more Sketch.
What; Contents of your Design Systems
There are four elements most common in Design Systems: a color- and typography system, and form- and navigation-components. Four out of five participants say these elements are in their Design Systems.
Compared to the world
Design Systems in The Netherlands have less of everything, especially the following:
Small vs big companies
Big companies (with 500 plus employees) have more of everything in there. Especially usage guidelines (80% vs 60%), code (72% vs 52%) and principles (64% vs 45%). There is also a significant increase in content-, accessibility- and coding guidelines, as well as information about the Design System team and on boarding.
When asked which things are most useful from the Design System in day-to-day work most people mention components, patterns and templates (40 people). Others mention using smaller ‘things’, like color or typography (12 people).
From struggle to success
Around 27% of participants say their Design System is not successful. This number drops to 13% for participants that have a Design System more than a year.
Of those who think their Design System is not successful, most mention this is because their system is a “work in progress”. Some mention adoption (“Isn’t used by all designers yet “) or process (“gap between design speed and development speed“).
To early to really say so. No, because its not completely done and because of that we are not always using it. And takes lot of time to set up. Yes, because it helps us to refer to when devs are in doubt. Also we see the potential. Also we hope other departments will use it(but not sure yet, but its the biggest goal for us)
The common struggles
Interestingly, both big (500 employee plus) and small organizations run into the same common problems: adoption (43%), maintenance (41%), staffing (39%) and team-maturity (32%).
This is what we saw last year as well: Design Systems consist of people, process and parts – and especially people are the main important thing.
This is on par with global numbers, except that ‘team maturity’ is much more a problem in The Netherlands (32% in The Netherlands, not mentioned globally) and a lack of an executive champion is much more a problem in the global survey (35% globally versus 16% in The Netherlands).
Currently the Design System is a side project for everyone involved. Because everyone has plenty of other tasks (with a higher priority), the development of the design system is slow.
Designers and frontenders did not communicate very well so there are still differences between the design and the implementation
It can be time-consuming to add descriptions on how to use the components. Its hard to prioritize maintaining and refactoring the DS over designing new features
The main problem is good front-end developers in the organization that can help grow the system. Right now it’s basically only one person pushing the code quality. This should be more evenly distributed.
Missing a single source of truth
I would love to have someone dedicated to working on the Design System, but that also a luxury I’m not sure has enough benefits to the organization. We have a lean way of working that is focussed on the stories that we push instead of the consistency of the platform.
When we help people set up Design Systems, the one thing that’s for sure on everybody’s mind is tooling. But from our survey we see different results. People who have a Design System (or is working on it) mainly talk about people and process.
We asked people what they would do differently if they could start over. Luckily, we saw a lot of positive remarks as well (“Quite happy with how it went!”).
Better plan ahead and focus on primary building blocks first before starting the icing on the cake
Presenting the need for a Design System to management earlier, to get more time to work on the design system. Especially more development time is important
We have a big community of UX/UI designers in the company. It would be helpful to make them aware in advance that the Design system is being created.
1. Just start. And start small
Start small was mentioned by 32% of all participants, which is an enormous amount for an open-text field. “Just do it” was mentioned by 20% of all participants.
We’d like to add to that: stay small. Make sure your Design System is lean, because most people who have a Design System for over a year experience more issues with maintenance and staffing
Start by defining the fundamentals like colors, typography and icons. These will be needed for every component. Define rules for layout, spacing etc. in an early stage
Keep it lean: Don’t make it a several months project and then publish it, instead create the basics and add the tokens and components as you work on the product
Just get started with a proof of concept (possibly by investing your own time), followed up by getting the right people aboard/invested
2. Communication is key
One in five participants mention communication as the best tip for Design Systems.
Talk about it and make sure everyone knows what a design system is and what the benefits are
Make sure you have a good story that suits your company. Everybody needs to want it in your organization
explain to everyone that it is a growing thing
Talk! Everybody needs to want it in your organization. If it’s only a designer party it’s useless
3. Involve others early
Involve others early, but be smart who you involve. Again, involving others was mentioned by 20% of the participants.
But, don’t involve random people! Look at the people who are using and maintaining the Design System (see above) in the first place. Focus your energy.
[…] make sure everybody is involved in decision making
Don’t do it alone: work together, get early buy-in from stakeholders and think together how this is going to improve the workflow and consistency Align with design/development: align the way of working to agree on a way how to set up components and create reusable blocks together
Do the research! (Tools and workflow) Get the right people on board. You cannot do it alone. (Both the designers and the management have a significant role in the process.) Keep focus within the team. (Dedicated design system team)
4. It’s okay to ask for help
One in four participants mention they had external help in setting up their Design System. Of those that asked for help, most mention specific knowledge on Design Systems or help with design or frontend capacity.
My Design System is successful
A selection of motivational quotes from participants that consider their Design System successful:
In boosting the design process, transfer to development and overall consistency in UI and patterns within the product it certainly has been already successful. But the real power of the system comes when we make further process in translating de system to reusable code in the application. […] we must further expand this side of the design system.
We have a lot of products […] in different countries. [The] Design System is a big step for us to start to keep consistency across all the products and make UX Design transparent across UX teams. There is still a lot of work to do including internal training […]
Already saves time and we have more and good discussions about design solutions and ux with all the disciplines involved.
People don’t ignore it, we’ve got covering from management, people are happy with it. And it’s used by our central platform which covers more than 35 countries
As the adoption rate increases, more developers are inclined to use it from the start. [Developers] are happy that they no longer have to do the tedious work anymore.
I use it everyday to build my designs while efficiently maintain branding, consistency and accessibility.
Single-source-of-truth (less discussions), easy sharing information (in the organization and external parties etc), brand consistency.