Design System Checklist

I just started to create another design system for a client and there are some conceptual questions I need to first think about before I can design the system. I’ve got them in my head and roughly know what to look out for. But up until now, I never wrote those questions down.

Tim Schoch
Nov 16, 2018 · 6 min read

Design Systems Series

This Checklist is Part two of something bigger:
Part I 5 Pillars of a Design System
Part II Design System Checklist
Part III Design System Resources and Links

Today I needed to free up the hard drive in my brain, so here it is: my evolving design system checklist.

Feel free to use and abuse it. ❤️
(Tired of reading? The video of my Talk is at the end)

And if you do so, please leave a feedback on what worked and what’s missing so we can add more important questions to this list as a community.

Pillar 1 — Sell our Design System

Goals

  • What do our stakeholders expect?
  • What are our expectations?
    (How perfect does it have to be? Do these expectations meet?)
  • Who will use this design system?
    (Devs, Agencies, Content Editors, …)
  • Are we designing for multiple products?

Scope

What will we deliver:

  • Principles (Brand values, Purpose, …, Limit them!)
  • Style guide (visual)
  • UX patterns (interactions, best practices, …)
  • HTML/CSS utility classes (typography, colors, buttons, forms, …)
  • Functional components (ready-to-be used in your apps)
  • Copy (wording, tone of voice, …)
  • Icons, illustrations and images
  • Sound and motion library

Stakeholders and Process

  • Which roles do we need on our team to be successful?
  • Which disciplines should be involved in our design process?
    (Business, Product, DevOps, Testing, Support, …)
  • Do we already have the buy-in from our team and stakeholders?
  • What deliverables and deadlines do we need to meet?
  • Will our system already be used in products during the initial development or are we releasing a finished v.1?
  • Who needs to sign off our work and at what steps?
  • What is the road map for our design system and how will it be maintained in the future? (Scope, MVP, Iterate, Extend, …)

Pillar 2 — Research our Design System

Initial Setup

  • Is it a redesign or completely new? (Migrating old applications
    can surface unexpected usages of token CSS-classes)
  • What rules and principles do we follow?
  • Where does the current design work well?
  • What can we improve over the current design?
  • Do we want a strict or loose design system?
  • Where can we draw inspiration from?
    (Well copied > badly invented)
  • Have we defined the most important terms to communicate our design system? (Designers, Devs and Stakeholders must speak the same lingo)

Users

  • Do we have enough insights to understand them? (Journeys, JTBD)
  • What context do our Apps live in?
  • How frequently will they interact with our App?
  • Do they want to use our App?
  • How mature is our audience on our topic?
  • Will our users receive training or start with zero knowledge? (B2E, B2B)
  • Are there standards or APIs our audience expects? (often the case in B2B)
  • What disabilities will we cater for?

Technology

  • What output channels suit our audience? (Web, Mobile, API, Services, …)
  • Does the technology stack have implications on our design?
  • What will we provide? (visual guideline, html and css templates,
    functional components, …)
  • Do we need personalized accounts and different roles? (B2C, B2E)
  • Are Features or Components within an access restricted area?
  • Which systems or sources will be integrated?
  • Will we need live data? (Does data need to be pushed to the frontend, eg with websockets, or will the front-end poll data actively)

Pillar 3 — Design our Design System

Layout and Content

  • What screen sizes and input methods de we design for?
  • How consistent should different products and platforms be?
  • What types of content do we expect
    (Data, mostly text and images, products, …)
  • Where do we expect the highest complexity, both visually and functional? (Tables, Forms, Dashboards, Products, Check-Out…)
  • Will there be foreign languages and what are their needs?
    (RTL/LTR, how long will labels be?)
  • Who will write the text?
    (both labels and descriptive text for our design system)
  • What requirements does our Information Architecture pose regarding navigation? (Deep, Wide, how many Levels, in 3 years?)
  • How will the user navigate? (Menu Navigation and/or in-content, Master-Detail Views, Search, Dialogs, …)
  • Will the user be able to customize his view?
  • Is our system capable of personalization?
  • Do we build on existing design systems or frameworks?
    (Material, Bootstrap, …)
  • How will our grid look and feel like? (appearance, columns, whitespace)
  • What components do our products need?
    (Create an inventory, mark ones that you have but don’t need anymore)

Pillar 4 — Build our Design System

Manipulating Data

  • Where does the user edit stuff? (Dialogs, Inline, Popup-Forms, …)
  • Auto-save or Save Buttons?
  • Do we need Inline-Edit (what happens with complex validation rules?)

Error Prevention and Error Tolerance

  • When do we validate user input and how do we show validation messages? (complex validation over several fields)
  • Is there an Undo option and how big is the risk for our users if we don’t have one? (especially critical with autosave)
  • Do we need a history? (Log, Roll-back)
  • What happens on Session Timeout? (eg. someone resumes the task in an open browser window the next day, but the session has timed out)
  • Can we use plausibility checks to prevent errors before they happen?

Notifications

  • What levels of notifications are needed?
    (Info, Success, Warning, Error, Critical)
  • Where do we show them?
  • What channels are used besides the screen?
    (Push, E-Mail, SMS, Info screen, …)
  • Are there critical notifications that can lead to real problems if the users miss them?

Testing and Documentation

  • When and how do we run usability tests?
  • How do we test the code of our design system?
  • What parts should we document?
    (Patterns, Components, Code, Do & Don’ts)
  • Where can we document it?

Pillar 5 — Maintain our Design System

Integration

  • Does our build pipeline allow for automation?
  • How do we automate our tests?
  • How are we going to version our design system? (Semantic Versioning)
  • What is the process for product teams to submit Pull Requests?
    (Features, only Bugfixes, Tests)
  • Do we need rules that feature requests need to pass
    in order to make it into the design system?
  • Which channels do we use to notify our product teams
    about new releases?
  • Who updates the change-log for new releases and sends newsletters?

Scaling

  • Do all products need the whole design system or can we group it into plugins?
  • What tweaks to our Design System do we allow by the product teams?
  • Can Product Teams implement their own versions of our components?
  • How do we add, deprecate and remove components?

DesignOps Global Conference Talk

I had the chance to talk about this check list at the DesignOps Global Conference 2019 in Manchester. It covers this check list and some more.
And the Fonts didn’t work.

Next Article in the Design System Series

Part I5 Pillars of a Design System

🚧 Work in Progress

If you’ve found this list to be useful, I need your help to make it even better. Please share it with your fellow designers and leave a comment below with additional questions you ask yourself or pitfalls you found out about the hard way while designing a system.

-No, this isn’t my checklist. This is simply stock photo by Glenn Carstens-Peters on Unsplash to make the teaser of this article look nice :)

Ramblings of a Designer

I write about Interaction and UX Design.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store