An Event Apart: “Why Design Systems Fail”

Una Kravets speaking at An Event Apart Orlando 2018 on October 9, 2018

Design systems are hot right now, and for good reason. They promote a modular approach to building a product, promote organizational unity, and ensure stability via reusable code snippets and utility styles. They make prototyping a breeze, and provide a common language for both designers and developers. But sometimes design systems are underutilized within organizations. Why is that, when they’re so darn useful? In an engaging hour, Una will draw on years of experience to explore what makes design systems successful, analyze real examples of success and failure, and show how to make sure your design system has the building blocks it needs to grow into a successful product.

Notes

  • In this talk:
    • What exactly is a “Design System”?
    • Why Design Systems fail
    • Execution details
    • Steps for getting started
  • What is a design system?
    • Style guide or visual pattern library
    • Design tooling
    • Component library
    • Code usage guidelines and documentation
      • eslint-config-airbnb
      • stylelint-config-airbnb
    • Design usage documentation
    • Animation language
    • Voice and tone guidelines
  • A design system fails when nobody uses it
  • Happy design systems:
    • Scale good standards
    • Build-in accessibility
    • Unify component style
    • Unify component code
    • Reduce code cruft
    • Speed up product delivery
  • People don’t use design systems, because we are all being judged on different metrics
  • Why design systems fail
    • Investment
      • To have a successful design system, you need to make a continuous effort to invest resources into it
      • A successful design system is like a successful exercise program
      • You need to have a dedicated person or team looking out for the design system
    • Communication
      • Ask
      • Listen
      • Make your user feel heard
      • Incorporate feedback
      • Act as a bridge between designers and engineers
    • Buy-in
      • Showing is more powerful than telling
      • When you can convince someone to use your design system, that’s when you really win
    • Solid architecture
      • GitHub Primer
      • Build it so it can grow
      • Semantic versioning — Major.Minor.Patch
      • Don’t wait to namespace
      • Tech stack choice
      • Design tooling still isn’t solved
    • Reduce friction
      • If a new design system is harder to use than the current system, people won’t use it
      • Start early, update often
      • Make sure there is a system in place to take care of bugs as they are found
  • So you want to build a design system?
    • Goal/hypothesis setting
      • Why are you building a design system?
        • Increase page performance
        • Decrease design inconsistencies
        • Decrease code cruft/bugs
        • Decrease codebase size
        • Increase speed of delivery
    • Review what you’ve got
    • Get user buy-in
      • Use the review stats to get user buy-in
        • Performance optimization issues (webpagetest.com)
        • Accessibility bugs (webaim.org, pa11y.org)
        • Style inconsistency data (cssstats.com)
        • Component inconsistencies (component cutup workshop)
      • Get buy-in and a commitment to action
      • Make a plan
      • Put it in writing
    • Make technical decisions
    • Start with atomic elements
    • Compose elements
      • Do we include layout in the system? To what extent?
    • Focus on interaction and accessibility
      • Every :hover has an equal (not opposite) :focus
      • Loaders
    • Document design and technical usage
    • Inform your users
    • Keep consistent communication
      • Design <> Dev Communication
        • What’s the ultimate visual source of truth?
        • What is the usage for each component?
        • When is the component inappropriate to use?
        • What does the interaction look and feel like?
        • How do the various states look?
        • How does this component interact with others?
  • Continuous iteration, support, and communication are the most important factors to design system success
  • Code is only 10% of it, design is only 10% of it — people ops is 80% of it
  • Different needs, different solutions
    • We can’t compare our 5-person design team to their 300-person design team
  • If the cost is greater than the benefit, you might not need a design system
  • You can’t be the only person rooting for the design system to work

Speaker Links and Resources

Design Systems

Resources

Tooling