Figma: Introduction to design systems

  • Figma
  • Figma Design
  • Design

These are notes from some of the videos from Figma's Introduction to design systems video series. As I've been learning Figma, I've been looking for some best practices around organization within Figma; how different teams keep track of all of the parts of their design ecosystem, from big components to small primitives, from internal documentation to public-facing assets.

I absolutely love when an organization gets all of this stuff right and can keep look and feel consistent across different properties and platforms. It signals that an org has great design and dev hygiene, which enables them to (seemingly) effortlessly put out polished products. Keeping that in mind, I wanted to try and figure out what makes for a good design system.

What is a design system?

Most designers think that a design system consists of a style guide and a component library, but it goes beyond that. A design system is a set of design standards used to build an ecosystem of products. This system communicates the "what", the "how", and the "why" of that ecosystem. It can contain:

  • Technical specs
  • Design tokens
  • Documentation
  • Principles
  • Processes

Resources in a design system

  • Style guide: a set of standards that define the appearance of elements and the overall voice and tone. A style guide focuses on the visual of the product, how things should look and feel. It can contain:
    • Colors
    • Typography
    • Icons
    • Logos
    • Illustrations
    • Brand guidelines
  • Pattern library: the visual and interactive aspects of components that enable standardizations and minimize discrepancies. It can contain:
    • Templates
    • Layouts
    • Interactions
    • Code snippets
    • Components

Do you need a design system?

Signs you might need a design system/some questions to ask:

  • Consistency struggles
  • Theming (dark and light modes)
  • Are people building the same thing over and over?
  • Are teams debating the same issues again and again?
  • Does the team lack a shared knowledge or language to discuss the product?
    • How easy is it to find answers to problems?
  • How long does it take to onboard new teammates?
  • Where in the product lifecycle can you benefit from improved speed and efficiency?

Audit

If you suspect you need a design system, the next step is to perform an audit. This lets you take stock of the product and find areas of improvement. This opens up conversations about various problems and can help secure buy-in from leadership.

  1. Identify the audit team: Who can help provide a full picture? This is a cross-discipline process; developers might know about inconsistencies between design and code, but the support team might know about sneaky modal errors that devs don't have visibility into
  2. Gather everything that exists: userflows, common or like elements, patterns, and interactions. Begin categorizing this stuff
  3. Analyze what's been gathered to identify patterns and areas of opportunity

Benefits of a design system

  • Allow teams to do more with less
    • Designing and prototyping features
    • Building real-world experiences
  • Less time spent sweating the small stuff increases design output, allows more time spent solving design problems
  • Becomes an onboarding resource allowing new team members to ship sooner
  • When aligned with code, tokens, and animation presets, enables engineers to ship experiences faster
  • As a design system matures, it becomes the single source of truth, provides teams with a shared language, and results in more consistent products. Ladders up to a more successful customer experience of your product
    • Consistency, usability, and accessibility build trust in the product

Challenges of a design system

Like products, a design system requires consistent time and effort to build and maintain. It requires investment and it might be a while before the ROI starts to be realized. This can make stakeholder buy-in a challenge. A design system also needs champions within the org to drive adoption of the design system.

Possible lifecycle of a design system

  • Approval: Where we work to get leadership on board with design systems
  • Discovery: Where we conduct research and audits, identify audiences and problems, and brainstorm solutions
  • Definition: Where we make decisions on solutions, contributors, and approaches
  • Building: Where we assemble the actual design system
  • Documentation: Where we detail how to use the design system
  • Maintenance: Where we make sure the system is up-to-date and that design and code are aligned
  • Advocacy: Where we socialize the design system into the organization

However, the lifecycle of a design system is not a linear process with a single endpoint; this is a cycle and many of these phases may overlap.

Key parts of a successful design system

  1. Principles
  2. Foundations
  3. Documentation
  4. Processes

Principles

Principles are the why of a design system. They're the guiding standards and approaches that reflect the org's beliefs and values. A strong set of principles directs everyone toward a common goal and aids in alignment when conflict arises.

