Design Systems – Alla Kholmatova

Review

This book makes a fair attempt at documenting the process of how to make a successful design system. I feel there’s still room for ‘the definitive Design System book’. I can’t bring myself to recommend this one, despite it being the best text I’ve found.

Most of the advice is useful, timeless and considered. Design tooling though is evolving quickly. This book was written in 2017 before the breakout of Figma and the other tools that have shaped the space.

Key Takeaways

The 20% that gave me 80% of the value.

  • A design system is a set of curated patterns and practices that help a team design and build a product.
  • Without a shared language a group of people can’t effectively create together. A design system makes your design language actionable and reproducible.
  • A design system is not just a pattern library. It’s a techniques and practices for creating, capturing, sharing and evolving those patterns. As there’s always room for interpretation. It’s the discussions around the interpretation which are the key to success or failure. A coherent design system integrates the patterns and practices.
  • Patterns are the repeating elements that are combined to create an interface
    • Functional Patterns: represented as concrete things or modules (e.g buttons, headers)
    • Perceptual Patterns: styles that describe the personality of a module (e.g. color, type, animations)
  • Practices are the processes behind creating, capturing, sharing, evolving and using them within a team
  • The purpose of the product should shape the design patterns it adopts. Radical new patterns require users to learn and adopt them. Use them sparingly. It’s best to differentiate your product not with patterns but with your design language.
  • A fragmented design system leads to a fragmented user experience – and lower design and build productivity.
  • Your core purpose should inform design and build decisions. Your ethos is also important, the values and spirit you want to portray with your brand. Ground everything in design principles. Involve the team in their creation. Values and principles can help you make decisions later.
  • Work out the key behaviors that you want to encourage or enable in your users that will help them achieve their goals. Design details will change, but behaviors will remain constant. Behaviors inform core functional models and interactions.
  • The words we choose to describe patterns influence how the team thinks, and shape designs.
  • Design principles are shared guidelines that capture the essence of what good design means for the team. Agreed criteria for what constitutes good design for your product.
    • The purpose of your product should shape all design decisions
    • Avoid generic principles that are obvious. Stress test your principles by asking is the opposite non-obvious anyhow?
    • Principles should be practical and provide actionable advice
    • Pair a principle with a real life example to show how it can be applied in practice
    • Principles should be memorable, keep them in constant use, keep them visible
    • Aim for between 3 and 5 principles
    • Start with the company values, mission and the product vision. Try to work out what principles would contribute most towards that goal.Ask everyone in the team – what good design means for your product? Ask them for a practical example for each thing they suggest
  • Functional Patterns → Tangible building blocks of the interface (objects). Their purpose is to enable and encourage certain behavior.
    • They’re largely influenced by the domain a product belongs to
      • Defining functional patterns
        • First map out your customers’ needs, goals and motivations (experience maps, jobs to be done etc). This anchors you in the user behaviors you want to enable and encourage.
        • Map core modules to sections of the user journey (to see how they fit into the big picture). Look for families of patterns that join together to help the core purpose.
          • e.g. For an education platform: discovery, learning, achievement
        • Conduct an interface inventory. Print all the screens of your interface. Separate out the components – group them into categories (navigation, forms, tabs, buttons, lists)
          • you can focus on one group at a time, you don’t have to do everything in one go
          • do them regularly – even if you have a maintained pattern library
        • View patterns as actions. To understand the purpose of a pattern, focus on what it does (not what it is). Try to find an action that best describes the behavior the pattern is designed for – helps you broaden the use of modules.
        • Draw a patterns structure (heading + call to action + background) and determine the hierarchy of elements and decide how they should be grouped.
        • Check if any similar ones can be unified into a single pattern.
      • Knowing the purpose of the pattern helps …
        • reduce duplication by helping everyone understand the design intent
        • determine the effectiveness of patterns with testing
        • helps define how much it can be modified before it becomes something different
  • Perceptual patterns → are styles, they describe what kind of objects they are and how they feel
    • Effective perceptual patterns help differentiate your product. They change how your product feel (even if it’s in a similar domain, with similar modules).
    • Platform-specific standards like Material Design take a strong view on functional patterns, so brands rely on perceptual patterns to bring the brand to life.
    • Create a design persona – capture key personality qualities which embody the traits of your brand. Could be a person or a place.
    • Select 5-7 traits that best describe your brand (and some to avoid)
    • Iterate and refine over time – allow patterns influence one another.
    • As you develop the brand – move from open exploration to refinement and consistency. Start broad and big, don’t worry about every detail. Then refine concepts as you start to apply them to a more realistic environment.
    • Perceptual patterns can be concentrated in the smallest details – in signature moments and micro-interactions. Teams struggle to prioritize the small details that add depth and meaning, and make something feel distinct.
  • Creating a cohesive system requires a shared language.
    • Naming Patterns → by naming objects, we start bringing them into existence. Well-chosen names are powerful tools in shaping your design system
    • Make your design patterns visible – create a pattern wall in the office. Position printouts in user journey order.
    • Make it part of the induction process – take employee’s through the story of hour the guidelines were created so they can understand why and how the decisions had been made
    • Keep a glossary and an up-to-date pattern library as a reference point for the entire team.
  • 3 dimensions of a design system:

