New Logo and Identity for GoDaddy done In-house



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 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.


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.

GoDaddy Design microsite

Logo introduction.
New Logo and Identity for GoDaddy done In-house
New Logo and Identity for GoDaddy done In-house
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.

GoDaddy Design microsite

Color palette.

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.

GoDaddy Design microsite

Headline typography.

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.

GoDaddy Design microsite

New Logo and Identity for GoDaddy done In-house

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.

GoDaddy Design microsite

New Logo and Identity for GoDaddy done In-house
Hand-drawn illustration style.

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.

GoDaddy Design microsite

New Logo and Identity for GoDaddy done In-house
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.

New Logo and Identity for GoDaddy done In-house
Business cards.
New Logo and Identity for GoDaddy done In-house

New Logo and Identity for GoDaddy done In-house

New Logo and Identity for GoDaddy done In-house

New Logo and Identity for GoDaddy done In-house
New Logo and Identity for GoDaddy done In-house
New Logo and Identity for GoDaddy done In-house
New Logo and Identity for GoDaddy done In-house
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 New each year since publication began in 2006

Logo Before & After
Sample Application

Spotted Around the web

Pinned Recent, Big Stories

Curated 3D that is 2L2Q


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.

1 in 5 people in the UK have a long term illness, impairment or disability – and many more have a temporary disability. Designing accessible services is incredibly important from an ethical, reputational and commercial standpoint. For EU government websites and apps, accessibility is also a legal requirement.

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:

A table with contact information in it.

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.

A screenshot of the table form component with the HTML beneath it. The span element is highlighted, and it has the classname of govuk-visually-hidden.

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.

(Here’s a shameless plug for my patterns Day talk on design system documentation earlier this year, if you want to know more about that.)

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.

A red button with the text 'Delete 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.

My colleague, Nick Colley, wrote about the work we did to ensure GOV.UK Design System’s components will work when users change colours on GOV.UK. To ensure we weren’t introducing barriers to our colleagues, we also made it possible to customise colours in the GOV.UK Design System website itself.

Screenshot of the GOV.UK website with green and white text and black background.

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.

Earlier this year, Domino’s pizza was successfully sued by a blind customer after he was unable to order food on their website or mobile app, despite using screen-reading software. And in a recent study carried out by disability equality charity, Scope, 50% of respondents said that they had given up on buying a product because the website, app or in-store machine had accessibility issues.

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:

font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Ubuntu, "Helvetica Neue", Oxygen, Cantarell, sans-serif;

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)


Windows (2000)

Microsoft Sans Serif

Windows (95, NT, Millennium)

MS Sans Serif

Windows (older versions including Windows 3)


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.



Red Hat

Other distros (Arch Linux, Debian, Fedora etc.)

It varies, can be DejaVu Sans, Noto Sans, Liberation Sans etc.

Default sans-serif font in iOS

iOS (9 and newer)

San Francisco

iOS (8 and older)

Helvetica/Helvetica Neue

Default sans-serif font in watchOS


San Francisco Compact

Default sans-serif font in Android

Android (4.0 )


Android (older versions)

Droid Sans


A streamlined workflow for frontend developers

Dominic Nguyen

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 interface code. 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.

? Read the full guide Design Systems for Developers

Design Systems for Developers was 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!


About The Author

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

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.

Grid of icons including stars, a shopping cart, and a snowflake
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.

Screenshot of links to Windows, Web, iOS, and Android documentation
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.
  • Salesforce’s Lightning Design System is a JavaScript-agnostic CSS framework. It can optionally be used alongside the Lightning Component Framework, which includes two JavaScript implementations: one using web components and another using Salesforce’s proprietary Aura framework.
  • 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.)
  • IBM’s Carbon Design System offers implementations in React, Vue, Angular, and vanilla JavaScript as well as a design toolkit for Sketch. The Carbon team is experimenting with web components. (Hat tip to Jonathan Speek for tracking down that repository.)

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.

Screenshot of five different button styles
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.

Further Reading on SmashingMag:

Smashing Editorial(ah, il)


illustrations by Francisco Morales

The A-Z guide for operating your design system team

Mike Dick

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.

IBM Design language

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.

Lightning Design System


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.


Skip to table of contents

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:

  1. In-house teams who use a design system for their organization
  2. 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
  • 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”

  1. Color System92%

  2. Typography System89%

  3. Form Components88%

  1. Navigation Components 79%
  2. CSS Code 70%
  3. HTML Code 69%
  4. Usage Guidelines 69%
  5. Grid System 68%
  6. Spacing System 66%
  7. Layout System 66%
  8. Content Blocks 63%
  9. Brand Guidelines 62%
  10. Design Files 59%
  11. JavaScript Code 56%
  12. Accessibility Guidelines 55%
  13. 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

  1. Color System
  2. Typography System
  3. Layout System tie
  4. Form Components tie
  5. Design Files tie


  1. Color System
  2. Spacing System tie
  3. Framework-Specific Components tie
  4. Typography System
  5. 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

  1. Storybook 34%

  2. InVision Design System Manager32%

  3. Pattern Lab23%

  1. UXPin 16%
  2. Fractal 10%
  3. KSS 8%
  4. A Homegrown Solution 7%
  5. zeroheight 6%
  6. Sketch 5%
  7. Vue 4%
  8. Abstract 4%
  9. 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

  1. InVision Design System Manager 60 responses
  2. Storybook 38 responses
  3. Pattern Lab 33 responses
  4. UXPin 31 responses
  5. Fractal 11 responses


117 Responses

  1. Storybook 47 responses
  2. Pattern Lab 26 responses
  3. InVision Design System Manager 18 responses
  4. Fractal 12 responses
  5. 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%

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%

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:

  1. Have a dedicated team to maintain the design system
  2. Integrate the design system into the developer workflow
  3. 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.

Sparkbox has become an expert in design systems and hopes to continue helping others through writing articles about design systems.

Are you looking for help building, adjusting, or maintaining your design system? Reach out to us for more information on how we can help!

Or are you interested in the full data set of this survey to run your own analysis? Download the CSV file on Dropbox.

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.