🏫
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️⃣ Abstract component design
  • Identify existing use cases
  • Abstract what's common
  • Iterate based on the team's input
  • 2️⃣ Detailing a component
  1. Product Design
  2. Design System

How to build components

PreviousHow to set up a design foundationNextHow to document a design system

Last updated 1 year ago

👋 Introduction

Post the pilot exercise, it's time to construct and document the components we've recognized. But before releasing v1 of a component, we should think about how the component helps with existing uses and test in progress work with the teams to make sure it's a valuable addition to the design system.

1️⃣ Abstract component design

For a design system component to be truly useful, it needs to support a range of use cases. Abstracting a components design enables that. However, it’s easy to over abstract a component.

Identify existing use cases

Find existing use cases during the discover process and pilot exercise. Don't over optimise for future use cases.

Abstract what's common

When you're abstracting the design, keep in mind that a component must be useful for three or more teams/features. Don't deviate too far from the original samples to keep all components recognisable. Making them too different can create a mismatch with the rest of the interface not using the design system.

Iterate based on the team's input

Before getting too far on your component design, share progress of your abstraction work with the pilot team that will eventually integrate it. Get a gut check from them about whether you’re headed in a direction that fits with what they’re doing.

There may be input from teams regarding changes and additions. However, consider these requests only if three or more teams currently need this component.

Remember that your job as the design system team is really to solve the common problems. The more the design system team tries to accommodate one-off problems, the less focus you can have on solving problems at scale. These one-off requests can be maintained as possible future iterations in separate doc.

2️⃣ Detailing a component

Once you've abstracted a component and tested with pilot teams, it's time to detail it out. Cover the following:

  1. Usage - A short description about the component.

  2. Anatomy - Breakdown of all the elements and building blocks of the component.

  3. Variants - Overview of all the configurations the component can have.

  4. Behaviour - This section elaborates on all the interactive details useful for the team

  5. Specs - Detailed breakdown of spacing and structuring of the component.

  6. Accessibility - Details about how the component should support assistive technologies.

5️⃣
Identifying use cases
Abstracting what's common