1) Strictness of the rules (strict → loose)

  • Stricter systems provide precise and predictable outcomes and visual consistency – at the same time they can become too rigid, making UX compromises for the sake of consistency
  • Loose systems are suited to products that prioritize sensitivity to context and experimentation. They require everyone to be aligned on the purpose and design approach

2) Modularity of the parts (modular → integrated)

  • Modular systems make parts interchangeable so they can be assembled in different ways.
    • Benefits: agile, cost-effective, easy to maintain, adaptable, can have a generative quality → come up with new outcomes by combining modules in new ways
    • Best for when: product needs to scale and evolve, adapt to different user needs, have a large number of repeating parts, multiple teams working on them
    • Drawbacks: more time-consuming to build, to be cost effective modules need to be re-used. Modules have to be more generic. Hard to make modules connect seamlessly. Focus not only on the modules, but the connections.
  • An integrated approach is not interchangeable as connections between them are not designed to fit in different ways.
    • Benefits: Specific to content, context, story or art direction. More coherent and connected. Built quicker as one-offs. Easier to coordinate]
    • Best for when: for one specific purpose, don’t need to scale or change, few shared repeating parts, one offs that are unlikely to be re-used
    • Drawbacks: doesn’t scale well, not adaptable or reusable.

3) Distribution of the organization (centralized → distributed)

  • A centralized model, is when rules and patterns are managed primarily by one group of people. They define the patterns and rules, have a veto and manage the pattern library
    • Benefits: ownership and accountability, better curation, maintenance and evolution. More focus and more opinionated.
    • Best for when: Design-led companies like Apple or Airbnb.
    • Drawbacks: impractical for small companies to have a dedicated team
  • A distributed approach is where everyone who uses the system is responsible for maintaining and evolving it
    • Benefits: autonomy, empowerment, more agile and resilient, creative direction is distributed (not limited to a few people)
    • Best for when: have a strong culture, distributed teams have a strong idea of what they want to do
    • Drawbacks: enthusiasm can dip, and people don’t want to do the additional work, hard to get everyone to contribute evenly, dilutes creative direction.
  • Conway’s law: organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

Get support to build your design system – don’t do it as a side project.

  • Show how an effective design system will help to meet business goals faster and at lower cost
    • Reusing elements saves time.
    • Quantity the cost of visual inconsistencies
    • Make site-wide changes faster
    • Prototype faster
    • More brand unity and visual consistency
  • Make progress transparent – stick things on the wall, write blog posts.
  • 80/20 principle – what tasks provide the most benefit for the least effort.

Build a Purpose-Directed Inventory

  • Identify key behaviors. User needs and behaviors you want to support in each part of the journey
  • Group existing elements by purpose
  • Define Patterns
  • Naming them well → Names affect how patterns are used – a well-chosen name is a powerful tool for shaping your design system. Find a name that reflects a pattern’s position on the specificity scale. If in doubt – go with a more specific name. Effective names guide usage and reduce the chances of duplicate patterns.
  • Once you’ve grouped the self-contained parts, repeat the process with other elements.

For perceptual patterns – we start with aesthetic qualities.

  • Styles should link to ethos and core design principles. Think how those qualities are embodied. How do you evoke those feelings in the user?
  • For each style – systematize them using this process
    1. Start with the purpose
    2. Collect and group existing elements
    3. Define patterns and building blocks
    4. Agree on the guiding principles
  • If your goal is to change the current design of your website – do it before you do your systematization exercise
  • Each style should be approached like a system in it’s own right. They should be interconnected and directed towards achieving a larger purpose.

Multidisciplinary pattern libraries are more resilient and enduring. Organize functional patterns for find-ability. Organization options: alphabetically, hierarchically, by type or by purpose.

  • Purpose seems the best → gives team guidance and inspiration for where to use a specific module – also fit with our purpose-directed approach for defining patterns.

Pattern Documentation should include → Name, purpose, examples/recommendations, variants, contributors, versioning and link out to related patterns. Do’s and Don’ts format can be useful – certainly if you’re expecting misuse Incorporate your design system into your workflow. For new components the key questions are: What is it? What is it for? How does it achieve it’s purpose? If you have a design system team – they should be partners not police.

Category: