Skip to content

A questionanaire for creating effective design systems

Notifications You must be signed in to change notification settings

kelsS/design-system-questionnaire

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

49 Commits
 
 

Repository files navigation

Design System Questionnaire

A one-page questionnaire to help your organization establish effective design systems and style guides. The sections are broken down into the broad process of creating a successful design system:

  1. Sell
  2. Kickoff
  3. Plan
  4. Design and Build
  5. Launch
  6. Maintain

1. Sell

Problems and Opportunities

Why do you want to create a design system? What problems does the design system need to address in your organization?

What are the goals you want to accomplish in establishing a design system? - The benefits of design systems are many, but what specifically are the goals of your organization's design system initiative?

What will happen if this initiative fails?

People

Who needs convinced? Which departments or people in your organization need convinced that establishing a design system is a good idea?

Who's doing the convincing? Who is involved at convincing stakeholders, management, securing funding, etc?


2. Kickoff

User Research

Who are the users and stakeholders of the design system? It's important to understand the needs of the people who will be affected by the design system. Conducting interviews with makers, users, and stakeholders helps the team better understand what the design system needs to be in order to be successful.

Who will conduct user/stakeholder interviews?

Who will be interviewed? - It's important to interview a healthy cross-section of product teams, disciplines, skill levels, and perspectives in order to ensure the design system initiative properly serves the organization.

What are the broad themes uncovered by the interviews? What pain do people experience, and how can the design system aliviate that pain?

Kickoff workshop

The kickoff workshop is used to kick off the design system initiative and establish a broad consensus about what the design system is and .

Who needs to be present at the kickoff workshop? The kickoff meeting attendees should be stakeholders who will influence and/or be influenced by the design system. Who should be present to ensure proper representation across products and disciplines?

What are the shared outcomes and priorities of the design system initiative? This is the result of the kickoff session and interviews.

Who is responsible for taking the outcomes of the kickoff workshop and translating them into a plan of attack?


3. Plan

Principles

  • What design principles does your design system embrace? Design principles underpin every aspect of the design system, and influence its construction. They should jive with your organization's broader mission and culture, and your design principles should be easily understood by everyone doing work with the design system.

Here are some good resources about design principles:

Products

What products will the design system serve? - List the products the design system will be applied to.

Are there products that will not be served by the design system? Why? What will those products use instead? List the products that won't make use of the design system and discuss why they won't utilize the design system.

What are the design system's pilot projects? - Design system pilot projects put the design system through its paces as it's being constructed. Which projects Keep in mind that pilot projects should provide a healthy cross-section of components, patterns, technologies, processes, and people. Read Dan Mall's Design System: Pilots and Scorecards for criteria for choosing design system scorecards.

Technology

What platforms does the design system apply to? (Web, iOS, Android, Windows, etc)

What web technologies does the design system need to consider? React, Angular, Drupal, WordPress, Handlebars, Twig, Jade, etc, etc.

Code Guidelines

What frontend guidelines does the design system follow? Frontend guidelines - For more information, check out Frontend Guidelines Questionnaire that's similar in format to this questionnaire.