To create impactful principles, you need cross-discipline perspectives.

  • How is the company represented by brand and marketing teams?
  • How do writers communicate to customers?
  • What is the experience when something goes wrong and customers need support?

Gather these partners, share ideas, and spot common patterns, characteristics, and actions. Then establish principles that are easy to understand and put into practice.

A principle might have:

  • a defining characteristic
  • a defined impact on customer experience and business goals
  • clear examples of what this principle looks like in action

Example: Be accessible and inclusive

  • Service should be available to the widest possible audience
  • Celebrate prioritizing accessibility
  • Considerations:
    • Are we testing using accessibility testing tools?
    • Are we testing with a wide range of users?
    • Can people navigate all pages with screen reader software?
  • Actionable suggestions:
    • Use WCAG AA
    • Eliminate jargon and use easy-to-understand language

Foundations

Foundations are the what of your design system. They're building blocks used to create product experiences, like styles, colors, typography, etc.

Some foundations:

  • Accessibility: a type of inclusive design focusing on users with disabilities
  • Color: can express personality, invoke emotions, and influence behavior; in products, color helps to create hierarchy and provide affordances
  • Typography: creates consistency, personality, and readability across your product
  • Type scale: a collection of font sizes and styles that make up your type system
  • Elevation: used to provide hierarchy, separation, and give visual feedback. Can be achieved using colors, shadows, transparency, and overlays
  • Iconography: Reinforces visual identity, improves user experiences
  • Grids, layouts, and spacing: The unseen scaffolding that provides rhythm and structure to our designs.
    • Layout: Designs should adapt to different screen sizes in ways that users expect
    • Grids: column, baseline, and modular grids are the most common

Documentation

Your design system's documentation is that system's how.

Documentation can look like:

  • on-canvas annotations for components and design files
  • style and component descriptions in Figma
  • naming structures in a library or codebase
  • written articles and guides
  • dedicated websites and tools

Considerations for your documentation:

  • Who is your audience?
  • When will your audience need this information?
  • How will your audience access this information?

If the information is too difficult to access, people won't use it.

It's highly recommended that you document your decisions as you go. This captures important information as it's defined. Make documentation a criteria for "done" work when components or layouts are added.

Tips

  • Make sure documentation is thorough and complete
  • Put yourself in the shoes of someone who has never seen this element before:
    • What are they using it for?
    • What do they need to know to achieve their goals?
    • What questions might they have along the way?
  • Avoid jargon and complex terms. If you need to introduce complex terminology, define it
  • Visualize what you write
  • Consult with writers in your company for guidance; also elicit feedback from both within and without your team

Naming conventions

A naming system makes it easier to find, understand, and apply elements in your design system.

  • Semantic naming: "Danger" or "Primary" instead of "spring blush" or "#FF5F72"; consider the function of the color and how it will be used
  • Component naming: In the example of a button, the primary button should correspond to the main action of a page. There should only be one primary button. Secondary buttons are non-critical actions. Each action has a default state and a pressed state.
    • This presents three levels of these buttons:
      • Category = button
      • Use = primary vs. secondary
      • Variation = default vs. pressed
    • This results in a structure for naming assets:
      • category / use / variation
    • We need to be able to apply this structure consistently; some common options:
      • Title Case: Trend Card / Trend Direction/ Upwards
      • Sentence case: Trend card / Trend direction / Upwards
      • underscore_case: trend_card / trend_direction / upwards
      • camelCase: trendCard / trendDirection / upwards

Processes

A design system's processes capture the mechanics and governance for managing the system:

  • How to make updates to a system and share them with others
  • Who to give feedback to and how
  • How to get changes to the system approved
  • How to collaborate with cross-functional teams
  • How to provide training to new members of the team

Development considerations

When designers and developers work side-by-side, the design system can benefit. A path to success might look like:

  • Getting developers involved in critiques before you finish designs
  • Consulting developers when you create new components so they can align with related code
  • Learning to spot limitations; working with devs to understand the codebase

Some tools for operationalizing the design system culture

  • Brainstorming workflows
  • Retros
  • Lunch-and-learn teach backs across disciplines