🏫
Obvious University
Website
  • 👋Welcome to Obvious University!
  • Strategy
    • Sprints
      • 1️⃣Map
      • 2️⃣Sketch
      • 3️⃣Decide
      • 4️⃣Prototype
      • 5️⃣Test
    • Benchmarking
    • Research
      • 1️⃣Research guide
      • 2️⃣How to recruit users
      • 3️⃣How to conduct an interview well
      • 4️⃣How to take notes
      • 5️⃣How to prep for remote research
      • 6️⃣How to throw a watch party
      • 7️⃣How to create artefacts
  • Working with Features
    • Building with AI
      • 1️⃣Understand the tech
      • 2️⃣Map your product
      • 3️⃣Build a proof of concept
      • 4️⃣LLM Inputs
      • 5️⃣LLM Responses
    • Building Help and Support
      • 1️⃣How to scope a support experience
      • 2️⃣How to design discovery for support
      • 3️⃣How to design a support centre
      • 4️⃣How to write good support articles
  • Product Design
    • Microcopy
      • 1️⃣How to write well
      • 2️⃣How to write phrases
      • 3️⃣How to write messages
      • 4️⃣How to create a voice
    • Typography
      • 1️⃣How to compose type
      • 2️⃣How to create a type scale
      • 3️⃣How to pick typefaces
      • 4️⃣How to pair typefaces
    • Design System
      • 1️⃣Introduction to design systems
      • 2️⃣How to audit a design system
      • 3️⃣How to run a design system pilot
      • 4️⃣How to set up a design foundation
      • 5️⃣How to build components
      • 6️⃣How to document a design system
      • 7️⃣How to enable adoption and govern a design system
    • Mobile Engineering
      • 1️⃣Trunk based development
      • 2️⃣Agile development terminology
      • 3️⃣Git commit messages
      • 4️⃣Code review and pull requests
      • 5️⃣Readings
  • Delivery
    • Project Management
    • Collaboration
  • Hiring and Growth
    • Growth
      • 1️⃣Design growth framework
      • 2️⃣How to give ongoing feedback
      • 3️⃣How to check-in every quarter
      • 4️⃣How to address underperformance
      • 5️⃣FAQs
    • Hiring and careers
      • 1️⃣The Hiring Process
      • 2️⃣Diverse and Inclusive Hiring
  • PEOPLE EXPERIENCE
    • Benefits and Perks
      • 1️⃣Paid time off
      • 2️⃣Insurance and healthcare
      • 3️⃣Continuing education
      • 4️⃣Speaking at conferences
    • Starting at Obvious
      • 1️⃣Introducing Obvious
      • 2️⃣Set up your workspace
      • 3️⃣Onboarding
      • 4️⃣Finances
      • 5️⃣Code of Conduct
    • Employment policies
      • 1️⃣Equal opportunity employment
      • 2️⃣At-will employment
      • 3️⃣Employee records and privacy
      • 4️⃣Prevention of sexual harassment
      • 5️⃣Drugs and alcohol
      • 6️⃣Fraternisation
      • 7️⃣Non-compete and non-solicitation
      • 8️⃣Non-disclosure
Powered by GitBook
On this page
  • 👋 Introduction
  • 1️⃣ Choose a design system pilot
  • 2️⃣ Identify components from pilot feature/product
  • 3️⃣ Identify Initial Components to Pilot
  • 4️⃣ Outcome
  1. Product Design
  2. Design System

How to run a design system pilot

PreviousHow to audit a design systemNextHow to set up a design foundation

Last updated 1 year ago

👋 Introduction

In order to test how a design system will support the product in the long term, a pilot is run a product or a feature.

1️⃣ Choose a design system pilot

To find the right pilot, review products or features you went through during the discovery phase. After the review, score these against the following 8 factors (on a scale of 0, unlikely, to 10, likely) for selecting the best pilot:

  1. Potential for common components: Does this pilot have many components that can be reused in other products?

  2. Potential for common patterns: Does this pilot have many patterns that can be reused in other products?

  3. High-value elements: Even if uncommon, is there a component or pattern with high-business value that is the heart of this project? Elements that are integral to a flow or audience that has unusually high value for the organisation.

  4. Technical feasibility: How simple is a technical implementation of the design system? Is a large refactor required?

  5. Available champion: Will someone working on this product see it through and celebrate/evangelise using the design system (and even contributing back to it)?

  6. Scope: Is this work accomplishable in our pilot timeframe of [3–4 weeks] (insert your timing here)?

  7. Technical independence: Is the work decoupled enough from other legacy design and code that there are clear start and end points?

  8. Marketing potential: Will this work excite others to use the design system?

Work with the team (include product, engg and design) to score these features as accurately as possible.

2️⃣ Identify components from pilot feature/product

Once you have identified a solid pilot candidate, reach out to the team that owns it and start scheduling time to walk through feature/product with them. Keep track of who you’ve talked to already and their general reception to working together.

Ask the pilot team to:

  • Walk you through what they’ve been working on and what’s coming up soon on their roadmaps.

  • Share their screens and take you through all the user flows/journeys.

As they’re showing you their screens, make a list of every component you see on screen. Look out for anything that could be a modular piece of design or code element.

3️⃣ Identify Initial Components to Pilot

  1. In the interface inventory list you generated before, highlight the components that appear three or more times.

  2. Find the overlap between the component list & components seen in pilot walkthrough to identify the first set of design system components.

This also becomes the initial guideline for which components go into the design system: if three or more teams need this component right now, it goes in the design system.

4️⃣ Outcome

You would have identified a pilot that includes components that will be used in other features or products also. This will help showcase the value of the design system quickly and also excite stakeholders.

Dan Mall has written about design system pilots and this scorecard .

3️⃣
here