Code language style guides - Which backend technologies are in use at your organization (PHP, Ruby, .NET? Are there style guides available to help the team write more cohesive code together?

Design Tools

What design tools are in use at the organization? The design system should be integrated with the tools teams use in their day to day work.

What design tools will be used to const

Methodology

Does your team use a methodology to organize components? Such as atomic design?


4. Design & Build

Do it!


5. Launch

What is the name of the design system? - A catchy and memorable name can help your design system gain traction. The name of the design system should embody the spirit of the organization and the system's underlying design principles. Fair warning: naming is hard.

Where does the style guide live? - The style guide (the container that houses the guts of the design system) should live at an easy-to-access and easy-to-remember URL (i.e. designsystem.yourcompany.com)

Is your style guide publicly accessible? (Yes, no, maybe, eventually). Making a style guide public has many benefits.

What tool are you using to house your style guide? - What tech is your style guide built on? What's its relationship to the style guide website to the components that make up your design system?

What does the design system include?

A design system is a collection of components, guidelines, documentation, points of view, processes, and tools. What ingredients should your organization's design system contain? No doubt your organization's structure, processes, and tools will all influence the design system's ingredients. I recommend checking out Nathan Curtis's Picking Parts, People, and Products for a great exercise to help prioritize what the system should include.

Let's take a look at some of the parts that your design system can include:

Brand Identity

  • Where are brand identity guidelines managed? - These include brand-wide elements such as logo, typography, color, tagline, marketing guidelines, etc.
  • What is the relationship between the overall brand identity and UI components? - There may be a tight relationship between the brand guidelines and UI (i.e. buttons and logo are, and must be, the same color) or there may be a loose relationship (i.e. Material Design's guidelines and Google's brand guidelines are quite different).
  • Are you using any third-party tools or services to manage brand assets? - Some of these tools include:

High-level Guidelines

What are some high-level guidelines you want to provide in the design system? Some examples may include:

  • Accessibility
  • Animation
  • Data display
  • Data entry
  • Data validation
  • Multi-device design
  • Layout
  • Navigation
  • Performance

While these topics will manifest themselves in more concrete ways at the component level, it's often a good idea to explicitly express the organization's point of view on these topics at a high level.

Content

Color

What are the Brand(s) colors?

Neutral palette?

Utility palette?

What are the color accessibility guidelines - Design a Light & Dark Color System

Typography

What is the typography system used in the design system?

Icons and Imagery

How are icons served in your products? Icon fonts? Inline SVG? SVG sprites? PNGs?

Where are icons sourced? In house or third party? Open source or proprietary?

What’s the process for updating an icon in the system?

What tools are used to create and manage icons? This includes graphics programs like Illustrator and Sketch, but also icon management services like Icomoon.

Motion

What are your guidelines for using motion and animation in your design system? Animation in your style guide

UI Components

What UI components are included in the system? - Form fields, cards, tabs, and much more can be present in your organization's design system. Which UI components that Conducting an interface inventory can be a good way to determine which UI components should be codified in the design system.

Page templates

What page templates should be included in the design system? Are there common page templates your organization creates time and time again? Templates for portals, dashboards, homepages, blog posts, etc may be good to codify

Workflows

If UI components are the tools in the toolshed, then workflows are the common tasks you perform with those tools.

What workflows should be included in the design system? Things like Sign up, Authentication, E-commerce checkout, Multi-step form, etc

Announcement

How will the design system be announced? - How will people find out about the new design system?


6. Maintain

People

Who are the primary design system makers? - Who is responsible for creating and maintaining the design system? Provide names and roles.

Who are the primary users of the design system? Who are the people that will be primarily be implementing the system's components, reading guidelines, and referencing the information in the style guide?

Who are the secondary users of the design system? Secondary users are people who may not rely on the system for their day-to-day work but may find the documentation and information in the style guide useful.

Are there teams or people in the organization that won't use the design system? Why? What do they do instead?

How is the design system team structured? Solitary? Centralized? Federated? How the design system team is structured influences its adoption and ongoing success. For more info, read:

Who is the primary owner of the design system? - Who is the primary person responsible for the design system's success or failure? This person is often in a senior leadership or director position.

Who is responsible for allocating time, budget, and resources to the design system initiative?

Who are the design system's key stakeholders?

Are there other parties involved? - Are there any players outside of the organization (agencies, consultants, etc) who will affect or be affected by the design system?

Deployment

How do the design system's components find their way into applications? See Chasing the Holy Grail: Strategies For Distributing Your Pattern Library and Keeping It in Sync for various strategies on how to deploy design systems.

How is versioning handled? - What versioning conventions do you adhere to when rolling out new updates to the design system. See Semantic Versioning for an example.

How are dependencies managed?

Who manages the deployment process?

Making Changes

Who can contribute to the design system? - Can every user directly contribute patterns or modifications to the design system's components and guidelines? Or is it only managed by a select few? On the spectrum from wipe open to complete lockdown, where does your design system stand?

What does the contribution process look like? - Pull requests? Simple feature requests? Prototypes? What process should people expect to follow in order to propose fixing a bug, extending a pattern, adding a new
See modifying patterns for more info.

How do changes make their way into the design system?

When the system is updated, what is the process for getting those changes into individual applications?

Communication

What communication channels are used to talk about the design system? - The design system should plug into the organization's existing communication structure. Slack? Yammer? HipChat? Basecamp? Wikis? Blogs? Email newsletters?

What steps are taken when the design system is updated? Release notes? Blog post? Email newsletter? Smoke signals?

How are system changes communicated to end users? How are users of your organization's applications notified when design system changes affect their experience? This may include release notes, blog posts, guided tours, videos, overlays, tweets, etc.

About

A questionanaire for creating effective design systems

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published