Established in 1997, GoDaddy is a domain registrar and web hosting company. A staggering 78 million domain names have been registered through them and they host over 19 million users. With 14 offices across the world, GoDaddy has evolved from that-place-with-the-weird-name-where-you-can-buy-domains to a well-rounded web service that will help users make something of those domains, providing templates to build websites and marketing tools to promote them. By now, GoDaddy would probably love it if the press didn’t mention their old ads as the company is trying very hard to completely shed the sex-sells approach but, no, we do not forget. This week, GoDaddy introduced a new logo and identity designed in-house with strategy by Lippincott, logo design by Koto, and leadership direction and implementation in-house.
The GO is a clear statement of advocacy for entrepreneurs everywhere — a symbol of empowerment that encourages them to stand on their own two feet.
The GO was created as a visual representation of the space where three ideas meet:
Entrepreneurial spirit We created the GO’s swooping arcs to represent the indomitable spirit of everyday entrepreneurs. And the word “go” itself is our rallying cry for folks to take the first or next step in their entrepreneurial journey.
Joy Joy is a corollary to the love that fuels entrepreneurs to make their own way. The GO’s heart shape is a nod to this feeling, while its bold lines radiate the same joy that entrepreneurs everywhere experience.
Humanity Entrepreneurship should be accessible to everyone, which is why we bring humanity into our digital tools for the benefit of all. The GO’s continuous, overlapping stroke symbolizes the connection all entrepreneurs share, and its generous interior space has room for folks of every stripe.
Logo introduction.Logo.Icon detail.Logo animation.Logo trait animations: Entrepreneurial Spirit, Joy, and Humanity.
In 2018 GoDaddy began the process of sweeping its old “guy” icon under the rug by dropping it from the logo — visually, it was the last connecting thread to the GoDaddy brand of old that made it even harder to forget about what their brand stood for. After an interim period of no “guy”, the company has introduced a new icon, the “GO” and Imma say “STOP”. There are a number of things that are not necessarily wrong but just very awkward. Based on the animation the logo is meant to be a heart but in its static form it looks like two ovals stacked oddly one on top of the other with the not-so-hidden “G” in there adding a whole lot of confusion. It doesn’t read like a heart at all because there is no depth to the loops and the one line that could make that connection is abruptly ended by trying to make the “G” — that hard-angled line pointing down and left kills this logo. Comparisons to Airbnb’s “Bello” are fair not just for the similar approach in design but the douchiness of giving it a pretentious name. (As much as I liked and championed the Airbnb logo I always disliked that they named it so annoyingly.)
Conceptually and/or contextually there is something very off about the icon too: it looks completely out of place next to the word “GoDaddy” — it’s really impossible to not think “Who’s your daddy?” (and all that that entails) — and, while I get that they are trying to appeal to the entrepreneurial spirit, let’s not kid ourselves, they sell domain names and templates, not dreams. I’m all for companies establishing an emotional connection with its audience and that’s in part what branding is for but this feels very forced and inauthentic. But let’s continue with the design aspects… the wordmark has been slimmed down, which makes for slightly better readability but the squared-off counters have been lost, which is a detail I really liked in the old logo. To the credit of the icon design, the weird angled line is the same thickness and rounded-corner-ness as the “G” in the wordmark. The new blue color is a little annoying in its vibrancy and I’m surprised they moved away so drastically from their green color, which I thought was fairly recognizable. So, to summarize my logo feelings: not a fan.
Always bright and dynamic, our brand colors speak to the creativity of our customers. Our wide palette connects with people across the globe and promotes inclusivity for all cultures. We use color to bring joy to our brand.
Our bold, serif headline font is elegant and expressive projecting a fresh, modern voice. It presents a hint of flair for professionalism, giving the brand a distinguished feel. We use it to establish strong moments of brand for customers.
Another big shift in the identity is the use of the bold, pointy, serif trend that has been widely adopted by editorial brands — Medium, The Guardian, BuzzFeed News, and others — and it also feels so out of place for GoDaddy, like a kid putting on their parents clothes. Visually, it’s far too unrelated to the icon or the wordmark and while it works graphically as a headline font — because, well, that’s what it is — it just feels like a gratuitous choice to add a quick dose of maturity.
Our photography lets people see themselves in our brand. Whether it’s capturing entrepreneurs in the moment or presenting them as heroes, we want their personality, independence and energy to shine through. When showcasing our products or anything else, our approach to photography is simple — keep it bright, bold and inspiring.
Photos are fine. Not exactly in a cohesive style or art direction but they have the right content.
Our hand-drawn illustrations add a touch of humanity to our brand. Some concepts are easier to convey through thoughtful illustrations than through image or word. We apply a light-hearted, editorial approach that intentionally compliments narratives across our experiences.
These are pretty cool — a nice step up from the typical mono-thickness-line trend.
With thoughtful concepts and bold use of color, we use a bit of personality to embody the story of intangible products and complex ideas. We want to create an inspiring world that sparks the possibilities our customers can create.
3D illustration style.3D illustration style, animated.
These are also very cool and fun, especially the animated ones. Unrelated to the other illustrations and photos but cool, sure. I could accept the rationalization that both illustration styles feature hands but, like the choice of bold pointy serif, both illustration styles seemed like they were picked to fill a quota of Things That Brands Do Today.
Business cards.
Ads.
Poster.Sign.Beanie.T-shirt and tote.
The applications are all fine and good in terms of execution. There is clearly a lot of care being put into the implementation and into building a visual language that can flex in different ways and styles. I don’t think it’s very cohesive or entirely convincing but it does get its messaging across vibrantly.
Brand video.
Overall, for me, there simply is too big of a disconnect between what the company offers and the overly emotional and philosophical positioning behind the new identity — it’s great that GoDaddy is convinced by it and trying to create this atmosphere but I’m not buying it. Maybe I’m alone in this and maybe I have some weird prejudice about GoDaddy not because I’m offended by their old ads — heck, they were fun at the time — but because their old brand, from the name to the logo to the website, had always been so extremely amateur that I can’t suddenly see them in this new heightened light. Nonetheless and I guess what matters in the end is that for any new customer going to buy a domain name at GoDaddy for the first time, it will all look like a respectable place to do so, which hasn’t always been the case.
See what else happened on Brand Neweach year since publication began in 2006
Design systems help us to make our products consistent, and to make sure we’re creating them in the most efficient way possible. They also help us to ensure our products are designed and built to a high quality; that they’re not only consistent in appearance, and efficiently-built, but that they are good. And good design means accessible design.
With that in mind, I’ll explain the four main ways I think we can use design systems to promote accessible design within an organisation, and what design systems can’t do.
1. Bake it in
Design systems typically provide guidance and examples to aid the design process, showing what best practice looks like. Many design systems also encompass code that teams can use to take these elements into production. This gives us an opportunity to build good design into the foundations of our products, not just in terms of how they look, but also how they work. For everyone.
Let me give an example.
The GOV.UK Design System contains a component called the Summary list. It’s used in a few different contexts on GOV.UK, to summarise information. It’s often used at the end of a long or complex form, to let users check their answers before they send them, like this:
Users can review the information and, if they’ve entered something incorrectly, they can go back and edit their answer by clicking the “Change” link on the right-hand side. This works well if you can see the change link, because you can see which information it corresponds to.
In the top row, for example, I can see that the link is giving me the option to change the name I’ve entered because I can see the name label, and the name I put in is next to it.
However, if you’re using a screen reader, this link – and all the others – will just say “change”, and it becomes harder to tell what you’re selecting. So to help with this, the GOV.UK Design System team added some visually-hidden text to the code in the example, to make the link more descriptive.
Sighted users won’t see this text, but when a screen reader reads out the link, it’ll say “change name”. This makes the component more accessible, and helps it to satisfy a Web Content Accessibility Guidelines (WCAG 2.1) success criterion for links which says we must “provide link text that identifies the purpose of the link without needing additional context”.
By building our components with inclusion in mind, we can make it easier to make products accessible, before anyone’s even had to think about it. And that’s a great starting point. But that doesn’t mean we don’t have to think about it – we definitely do. And a design system can help with that too.
2. Explain it
Having worked as the GOV.UK Design System’s content designer for the best part of 3 years, I’m somewhat biased about this, but I think that the most valuable aspect of a design system is its documentation.
When it comes to accessibility, written documentation lets us guide good practice in a way that code and examples alone can’t.
By carefully documenting implementation rules for each component, we have an opportunity to distribute accessible design principles throughout a design system. This means design system users encounter them not just once, but repeatedly and frequently, in various contexts, which helps to build awareness over time.
For instance, WCAG 2.1 warns against using colour as “the only visual means of conveying information, calling an action, prompting a response or distinguishing a visual element”. This is a general principle to follow, but design system documentation lets us explain how this relates to specific components.
Take the GOV.UK Design System’s warning buttons. These are used for actions with serious, often destructive consequences that can’t easily be undone – like permanently deleting an account.
The example doesn’t tell you this, but the guidance explains that you shouldn’t rely on the red colour of warning buttons to communicate that the button performs a serious action, since not all users will be able to see the colour or understand what it signifies.
Instead, it says, “make sure the context and button text makes clear what will happen if the user selects it”. In this way, the colour is used as an enhancement for people who can interpret it, but it’s not necessary in order to understand it.
Making the code in our examples and component packages as accessible as possible by default is really important, but written documentation like this lets us be much more explicit about how to design accessible services.
3. Lead by example
In our design systems’ documentation, we’re telling people what good design looks like, so it’s really important that we practice what we preach.
Design systems are usually for members of staff, rather than members of the public. But if we want to build an inclusive workplace, we need to hold them to the same standards and ensure they’re accessible to everyone who might need to use them – today and in the future.
One of the ways we did this in my team, was by making sure the GOV.UK Design System supports users who need to customise the colours they use to browse the web. There are a range of different user needs for changing colours on the web. People who are sensitive to light, for instance, might find a white background too bright. And some users with dyslexia find certain colours easier to read than others.
Building this flexibility into our design system helps to support our colleagues who need it, but it also shows others that we’re committed to inclusion and removing barriers.
4. Teach it
The examples I’ve drawn on here have mostly focused on design system documentation and tooling, but design systems are much bigger than that. In the fortuitously-timed “There is No Design System”, Jina reminds us that tooling is just one of the ways we systematise design:
…it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting.”
To make a design system successful, we can’t just build a set of components and hope they work. We have to actively help people find it, use it and contribute to it. That means we have to go out and talk about it. We have to support people in learning to use it and help new teams adopt it. These engagement activities and collaborative processes that sit around it can help to promote awareness of the why, not just the what.
At GDS, we ran workshops on accessibility in the design system, getting people to browse various web pages using visual impairment simulation glasses to understand how visually impaired users might experience our content. By working closely with our systems’ users and contributors like this, we have an opportunity to bring them along on the journey of making something accessible.
We can help them to test out their code and content and understand how they’ll work on different platforms, and how they might need to be adjusted to make sure they’re accessible. We can teach them what accessibility means in practice.
These kinds of activities are invaluable in helping to promote accessible design thinking. And these kinds of lessons – when taught well – are disseminated as colleagues share knowledge with their teams, departments and the wider industry.
What design systems can’t do
Our industry’s excitement about design systems shows no signs of abating, and I’m excited about the opportunities it affords us to make accessible design the default, not an edge case. But I want to finish on a word about their limitations.
While a design system can help to promote awareness of the need to be accessible, and how to design products and services that are, a design system can’t make an organisation fundamentally care about accessibility.
Even with the help of a thoughtfully created design system, it’s still possible to make really inaccessible products if you’re not actively working to remove barriers. I feel lucky to have worked somewhere that prioritises accessibility. Thanks to the work of some really brilliant people, it’s just part of the fabric at GDS. (For more on that work and those brilliant people, I can’t think of a better place to start than my colleague Ollie Byford’s talk on inclusive forms.)
I’m far from being an accessibility expert, but I can write about this because I’ve worked in an organisation where it’s always a central consideration. This shouldn’t be something to feel lucky about. It should be the default, but sadly we’re not there yet. Not even close.
Legally, reputationally and most importantly, morally, we all have a duty to do better. To make sure our products and services are accessible to everyone. We can use design systems to help us on that journey, but they’re just one part of our toolkit.
In the end, it’s about committing to the cause – doing the work to make things accessible. Because accessible design is good design.
No doubt that you’ve probably seen a css font-family declaration that didn’t include a specific webfont, but just the sans-serif fallback, or values like -apple-system, system-ui, and BlinkMacSystemFont.
All of those values will return the operating system’s default sans-serif font, with some differences:
-apple-system works only for newer MacOS versions (El Capitan and newer) and iOS
BlinkMacSystemFont works only for older Mac OS versions (Yosemite and older)
system-ui works for all operating systems, but there’s one notable exception: it doesn’t work in the Firefox browser. Firefox doesn’t support this value, so your text will be displayed in the default fallback which is a serif font
sans-serif will work in all browsers and operating systems, but should be only used as fallback, because in some cases operating systems have quirks like different sans font set for web than in its interface
Whether you use a custom font or not, the recommended complete css font-family declaration is:
You can safely omit Oxygen and Cantarell since they are targeted to certain Linux versions only. Roboto, Ubuntu, sans-serif will be ok for Linux distros.
Default sans-serif font in MacOS
MacOS (El Capitan and newer)
San Francisco
MacOS (Yosemite)
Helvetica Neue
MacOS (older versions)
Lucida Grande
Default sans-serif font in Windows
The difference between Microsoft Sans Serif and MS Sans Serif is that MS Sans Serif was a bitmap/raster font available in 8, 10, 12, 14, 18, and 24 sizes and Microsoft Sans Serif is a TrueType scalable font.
MS Sans Serif was based on Helvetica and in all versions up to Windows 3.1 it was called Helv.
Windows (Vista and newer, including Windows 10)
Segoe UI
Windows (XP)
Tahoma
Windows (2000)
Microsoft Sans Serif
Windows (95, NT, Millennium)
MS Sans Serif
Windows (older versions including Windows 3)
Helv
Default sans-serif font in Linux
Many Linux users re-configure defaults to other fonts like Inter UI or others. So it’s almost impossible to accurately mention defaults, except for the Ubuntu distro which has its own font as default. Red Hat also has commissioned its own fonts, Red Hat Display and Red Hat Text.
Ubuntu
Ubuntu
Red Hat
Other distros (Arch Linux, Debian, Fedora etc.)
It varies, can be DejaVu Sans, Noto Sans, Liberation Sans etc.
Last week over 15,000 people checked out Design Systems for Developers, a free guide I cowrote about the frontend infrastructure underpinning design systems.
The guide’s surprising popularity is indicative of just how mainstream design systems have become amongst developers. In three short years since Brad Frost’s seminal book Atomic Design, design systems like Shopify Polaris, IBM Carbon, Salesforce Lightning, and Airbnb Lunar now power the frontend practice of countless engineers.
Design Systems for Developers examines how the smartest teams engineer design systems at scale and why they use the tools they use. This article summarizes the essential workflow outlined in the guide.
Earlier this year Storybook maintainers and I set out to build a design system for Storybook. Yes, a design system for a tool that builds design systems. At the time, information about this area of frontend infrastructure was scarce. Even though plenty of design systems were open source, developers still had to spelunk through code to see how things worked.
Fortunately as Storybook maintainers, we were in an ideal position to research best practices from the entire Storybook community which includes thousands of projects.
The research uncovered a five step workflow that balances low setup cost, time-saving automation, and convenient developer experience. It’s presented here in the abridged form to give you a head start on engineering design systems from scratch.
Building and maintaining a system isn’t a single discrete task. It’s a collection of jobs that must complement each other.
Design systems aren’t apps; they ship only production UI components. Use Storybook as a “workbench” to build UI components in isolation outside a consumer app. Then customize Storybook’s core functionality to your team’s needs with popular addons:
Actions to verify interaction.Get UI feedback in Storybook when an action (click, hover, etc) is performed on an interactive element like a Button or Link.
Source to view source code.View the underlying code in Storybook’s UI to understand how it works and paste it into your project.
Knobs to explore component props.Interact with component props dynamically in the Storybook UI. That helps design system creators stress test components by adjusting, well, knobs.
As seen at Twitter, Dropbox, IBM
Design systems affect every product and feature in an organization. As such, they require alignment between developers, designers, product managers, and other disciplines.
The most effective way to reach alignment is to publish Storybook online regularly as a part of your CI process. For example, with Netlify, Now, or S3. That way all stakeholders have a universal reference point for UI implementation –all without touching code or command line.
As seen at Shopify, Auth0, Airbnb
As a dependency of many apps, design systems are a single point of failure. Introducing UI bugs in common components snowballs into major regressions across projects. Prevent regressions by automating visual (e.g., Chromatic) and unit tests (e.g., Jest) to run whenever you push code.
Running code through a test suite gives your team the confidence that you’re shipping durable code to all client apps.
As seen at BBC, Salesforce, Artsy
It’s clear that documentation is invaluable. How else are folks supposed to learn your design system? But writing docs is often the last priority.
Make it easier on your team by auto-generating “minimum viable docs” which you can then customize later. With Storybook Docs addon you develop stories as normal and get UI documentation for free.
As seen at SEEK, GitHub, Jetbrains
Now that your UI components are durable, peer-reviewed, regression-tested, and documented, you need a mechanism to distribute them to other teams.
Design systems are distributed as versioned packages via a package manager (e.g., npm). Smart teams further streamline this process using a release management tool like Auto that allows you to seamlessly release new versions from your GitHub workflow.
As seen at Atlassian, GovUK, Mozilla
Products change, users change, design systems change too. A workflow is a standardized repeatable process for delivering good work. Over a design system’s life, teams ship countless updates. Mastering the workflow makes constant improvement satisfying and painless.
What’s more, streamlining the developer experience of common tasks now yields large time savings in the future.
By the numbers, code reuse has the potential to accelerate projects 42–81% and increase productivity by 40%. Design systems help companies reuse user interfacecode. It’s no wonder they’re gaining popularity in the development community.
I hope distilling common-sense tactics into a pragmatic workflow helps you create a thriving design system of your own. Let this be your launching point.
Design Systems for Developerswas produced by Chroma and co-authored by Dominic Nguyen (me!) and Tom Coleman. InVision’s Design Forward Fund provided a grant to kickstart this guide (thank you!). Want to learn more about Storybook workflows from the folks who build Storybook? Checkout these articles:
? Delightful Storybook workflow: We surveyed developers from Squarespace, Discovery Network, and Major League Baseball to find a streamlined UI development workflow
? UI Component Playbook: A 5-step guide to designing and engineering frontends with components.
✅ Visual testing with Storybook: UIs bugs are more annoying and expensive than ever. Learn how to teams at Slack, Lonely Planet, and Walmart test the appearance of modern UIs to save time.
Join Chroma’s mailing list to get notified when more in-depth guides and articles are published!
Ryan DeBeasi is a a software engineer, writer, and speaker living just north of Boston. He helps businesses solve problems using modern web technologies and … More about Ryan
DeBeasi …
Design systems can improve usability, but they can also limit creativity or fall out of sync with actual products. In this article, we’ll explore how designers and developers can create more robust design systems by building a culture of collaboration.
Design systems can be incredibly helpful. They provide reusable elements and guidelines for building a consistent “look and feel” across products. As a result, users can take what they learned from one product and apply it to another. Similarly, teams can roll out well-tested patterns for navigation or reviews, making products more trustworthy. Effective design systems solve boring problems in a repeatable way so that developers and designers can focus on solving novel problems.
Yet when someone uses the term “design system” in a meeting, I’m never quite sure what reaction to expect. I’ve seen curiosity and excitement about trying a new way of working, but I’ve also seen frustration and concern at the idea of a system limiting designers’ creativity. Some designers argue that design systems sap creativity, or that they are solutions in search of a problem. Design systems can fragment over time, causing teams to stop using them.
Design systems aren’t going away, though. Just 15% of organizations lacked a design system in 2018, according to one survey. That’s down from 28% the previous year. Some teams use large, general-purpose design systems such as Google’s Material Design, while others use smaller, more bespoke systems such as REI’s Cedar and Mozilla’s Protocol.
Design systems should empower teams, not limit them. For that to happen, we need to start thinking more holistically. A design system isn’t just code, or designs, or documentation. It’s all of these things, plus relationships between the people who make the system and the people who use it. It includes not just CSS files and Sketch documents, but also trust, communication, and shared ownership. As it turns out, there’s a whole field of study dedicated to exploring systems like these.
In REI’s Cedar Design System, icons are tailored to the company’s outdoor gear business. The snowflake icon indicates ski and snowboard services, and the ruler icon indicates a size chart. (Large preview)
The Big Picture
A 1960 paper titled “Socio-technical systems” explored the interactions among technology, humans, and the larger environment in which they exist. Enid Mumford explained that researchers began by investigating how to build better relationships between managers and employees, but by the 1980s, they were focused on making work more efficient and cost-effective. In 2011, Gordon Baxter and Ian Sommerville wrote that this research helped inspire user-centered design, and that there’s a lot of work left to do.
Baxter and Sommerville argued that today, there is still a tension between “humanistic” research, which focuses on employees’ quality of life, and “managerial” research, which focuses on their productivity. They also explained that it’s important to consider both technology and human interactions: “system performance relies on the joint optimization of the technical and social subsystems.”
I’d argue that design systems are socio-technical systems. They involve interactions between the people who create the system, the people who create products using the system, and the end users who interact with these products. They also evoke the same tension between efficiency and humanism that Baxter and Sommerville saw.
Design systems aren’t composed just of images and code; they involve conversations among designers, developers, product managers, CEOs, and random people on GitHub. These interactions occur in various contexts — a company, an open-source community, a home — and they happen across cultures and organizational boundaries. Building a team can mean bringing together people from disciplines such as animation, sound design, data visualization, haptics, and copywriting. Creating a successful design system requires equal parts of technical expertise and soft skills.
And yet, peruse design or engineering news aggregators and you’re likely to see a distinct focus on that “technical subsystem” — code and tools, rather than people and conversations. Which creative tool is the best at keeping track of design tokens? What JavaScript technologies should be used for building reusable components — React, web components, or something else? Which build tool is best?
The answer to these questions is, of course, “it depends!” Who will design, build, and use the system? What are their needs? What constraints are they operating under? What tools and technologies are they comfortable with? What do they want to learn?
To answer these sorts of questions, Baxter and Sommerville recommend two types of activities:
Sensitisation and awareness activities Learning about the varied people who will create and participate in the system, and sharing that information far and wide.
Constructive engagement Communicating across roles, building prototypes, and considering both the technical and social parts of the system.
Digging In
In early 2019, I was part of a team — let’s call them “team blue” — that was building a design system for a large organization. I facilitated informal chats with this team and “team green”, which was using the design system to build a web application. Every couple of weeks, we got all the developers and designers together around a table and talked about what we were building and what problems we were trying to solve. These chats were our “sensitization and awareness activities.”
We didn’t have permission to make our design system public, so we did the next best thing: we treated it like a small open-source project within the organization. We put the code in a repository that both teams could access and asked for contributions. Team blue was responsible for reviewing and approving these contributions, but anyone on either team could contribute. Team blue was also building an application of their own, so in a sense, they were both users and custodians of the design system.
These interactions helped the teams build better products, but just as importantly, they established trust between the teams. Team blue learned that folks were using the system thoughtfully and building clever new ideas on top of it. Team green learned that the system really was tailored to their needs, so they could work with it instead of against it. Baxter and Sommerville might call this work “constructive engagement.”
We found that both teams were under pressure to learn new technologies and deliver a complete product quickly. In other words, they were already operating under a pretty considerable cognitive load. As a result, the two teams agreed to focus on making the system easy to use. That meant sidestepping the whole web components debate, focusing mostly on CSS, and ensuring that our documentation was clear and friendly.
Microsoft’s Fluent Design System targets four very different platforms. (Large preview)
Putting It All Together
Organizations of all sizes create reusable design elements to help teams build more consistent, elegant applications. Different organizations’ needs and dynamics are expressed in their design systems. Here are just a few examples:
Google’s Material Design has several implementations in different frameworks and languages. It’s used by a variety of people inside and outside of Google, so it has comprehensive documentation and a variety of toolkits for design apps.
Microsoft’s Fluent Design System targets four very different platforms. Like Material, it includes toolkits for UX designers and comprehensive documentation.
Mozilla’s Protocol is implemented in Sass and vanilla JavaScript. It has a strong focus on internationalization. Alex Gibson says that this system helps Mozilla “create on-brand web pages at a faster pace with less repetitive manual work.”
REI’s Cedar is built with Vue.js components and can’t be used with other JavaScript frameworks. Cedar is used primarily by REI’s internal developers and is closely tied to the company’s brand. The design system’s code is open source, but its fonts are not.
Red Hat’s PatternFly was created to provide a consistent user experience across the company’s cloud platform products, so it has a relatively high information density and includes a variety of data visualization components. The PatternFly team recently switched from Angular to React after some experimentation with web components. PatternFly also includes a JavaScript-agnostic implementation using HTML and CSS. (Full disclosure: I’m a former Red Hatter.)
Systems like these are consistent and reliable because people from different teams and roles worked together to build them. These systems solve real problems. They’re not the result of developers trying to impose their will upon designers or vice-versa.
Josh Mateo and Brendon Manwaring explain that Spotify’s designers “see their role as core contributors and co-authors of a shared system — one that they have ownership of.” Mina Markham describes herself as “the translator between engineering and design” on the Pantsuit design system. Jina Anne digs into the team dynamics and user research behind design systems: “Spoiler alert! You’re going to need more than just designers.”
Let’s Build Some Stuff!
Now that we’ve gone through research and some examples, let’s talk about how to build a new design system. Start by talking to people. Figure out who will be using and contributing to your design system. These people will probably span a variety of disciplines — design, development, product management, business, and the like. Learn about people’s needs and goals, and ask them to share what they’re working on. Consider planning an informal meeting with snacks, coffee, or tea to create a welcoming atmosphere. Establish regular communication with these folks. That might mean joining a shared chat room or scheduling regular meetings. Keep the tone casual and friendly, and focus on listening.
As you talk about what you’re working on, look for common problems and goals. You might find that teams need to display large amounts of data, so they’re investigating tools for displaying tables and generating reports. Prioritize solutions for these problems.
Look also for repeated patterns and variations on similar themes. You might find that buttons and login forms look a bit different across teams. What’s the significance of these variations? What variations are intentional — for example, a primary button versus a secondary button — and what variations have happened by accident? Your design system can name and catalog the intentional patterns and variations, and it can eliminate the “accidental” variations.
IBM’s Carbon Design System lists all the variations of its components. (Large preview)
The goal here is to establish a rapid feedback loop with people who are using the design system. Faster feedback and smaller iterations can help avoid going too far in the wrong direction and having to dramatically change course. P.J. Onori calls these sudden, large changes “thrash.” He says that some thrash is good — it’s a sign that you’re learning and responding to change — but that too much can be disruptive. “You shouldn’t fear thrash,” he says, “but you need to know when it’s useful and how to help mitigate its downsides. One of the best [ways] to mitigate the downsides of thrash is to start small — with everything.”
Consider starting small by setting up a few basic elements:
A version control system to store your code. GitHub, GitLab, and Bitbucket are all great options here. Make sure that everyone who uses the system can access the code and propose changes. If possible, consider making the code open source to reach the widest possible audience.
CSS code to implement the system. Use Sass variables or CSS custom properties to store “design tokens” — common values such as widths and colors.
A package.json file that defines how applications can build and install the design system.
HTML documentation that demonstrates how to use the design system, ideally using the system’s own CSS.
The node-sass documentation for the CSS framework Bulma describes these steps in a bit more detail. You can skip installing and importing Bulma if you’d like to start from scratch, or you can include it if you’d like to start off with some of the basics in place.
You might have noticed that I didn’t mention anything about JavaScript here. You might want to add this element eventually, but you don’t need it to get started. It’s easy to go down a rabbit hole researching the best and newest JavaScript tools, and getting lost in this research can make it harder to get started. For example, “5 Reasons Web Components Are Perfect For Design Systems” and “Why I Don’t Use Web Components” both make valid points, but only you can decide what tools are right for your system. Starting with just CSS and HTML lets you gather real-world feedback that will help you make this decision when the time comes.
As you release new versions of the system, update your system’s version number to indicate what has changed. Use semantic versioning to indicate what’s changed with a number like “1.4.0.” Increment the last number for bug fixes, the middle number for new features, and the first number for big, disruptive changes. Keep communicating with the folks who use the design system, invite feedback and contributions, and make small improvements as you go. This collaborative, iterative way of working can help minimize “thrash” and establish a sense of shared ownership.
Finally, consider publishing your design system as a package on npm so that developers can use it by running the command npm install your-design-system. By default, npm packages are public, but you can also publish a private package, publish the package to a private registry, or ask developers to install the package directly from a version control system. Using a package repository will make it easier to discover and install updates, but installing directly from version control can be an easy short-term solution to help teams get started.
If you’re interested in learning more about the engineering side of things, Katie Sylor-Miller’s Building Your Design System provides a fantastic deep dive. (Full disclosure: I’ve worked with Katie.)
Wrapping Up
Design systems are made up of code, designs, and documentation as well as relationships, communication, and mutual trust. In other words, they’re socio-technical systems. To build a design system, don’t start by writing code and choosing tools; start by talking to the people who will use the system. Learn about their needs and constraints, and help them solve problems. When making technical, design, or strategy decisions, consider these people’s needs over the theoretically “best” way to do things. Start small, iterate, and communicate as you go. Keep your system as simple as possible to minimize thrash, and invite feedback and contributions to establish a sense of shared ownership.
By giving equal weight to engineering and interpersonal considerations, we can get the benefits of design systems while avoiding the pitfalls. We can work in a way that’s efficient and humane; we don’t have to choose one over the other. We can empower teams rather than limiting them. Empowered teams ultimately help us better serve our users — which, after all, is why we’re here in the first place.
The A-Z guide for operating your design system team
Measure how people are using (or not using) your design system
There are two groups who need to adopt your design system: designers who use UI Kits and engineers who use a code library such as React. Design adoption is easy — just swap out the UI Kit and voila. However, code that is even 1 day old comes with technical constraints that make it hard to just flip a switch and expect all engineers to use it overnight.
To measure adoption at SurveyMonkey, we plot every product team on a 5-point color scale:
Red: Team does not know we have a system
Orange: Team has not adopted any part of the system
Yellow: Team has prioritized adopting the system to their roadmap
Green: Team is using the design language but not the code
Blue: Team is using both our design language and the code
Get your engineers involved upfront to foster healthy adoption. Design systems solve a design problem, but with an engineering solution.
Pilot new releases to a small group of beta testers
A small change to any component could break the kits that your adopters are using and require them to make a change on their end to support it. This can get really taxing over time and can get expensive as things scale. To avoid this, we always ship big releases to a small group of early adopters first. Then we learn from them before releasing to everyone.
Some things we’ve learned early on was that our naming conventions were not clear and that some components needed more robust variants. If we had not caught those kinds of small — yet breaking — things upfront we would have ran the risk of creating more work for our adopting teams when we asked them to upgrade to a new version.
Your official criteria for adding new things to the system
We organize by design tokens and UI components, and we carefully curate what gets added so that the wrong parts do not get inducted without meeting every checkmark in our induction criteria. Our canon is the truth and how we distinguish between a sanctioned decision versus a pattern that is being circulated unofficially. Tokens and components must both be available in Sketch and code before they are inducted so that designers and engineers are always working from the same set of tools. We also look at things like if it’s an industry best practice, is it context agnostic, has it been proven in production, etc..
Be strict curators of your canon and communicate how your team decides when and why tokens or components are or are not ready to be inducted.
Design systems solve a design problem, but with an engineering solution.
How you communicate and deliver changes to your teams
You can spend months crafting brilliant symbols in Sketch, writing guidelines, and partnering with engineers to build everything in code. But have you stopped to think about what the experience is like for people using the system? How easy is for them to receive updates? Is it a manual process or do changes get synced automatically?
Good distribution starts with great encapsulation.
Most modern design tools have disruption tools built right into them. But how might a Sketch plugin replace your need to use a Sketch Library that has to be manually download each update? For engineers, how might you improve their need to copy-and-paste raw values and/or HTML? Instead of 50 lines of HTML, how might you encapsulate it down to 1 line of code? Most modern tech libraries are built with this philosophy of encapsulation (i.e. React and Web Components).
The delicate balance of everything that makes up your design system
Just like a rainforest ecosystem, every part of a design system plays an important role and it all needs to work effectively together to keep everything running smoothly. And the design system ecosystem reaches far beyond UI components. We like to think that our design system ecosystem contains these 4 systems inside it — all of which need to work together to keep the system healthy:
Distribution: Automating release and communication of updates (Deploying, npm, change logs, Slack)
Tooling: Streamline how people use the system (Sketch plugins, VScode plugins, prototyping tools, etc.)
Education: Helping people use the system better (Docs, guidelines, onboard training)
System: The design language and UI components (The fun stuff!)
Imagine dropping a polar bear into the middle of a rainforest. It’ll wreak havoc on the wildlife around it, and the polar bear will suffer too. We think of our system just like that. If you introduce things into your design system that don’t make sense in the larger context, the system will slowly deteriorate.
Each addition to the system is a vow to maintain it
Who doesn’t celebrate when they ship a new component and move onto something else? It’s tempting to never look back, but it’s important to remember that every time you add more features to your design system, your commitments and responsibilities increase. If you’re not careful, you might bite off more than you can chew, and all of a sudden you only have time to maintain the core system — and no time to grow the system further.
Before you add anything new, think about the long-term cost to support. As your system takes on more responsibility, grow your team at a relative speed.
Be the reason that other teams break out of their silos and work together
Your design system sits central to everyone and gives you a holistic view of the entire product experience. You have the powerful advantage to spot when people are working on similar problems, and bring them together to solve it together — when otherwise they might not have looked up to notice the opportunity. I call these missed opportunities “the seams” and your design system is the glue that holds the seams together.
Your design system is the glue that holds the seams together.
Be clear and specific about how others can contribute
A design system shouldn’t exist in a vacuum, so it’s important to set up a process for accepting help and contributions from the people using it — similar to an open-source model. But not just any help. Be crystal clear about what your team does and doesn’t need help with, and establish guidelines for contributing. Our design systems team wasn’t ready to accept outside contributions until we did a ton of work upfront to set a good foundation. Once we were ready, we created a roadmap and a process that made it clear how to be an effective contributor.
Disrupt your adopters’ process as little as possible
One of our design system’s guiding principles is to disrupt the workflow of our teams as little as possible. Aim to fit into their workflow instead of asking them to fit into yours. Everyone works differently and every team operates differently. It’s not your role to determine their destiny for them. Instead, it’s your role to listen to how they work and design your system to accommodate so it can be invisible during their process.
All the small tasks you do today can become a full-time job later
It’s no exaggeration to say that there’s a lot of work to do on design systems. Every small responsibility you’re doing today has the potential to be a full-time job later on. Small tasks today are easy to juggle until they balloon in scope as your system scales. Being blindsided by increasing scope is a shock to the operation of your system. Prioritization becomes your key ally in recovering your operations — decide which tasks you can drop until you have more people on your team.
Document and share the knowledge you gain from being centralized
Being central to the process of so many designers and engineers means you have a wealth of undocumented knowledge brewing around your head. That sounds great if you’re okay being the gatekeeper, but documenting the knowledge in your head is very powerful and can empower your entire organization to do better work.
Find a process to document your knowledge in an informal way and see what your team finds valuable.Share it with your team until your system is ready to formalize it inside your documentation and guidelines.
Design files are just a static representation of your design system — not the design system
As we’re moving toward modern technology stacks like React, changes can automatically sync across your entire ecosystem (docs, Sketch, and code). Philosophically, that means every UI component in your system exists everywhere, together.
First, make sure your system’s source of truth is the code. Build a doc site that renders that living code right inside its examples. Build tooling, like a Sketch plugin, that automates converting your coded components to Sketch symbols so that your team doesn’t have to manually draw your UI Kits by hand. This helps avoid bugs downstream due to human error.
Prove the value of your design system by measuring its impact
Early-stage design systems teams measure different things than mature ones. Early on, you focus on delivering what you promised: UI components. At this stage, you’re measuring how many tangible things your team is able to produce and deliver — like your UI kit or new components. But once you’ve done that, you need to start measuring the impact and value your design system brings to your organization..
The metrics you measure at this stage should align with the metrics your company already cares about. For example, our engineering teams already measure “time to close a PR”. Separately, we keep track of which teams use our design system, and which teams don’t. When we map that data together, we can show that engineering teams that use our design system take less time to close a PR. This is a win-win — it helps us prove the value of our design system, and it gives an incentive to engineering teams to adopt our design system to increase their efficiency.
Find out what your design and engineering departments are measuring and segment the data.
Your system doesn’t get dedicated resourcing because it hasn’t solved a business need
No one is listening if you pitch your system as solving design problems (i.e. improving color and typography). Even if you pitch that it will improve the customer experience, leading to more money downstream. While that may be true, it’s usually not how the business thinks about priorities.
Instead, start by identifying a need that the business has and propose that you can solve that need with a design system.What they care about is that you’re going to solve that need, not necessarily that you are going to do it by spinning up a design system.
At SurveyMonkey, our business need was to apply our new brand throughout the entire product as quickly as possible. At another company, the legal team had the business need to ensure that we were meeting accessibility guidelines across the site — and we promised to solve that need with a design system.
Identify a need that the business has and propose that you can solve that need with a design system
Educate and train teams on how to adopt your design system
One day you’ll get to a point when the foundation is stable and the amount of new components being added has slowed down drastically. Add an uptick in adoption to that mix and your design system’s bottleneck will no longer be that a pattern doesn’t exist, yet. The new bottlenecks will be the unknowns of how to get started and how to use the system correctly.
To solve that, you need to invest in training at the right time — not too early when shipping new components is more important, but not so late that you’re creating huge barriers for getting more teams to start adopting your design system.
Your customers are your coworkers
Early design systems are usually developed as a grassroots effort by Product Designers, who naturally bring their customer-centric design process with them. As a result, I see design systems teams fall into the trap of building their design system for customers, instead of building it for the designers, engineers, and PMs who are actually using it to craft products for customers downstream.
What ultimately gets shipped to production is not your responsibility. Your responsibility is to build a design system that improves the productivity and relationships of the people using the system — your coworkers — and to help them make great decisions as quickly as possible.
Your company’s live app or product is not your priority
The design systems team shouldn’t be the gatekeeper of what ships to production. What ships to customers is your product design team’s responsibility. If you’re straddling the line and policing designs right before they ship, you’re already too late. You’re focused on the wrong part of the process. As more teams use your design system, it becomes too time-intensive to watch every release to make sure everything that gets shipped is using your system correctly and is consistent with how others are using it.
Instead, focus your energy on proactive education and training. Make sure people know their resources before they start designing or building anything. If you educate people on how to effectively use the design system, they’re more likely to make better decisions when they work on future projects.
Your design system bridges the gap between disciplines
Your design system’s ability to bridge gaps between disciplines is your greatest superpower. Your design system reaches far beyond one-on-one collaboration between a designer and an engineer. It has the potential to nurture the relationships between every designer and engineer at your company by empowering everyone to speak a shared language.
Set up repeatable processes and guidelines that scale your team’s capabilities
Relative to the rest of the company, design system teams are small — yet they’re tasked to support an entire company. The math doesn’t add up, and we often see 1-person design system teams supporting 100 people using the system. If only a couple of those people ask you to pair code or design, that could take up an entire week of your team’s time.
To combat this, you have to scale your team’s capabilities so that your team doesn’t have to be in the room for people to make a decision. If done correctly, you can scale a single skillset (such as Visual Design) from 1 person to unlimited.
Systems thinking is your team’s superpower
Traditionally, product organizations are made up of three roles: Product, Engineering, and Design. As a result, you often design system teams made up of these same roles. But not just any engineer or designer will succeed on a design systems team — your greatest assets are engineers and designers with a knack for improving the productivity of others around them by solving problems systematically, on a holistic level.
Engineering by design, design by engineering
There’s an interesting opportunity when your design system sits central to everything: unify everything! Design, code, process — you name it and we’ll unify it.
How might we, as a design systems community, unify disciplines and empower them to work better, together. We have the opportunity to blend the way code and design work together by building tools that unify those processes. We can get designers working more like engineers by introducing version control. Or build a prototyping sandbox that allows designers to prototype in code — without writing code.
Your design systems ability to bridge gaps between disciplines is a superpower
Have a clear vision of what you want your design system to be
Since your system builds bridges between disciplines (design, engineering, and product) everyone will have different expectations of the system. That means that right out of the gate, people might assume that your system is everything, for everyone. Lofty expectations like this are dangerous, because they’re unrealistic.
Establish a strong vision and evangelize that to the entire product organization. Explain what your system is , and more importantly what it is not.
That moment of realization: “Have I become a PM?”
As the creator of a design system, you end up doing whatever it takes to keep the system alive. As your system scales, you may notice you’re acting more like a Program Manager than before. Your day-to-day shifts from hands-on work to managing operations and coordinating. Project plans, roadmaps, timelines, synthesizing feedback — oh my, did I just become a PM?
Get really good at “X’ing” things out and saying no.
Everyone will come to you with the next big idea for your system. They’ll ask you to take on a collection of new components by a certain date to help them meet their own deadlines. It’s easy to say yes because it’s a quick way to prove your system’s value early on, but it’s important to set boundaries. Be careful not to commit too much time solving the needs of single team. Focus on the holistic view and prioritize work that benefits everyone — not just a single team or a single project.
You happen to your design system
Your design system starts with you showing up and being proactive about grassrooting it. Even if you can’t do it alone, it still takes you to inspire and lead others to believe that it’s a cause worth supporting. Don’t wait for someone to hand you the keys to the design system. Your passion and hard work could be what it takes to grow your system into a dedicated design system team that wins!
It will feel like a zoo because it is a zoo
Grassrooting a system and watching it grow from a tiny seed into its own dedicated team is quite the journey. It will feel like order and calm is just around the corner, but around each corner lies new challenges. That’s okay! Embrace the chaos and see where it takes you. The best innovations often come from chaos. Trust your vision, take it one step at a time, and rally your team around creating order from the chaos as you go.
If you’re just getting started with creating your own design system, a little visual inspiration can go a long way. That’s why in this post, we’ve gathered the 10 best design systems from world-famous brands.
A design system helps everyone in your business to maintain brand consistency. It’s a collection of guidelines that explains how your branding assets should be used in everyday communication and marketing efforts.
A design system usually consists of general brand guidelines, color usage, brand tone and voice, typography, patterns, and any other visual element that helps convey your brand principles. Use them as an inspiration and a learning material to help you create a cohesive design system for your own business and brand.
1. Material
Material is a modern design system developed by Google. The design system itself is a treasure trove of useful guides and helpful tools that can be used by app developers to design an app that adheres to Material style as well as anyone else that wants to create a modern and trendy design. You will find a color palette picker, typography guidelines, icon design best practices, the ability to create a dark material theme, and much more.
2. Fluent
The Fluent design system was developed by Microsoft and it aims to create simplicity and coherence through open design systems developed for all the platforms. It focuses on uniting the fundamentals of principled design, tech innovation, and customer needs. The system is based around five key components: light, depth, motion, material, and scale. It also lays out guidelines for developing apps for Windows, Android, and iOS devices.
3. Shopify Polaris
Shopify Polaris was developed so all Shopify merchants could enjoy a great experience and benefit from a beautiful store design. This design system has guidelines for crafting every part of the Shopify experience; from admin screens down to product experience and various apps for Shopify. It covers content, components, design, and pattern guidelines. You will also find helpful links to third-party tools that can serve as an inspiration or help you learn how to effectively design for Shopify.
4. Mailchimp
Mailchimp is always cited as one of the best examples for a detailed company brand tone and voice guide but they also have a pretty thorough design system that is focused on a pattern library. You can find detailed guidelines for colors, buttons, alert messages, and every other aspect of their marketing platform. What’s more, the guidelines have plenty of examples and explanation that break down the most important concepts.
5. Atlassian
Atlassian is an Australian software company best known for their issue tracking application, Jira. Their design system describes not only how to use their logo, brand colors, fonts, and other design elements but they also let their brand personality shine through. With color names such as Dragon’s Blood and Herky Jerky, it’s easy to see why they describe their style as bold, optimistic, and practical with a wink.
6. Apple
Apple’s design system is meant to facilitate the design of apps and Apple’s suite of products but there’s plenty to learn and admire in their style guide. For starters, you can download the SF icons which are meant to complement the system font for Apple’s devices. You will also find guidelines and instructions for UX design, making apps more accessible, and accessories.
7. IBM Design Language
The guiding principle behind IBM’s design system is building bonds. Their design system goes beyond documenting their style guidelines and brand assets usage; they also share their philosophy as well as a gallery full of examples of their design system in action. The design system itself covers colors, typography, logos, icons, pictograms, photography, and motion.
8. AirBnB
AirBnB shares a comprehensive overview of their design system through a series of articles that go in-depth about the decisions behind each design choice as well as practical application examples and lessons learned from it. The main characteristic of their design language is that each component can live on its own as a separate entity and even evolve further while also being a part of a larger cohesive unit, comparing their design system to a living, breathing organism.
9. Uber
Uber describes its brand as a bold, new brand and their design system does an excellent job of portraying those principles. The design system covers the entirety of their brand visuals, from logo usage to color, composition, and even photography, and motion. Uber’s design system revolves around elegant simplicity and subtly recreating the famous U wherever possible.
10. Lightning Design System
Lastly, the Lightning Design System was developed by Salesforce as a way to keep everything unified and easy to access for anyone designing for the platform. Instead of focusing on pixels, the design system focuses on application logic, user experience, interactions, and flows. You will find in-depth guidelines and examples that cover not only design guidelines but also accessibility issues and component blueprints.
Hearing all the hype about design systems can give you the impression that you just create a design system and *poof* everything comes together. Maybe you write a blog post about it and then you never have to think about design systems again.
I can tell you that that’s far from reality. A design system is a process, and a long one at that. It’s not uncommon to “fail” in your first (or second or third) attempt. How do I know? Because that’s what happened when I set out to create a design system at Instacart.
It took three tries over the course of a few years to build a design system that worked for our teams. And after we found something that worked, we were still fine-tuning it because a design system is a living, breathing thing. There’s no one-and-done.
So whether you’re already off to the races or just starting to think about how to mobilize your design system team, here are some key things to remember along the way.
Treat it like a product
Our design system didn’t truly come together until we saw it as a product with a full design process.
We had to approach it with the mindset of — How would we go about building this if it was anything else we’re working on? If you want to create an effective design system, you can’t treat it like a side project.
Leave breathing room
Your system should be opinionated when possible, but it also needs to be flexible. The point of a design system is to help scale and empower, not lock in.
Thinking about things systematically is always healthy and leads to a better product… until it doesn’t.
For example, during my time at Instacart, we had a new shift in demand from brands on our platform. They wanted to give users coupons, which required new kinds of controls on every product card.
We put meticulous thought into the product cards (they are the lifeblood of the product after all). This new direction couldn’t be an opportunity for us to dig our heels in and oppose. We needed to shift with our business and the ability to rethink components was necessary.
A.B.U. (Always Be Updating)
The biggest mistake you can make when scaling a design system is thinking that you’re done. You can always do something better, and new requirements are always coming out. You need to be in it for the long haul.
Standards change. For instance, Apple’s Human Interface Guidelines gained some new updates this year, and it will probably change again next year. You need to be constantly updating to stay on top of user expectations.
You don’t always need a dedicated team
The problem with all the hype surrounding design systems is that it makes it seem like you need to do it a certain way to achieve results. One assumption is that you need to have a dedicated team. Having a dedicated design system team is a nice thing to have when building a system from scratch, but it’s not necessary.
But, to my previous point, building a system is not a small side project. So if you can’t have a dedicated team, treat it like a product and figure out how many people can commit X amount of hours over the next few months to build it. It just depends on your needs and the size of your organization.
At Abstract, we still have a small design team, so we all contribute to the system. It allows the system to get the resources to grow and change while we keep working on the next exciting update for our platform ?.
Define the design principles for your design system
When you’re creating a design system, it helps to ask yourself: Why are you doing this in the first place? What are the major goals that need to come out of this?
Talking about the goals of your company and your product will go a long way in helping you figure out how your design system should work. The answers to those questions will become the North Star of your system, guiding the decisions you make, and helping you solve challenges that pop up along the way.
Don’t work in isolation (tempting as that can be)
Building a design system is a masterclass in collaboration. It’s important that other teams build the system with you. Getting input and letting people into that process helps us challenge and overcome assumptions we didn’t even realize we’re making.
You need to be as collaborative as possible because so many different people use a design system. What makes sense for you is not always going to be what makes sense for someone else with a different perspective and skillset.
And, at the end of the day, if no one wants or can use your design system, then why did you spend all that time creating it? You might as well be as open as possible to other people’s viewpoints to build a design system they actually want to use.
Measuring the success of a design system looks different for everyone
How do you know if your design system is successful? It’s tempting to make a CVS receipt–length list of key performance indicators (KPIs) you want to hit.
But, in my experience, it’s best to keep it simple. When measuring the success of your system, ask yourself:
Is it helping or hurting us?
Are the other folks at my company using what I built or are they choosing to do something custom?
Is the system being talked about socially, or is it living in obscurity?
Take time to reflect
Creating a design system is a process. And that means you’re always learning as you go, especially when you go down the “wrong” path. This is where reflection comes in.
At Instacart, we didn’t really start succeeding until we started reflecting together as a team, figuring out what was working, what wasn’t working, and why. Working out in the open is the only way you’re going to figure those things out. You work with smart people. Include them.
The 2019 Design Systems Survey is intended to illuminate how design systems are created, used, and maintained. Design systems have the ability to solve real-life problems by establishing consistency in design and code, promoting efficiency when creating products, communicating usage guidance, encouraging reuse instead of rework, increasing the accessibility and usability of digital properties, and so much more.
For the second year in a row, Sparkbox, a web design and development firm, has conducted this survey to learn more about both the challenges and benefits of building and using design systems. By analyzing the reflections of in-house teams who use a design system and agencies who’ve helped organizations build new or maintain existing design systems, we look to inform those who want to build or improve their own.
This survey had 256 responses comprised of two respondent types:
In-house teams who use a design system for their organization
Agencies who build or contribute to design systems for clients
The two respondent types were asked different sets of questions with some common questions. As each audience brings different expertise to the survey, we will be acknowledging both types of responses.
This survey was shared across social media, Slack channels, at conferences attended by Sparkbox, and was emailed directly to web design and development professionals.
These 148 in-house team respondents came from various company sizes ranging from a couple of team members to over 10,000 employees. Industries include e-commerce, finance, healthcare, advertising and marketing, education, and many others.
The in-house team survey respondents came from various job disciplines. 49% are designers or user experience professionals, 39% are developers, 8% are managers, and 4% are from other job disciplines.
In-house Respondents Breakdown
Designers and UX 49%
Developers 39%
Managers 8%
Other 4%
92% of the in-house team respondents stated that their organization is actively maintaining its design system. When asked who is primarily responsible for the design system, 50% said designers or user experience professionals, 30% said developers, 11% said a cross-functional team, 4% said project managers, and 5% said others.
Of these 108 agency respondents, 81% work at firms with 200 or fewer employees. These agency respondents include people from traditional advertising or digital-only agencies, IT professional services firms, small studios, and freelancers.
The agency survey respondents came from various job disciplines. 51% are designers or user experience professionals, 42% are developers, and 7% are in management disciplines.
In total, this survey captured 92% of responses from individuals in the design (38%), user experience (13%), or development (41%) fields. Only 8% were in product/project management, marketing, strategy, management or other disciplines combined.
Over 70% of the in-house respondents and 65% of agency respondents said they first learned about design systems by reading articles about design systems. And 77% of in-house respondents and 70% of agency respondents stated reading articles about design systems is the most helpful resource for understanding design systems.
In this survey, in-house and agency respondents were asked what was contained in the design systems they or their clients use. Over half of the respondents said their design system included the following elements.
Top Design System Features
163 In-House and Agency Responses Respondents could select multiple from 19 options and fill out a response to “other”
Color System92%
Typography System89%
Form Components88%
Navigation Components 79%
CSS Code 70%
HTML Code 69%
Usage Guidelines 69%
Grid System 68%
Spacing System 66%
Layout System 66%
Content Blocks 63%
Brand Guidelines 62%
Design Files 59%
JavaScript Code 56%
Accessibility Guidelines 55%
Framework-specific Components 53%
When in-house teams were asked which parts of the design system were most useful to their day-to-day work, the responses varied based on the discipline of each individual. The following shows the top 5 responses for designers/user experience professionals and developers. Color system and typography system ranked in the top 5 for day-to-day usage by both job types.
Designer or User Experience
Color System
Typography System
Layout System tie
Form Components tie
Design Files tie
Developer
Color System
Spacing System tie
Framework-Specific Components tie
Typography System
Usage Guidelines
When asked how they deliver a design system to a consumer, two-thirds of in-house respondents said they distribute the design system via automation or integration into the codebase, while just under a quarter ask developers to copy/paste or download code from a standalone website.
Q: How is your design system delivered to the consumers of the design system?
108 In-House Responses Respondents were asked to select one answer
In an external codebase and consumed via package manager
36%
On a standalone documentation site where users primarily copy paste, or download files
24%
Included in the main codebase
16%
In an external codebase and consumed by the main codebase’s build pipeline
14%
I am not sure
6%
Other
4%
In an external codebase and consumed via package manager
On a standalone documentation site where users primarily copy paste, or download files
Included in the main codebase
In an external codebase and consumed by the main codebase’s build pipeline
Along with the growing adoption of design systems, there are dozens of tools on the market to help organizations build and maintain their design system. In-house and agency respondents were asked to share what design system tools they have used, and they answered with the following:
Top Design System Tools
108 In-House Responses Respondents were asked to select one answer
Storybook34%
InVision Design System Manager32%
Pattern Lab23%
UXPin 16%
Fractal 10%
KSS 8%
A Homegrown Solution 7%
zeroheight 6%
Sketch 5%
Vue 4%
Abstract 4%
Figma 4%
Survey respondents were invited to share whether they have a favorite tool and why. Top reasons for why they preferred a tool included specific features or compatibility, ease of use, collaboration abilities, speed and performance, and display and showcase ability. Storybook and Pattern Lab were the top tools among developers while Invision Design System Manager and Storybook were the top tools among designers or user experience professionals.
Designer or User Experience
146 Responses
InVision Design System Manager 60 responses
Storybook 38 responses
Pattern Lab 33 responses
UXPin 31 responses
Fractal 11 responses
Developer
117 Responses
Storybook 47 responses
Pattern Lab 26 responses
InVision Design System Manager 18 responses
Fractal 12 responses
UXPin 11 responses
The top motivating factors for in-house respondents included the reusability of code, efficiency in development design, and consistency in UX/UI and in development. This matches last year’s survey findings.
Q: How strongly did each of the following factors motivate your organization to establish a design system?
108 In-House Responses Respondents were asked to rate on a 1 to 5 scale where 1 = Not a motivator and 5 = A strong motivator
1
2
3
4
5
Code reusability
5%
3%
9%
16%
67%
Increased efficiency in design
1%
3%
13%
21%
63%
Increased efficiency in development
2%
2%
10%
25%
61%
UX/UI consistency
0%
3%
8%
28%
61%
Maintaining brand standards
8%
6%
24%
24%
38%
Accessibility compliance
16%
13%
23%
22%
25%
Rapid prototyping
13%
15%
24%
31%
16%
Code reusability
5%
3%
9%
16%
67%
Increased efficiency in design
1%
3%
13%
21%
63%
Increased efficiency in development
2%
2%
10%
25%
61%
UX/UI consistency
3%
8%
28%
61%
Maintaining brand standards
8%
6%
24%
24%
38%
Accessibility compliance
16%
13%
23%
22%
25%
Rapid prototyping
13%
15%
24%
31%
16%
0%
25%
50%
75%
100%
When agencies suggest a design system to clients, the top reasons mirror what motivated in-house teams to consider a design system: consistency, the ability to reuse code, and greater efficiency in their work.
Q: What about a client engagement leads you to suggest or not suggest a design system?
79 Agency Responses Respondents were asked to select all that apply
The client struggles with consistency across web properties
58%
The client has many web properties that could all benefit from a unified system
57%
The client needs a more efficient way to work
52%
The client has many contributors to their web properties
38%
The client needs “out of the box” solutions to fill UX/UI developer gaps
33%
We always suggest a design system
30%
We never suggest a design system
8%
Other
8%
The client struggles with consistency across web properties
The client has many web properties that could all benefit from a unified system
The client needs a more efficient way to work
The client has many contributors to their web properties
The client needs “out of the box” solutions to fill UX/UI developer gaps
We always suggest a design system
We never suggest a design system
48 respondents said consistency and 46 respondents mentioned efficiency when in-house teams and agencies were asked to describe the most valuable aspect of having a design system.
When in-house individuals were asked about their biggest concerns as their organization considered implementing a design system, top responses included the following:
adoption and acceptance
buy-in from the team
maintenance and evolution
investing the time needed to build the system
When agencies were asked what they think concerned their clients most about building/having a design system, the most common responses were the following:
the investment required (both cost and time)
the long-term maintenance of the design system
When in-house teams were asked about the biggest challenges of having a design system, common answers included updating the system, getting teams and leaders to see the value of the system, getting everyone to use the system the same way, and not having a dedicated team to maintain the system.
The survey had 71 in-house respondents give reasons why they felt their design system was unsuccessful. The most common reasons were adoption, maintenance, staffing, and lack of an executive champion, mirroring the major challenges of implementing a design system.
Q: If you feel that your organization’s design system was not successful, what were the primary reasons?
71 In-House Responses Respondents were asked to select all that apply
Adoption difficulties
52%
Maintenance difficulties
42%
Staffing difficulties
38%
Lack of an executive champion
35%
Funding difficulties
15%
Other
15%
Lack of an executive champion
In-house teams were also asked what they would do differently if they could go back in time to when they were creating their design system. Some common answers included bringing in more people earlier (such as other developers, technical architects, or executive champions), making different technology/build decisions, and doing better planning.
The 49% of in-house team respondents who ranked their design system as successful follow three commonalities:
Have a dedicated team to maintain the design system
Integrate the design system into the developer workflow
Source at least 50% of work product from the design system
Have a dedicated team to maintain the design system.
20 of 26 in-house respondents with a successful design system answered an open-ended question that both designers and developers were assigned to support the design system in either a part-time or full-time capacity.
More often than not, the list of team members was cross-functional, expanding beyond designers, user experience, and developers to include product owners, copywriters, and managers.
Integrate the design system into the developer workflow.
Of respondents with a successful design system, 79% integrated the design system into the developer’s workflow or tooling. The following are how respondents with successful design system deliver it to the consumers of the design system:
49% deliver their design system by an external codebase and consumed via package
15% deliver their design system by an external codebase and consumed by the main codebase’s pipeline
15% deliver the design system in the main codebase
These delivery models make the design system a way of life for developers.
Source at least 50% of work product from the design system.
Of responders who said they felt their design system was very successful or successful, 62% were sourcing 50% or more of their website from the design system. And of those who perceived their design system as very successful, 63% had over 75% of their web properties sourced from their design system.
As we reflect on the results of this year’s survey, we feel the experiences of in-house teams and agencies shared a common theme: the greatest values of design systems are consistency and efficiency. These two benefits are related. Consistency is not just good for user experience or for design cohesiveness across a brand or brands, but it begets efficiency because there is no need to reinvent the wheel—either in concept or code.
Efficiency suggests speed, and speed can result in time and cost savings. This is the ultimate return on investment for an organization that adopts a design system—freeing up designers and developers to do more innovative work and freeing up budget to pursue organizational growth, product innovations, or other goals.
The 2019 Design Systems Survey is just the start! Sign up and receive one to two emails each month with more information on design systems and other web design and development content right to your inbox.
The 2019 Design Systems Survey is just the start. Sign up and receive one to two emails each moth with more information on design systems and other web design and development content right to your inbox.
