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.

You Might Also Like…

Book Review and Summary: The Design of Everyday Things by Donald A. Norman

Get a comprehensive review and summary of the classic book "The Design of Everyday Things" by Donald A. Norman, the user experience and design expert. Learn about the key principles and practices for designing products and environments that are intuitive and enjoyable for users.

andrewclark.co.uk

Articulating Design Decisions

I wish I’d found this book earlier. We don’t work in a vacuum, we work with people. Much of this advice is transferable to product teams and product managers communicating product decisions.

andrewclark.co.uk

Book Review and Summary: Information Architecture by Louis Rosenfeld, Peter Morville, and Jorge Arango

Get a comprehensive review and summary of the best-selling book "Information Architecture" by Louis Rosenfeld, Peter Morville, and Jorge Arango, the experts on information design and organization. Learn about the key principles and practices for creating effective and user-friendly information architectures for websites and digital products.

andrewclark.co.uk

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 colour, 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 behaviours that you want to encourage or enable in your users that will help them achieve their goals. Design details will change, but behaviours will remain constant. Behaviours inform core functional models and interactions.
• The words we choose to describe patterns influence how the team thinks, and shape designs.

• Functional Patterns → Tangible building blocks of the interface (objects). Their purpose is to enable and encourage certain behaviour.
• They’re largely influenced by the domain a product belongs to
‣
Defining functional patterns
1. First map out your customers’ needs, goals and motivations (experience maps, jobs to be done etc). This anchors you in the user behaviours you want to enable and encourage.
2. 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
3. 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
4. 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 behaviour the pattern is designed for - helps you broaden the use of modules.
5. Draw a patterns structure (heading + call to action + background) and determine the hierarchy of elements and decide how they should be grouped.
6. 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 prioritise 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 prioritise 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.
• Integrated
‣
3) Distribution of the organisation (centralised → distributed)
• A centralised 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.
• Conways law: organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations
• 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 behaviours. User needs and behaviours 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 - systematise 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 systematisation 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.
• Organise functional patterns for find-ability. Organisation 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.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Chapter 1: Design Systems

• A design system is a set of curated patterns and practices that help a team design and build a product.
• 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 colour, 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
• A pattern is a recurring, reusable solution that can be applied to solve a design problem. We use design patterns to solve common problems when creating interfaces.
• E.g: High density (tight spacing, compact controls) for a product that benefits from displaying lots of information at once
• Pattern choice can be influenced by:
• Platform conventions
• Domain
• Functionality (functional patterns)
• Perceptual Patterns (what you want to be known for / ethos)
• Architect Christopher Alexander proposed that buildings elicit certain feelings due to certain tangible and specific design patterns. These patterns could be learnt, and used to create humane architecture.
• A pattern is a recurring, reusable solution that can be applied to solve a design problem. We use design patterns to solve common problems when creating interfaces.
• Patterns guide the user through a product. They can make tasks easier or more delightful.
• Many patterns are established and familiar → building on people’s intuitive mental models
• 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 (how patterns are executed and applied).
• Without a shared language a group of people can’t effectively create together.
• To consistently, reliably and coherently design a product in a team, you need to articulate and share your patterns.
• A design system makes your design language actionable and reproducible.
• Articulating your language is the first step in gaining control over the system.
• Establish a shared language before you think about interfaces
• Shared language is about knowing what, how, in what context and for what purpose a pattern should be used.
• A design system is not just a pattern library. It’s a techniques and practices for creating, capturing, sharing and evolving those patterns.
‣
Iconic pattern libraries
• Palladio’s - The Four Books of Architecture (1570)
• NASA’s Graphics Standards Manual (1975)
• Yahoo’s pattern library - first to document interface patterns
• Mail Chimp - one of the most influential
1. There’s room for interpretation. It’s the discussions around the interpretation which are the key to success or failure of a library
2. A good library can be rigid and restricting OR make experimentation easier.
• A coherent design system integrates the patterns and practices.
• A design system is effective if it helps achieve the purpose of the product. Through improving the user experience and the design and build workflow.
• A design system is a collection of subsystems and rules aligned to a greater shared purpose
• A fragmented design system leads to a fragmented user experience - and lower design and build productivity.
• Purpose and Values
• Understand your users, their goals, needs and motivations
• 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 behaviours that you want to encourage or enable in your users that will help them achieve their goals. Design details will change, but behaviours will remain constant. Behaviours inform core functional models and interactions.
• Aesthetics and perceptual patterns → how do you want to be perceived? What are the aesthetics that capture the personality and ethos we want to portray through the interface?
• Mood boards, experiment with visuals, define core elements.
• Styles are your perceptual patterns.
• E.g: Warm, earthy colours, hand-drawn icons, typography with a readability focus, quality photography.
• The words we choose to describe patterns influence how the team thinks, and shape designs.

Chapter 2: Design Principles

• 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.
• Principles are the foundation of the design system.
• The purpose of your product should shape all design decisions
• Principles help apply a few key values across all customer touchpoints
• Good principles unify design thinking.
• Avoid generic principles that are obvious. Stress test your principles by asking is the opposite non-obvious anyhow?
• E.g. ‘Simple, useful and enjoyable’ is not helpful. Your team weren’t going to design something ‘complex, useless and painful’.
• Principles should be practical and provide actionable advice
• E.g. Make it simple < No needless parts
• E.g. Make it clear < Only one number 1 priority
• Pair a principle with a real life example to show how it can be applied in practice
• Ranking principles helps with decision making:
• E.g. Beauty should not be promoted over efficiency or consistency, and clarity should always come first.
• E.g. Direction over choice (A Medium principle)
• Principles should be memorable, keep them in constant use, keep them visible
• Aim for between 3 and 5 principles
• How to define your 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
• Look for common themes and overlap (be wary of divergence)
• Your design principles are for you and your colleagues first.
• Test, evaluate and refine your principles over time. Your principles will influence your patterns, but your patterns may also influence your principles. Principles should be pretty static though.

Chapter 3: Functional Patterns

• Functional Patterns → Tangible building blocks of the interface (objects) . Their purpose is to enable and encourage certain behaviour.
• Functional patterns are informed by the user behaviours that you want to encourage, therefore they’re largely influenced by the domain a product belongs to (e.g. cooking app vs finance software)
• Functional patterns vary from simple to complex.
• Each module should have a core purpose.
• If a pattern is not defined and shared with the team, you’ll start recreating it to accomplish similar goals → which leads to inconsistency and waste.
• Defining functional patterns
1. First map out your customers’ needs, goals and motivations (experience maps, jobs to be done etc). This anchors you in the user behaviours you want to enable and encourage.
2. 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
3. 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
4. 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 behaviour the pattern is designed for - helps you broaden the use of modules.
5. Draw a patterns structure (heading + call to action + background) and determine the hierarchy of elements and decide how they should be grouped.
6. Check if any similar ones can be unified into a single pattern.
• Place patterns on a scale (e.g. visual loudness) to differentiate them, and make clear the potential use cases
• Imagine your interface is not visual, but read out by a voice. When would that voice need to get louder and change annotation. Now think about how that could be expressed between the elements within the modules, as well as their hierarchy in the overall design.
• Treat content as a hypothesis. If content consistently ends up being unsuitable for a pattern:
• the purpose of the pattern wasn’t clear, or it wasn’t designed in a way that achieves it purpose, trying to force content into a pattern that it’s not right for
• The purpose > the structure of the pattern > the content > it’s presentation
• 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

Chapter 4: Perceptual Patterns

• Perceptual patterns are styles - they describe what kind of objects they are and how they feel
• E.g. tone of voice, typography, colour palette, layouts, illustrations, iconography, shapes and textures, spacing, interactions and animations.
• Effective perceptual patterns help differentiate your product. They change how your product feel (even if it’s in a similar domain, with similar modules).
• Styles applied purposefully and repeatedly form patterns. Perception is influenced by the relationships between the different style building blocks.
• In modular systems, achieving visual coherence and seamlessness can be tricky (especially in a team). Perceptual patterns permeate a system and connect the parts, providing a sense of unity that links the modules together.
• 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.
• E.g. small things like Twitters 💙 instead of a ‘like’ become markers for the brand
• Functional modules → reflect what users wand and need (behaviours and actions)
• Perceptual patterns → focus on what they feel or do intuitively (personality, ambience)
• 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)
• The team then identify how to bring those traits to life, through tone of voice, visually and in other ways, such as interactions and sounds.
• Different tools (from low to high fidelity)
• Mood Boards: explore visual themes
• Style Tiles: explore variations in more detail (essentially, designing a key part of a page)
• Element Collages: assembly of interface pieces that explore how branding works in the interface
• 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.
• Constrained, generic, rigid and stifled → Goldilocks Brand Zone ← lose, chaotic, sporadic, inconsistent
• Perceptual patterns can be concentrated in the smallest details - in signature moments and micro-interactions. An elegant loading animation or catchy sound. Teams struggle to prioritise these - but it’s the small details that add depth and meaning, and make something feel distinct.
• Do experiment on a small scale - and then integrate them into other parts of the interface if successful, else kill them off
• Be conscious of urgent business requirements forcing a solution that doesn’t sit well with the brand
• Team Signature Patterns Exercise:
• Ask everyone to write down the most distinct perceptual pattern for your product
• Think of the elements and the meaning behind them.
• Helps you surface and move toward a shared understanding of your important patterns

Chapter 5: Shared Language

• Creating a cohesive system requires a shared language.
• It empowers people to create products that feel whole, even when multiple contributors work on different parts.
• It takes a lot of effort to create a shared language in a product team
• Naming Patterns → by naming objects, we start bringing them into existence
• Well-chosen names are powerful tools in shaping your design system
• Names should be focused, memorable and embody the purpose of the module
• Think about what they help you/the user achieve
• The best names are metaphorical, have personality and communicate the purpose of the pattern
• Metaphors from other industries (like architecture) can inspire a good name
• Names with personality are easier to remember.
• Guidance or inspiration for where to use the specific pattern
• Open the naming process up to the team. Involve people in a slack channel, encourage suggestions and feedback. Give people kudos if they come up with the winning name.
• You can even test names with users, and bring their language into your design system
• Make your design patterns visible - create a pattern wall in the office. Position printouts in user journey order.
• Refer to objects by their names - to keep the language alive.
• 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
• Have regular deign system catchups - agree on patterns, share new modules, and discuss their purpose, usage and any problems people have
• Keep a glossary and an up-to-date pattern library as a reference point for the entire team.

Part 2: Process

Chapter 6: Parameter of Your System

• A design system doesn’t start and end with a building a pattern library.
• 3 dimensions of a design system
‣
1) Strictness of the rules (strict → loose)
‣
AirBnB: Strict
• precisely specified, design and engineering fully synchronised. Design modules have exact equivalents in code, names match, modules are cross platform
• synchronisation is a priority
• the team creates custom tools to achieve that
• strict process to introduce a new pattern - creation of new patterns is infrequent
• Comprehensive documentation
‣
TED · Loose
• Loosely set up. Brand feel and utility of the page are more important than visual consistency
• They design what is right - not what is consistent
• TEDs processes are more relaxed and informal
• No detailed specs, just low-fi sketches with notes
• They have a swatch file - but rely on shared design knowledge, rooted in the culture not the documentation
• Rely more on shared principles to guide designs. The shared knowledge is the foundation that allows the loose set up
• 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
• Create opportunities outside the system for experiments and side projects
• Clear and compelling documentation is important for strict systems
• Loose systems are suited to products that prioritise sensitivity to context and experimentation.
• Loose systems 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.
• Integrated
‣
3) Distribution of the organisation (centralised → distributed)
• A centralised 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.
• Conways law: organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations

Chapter 7: Planning and Practicalities

• Get support to build your design system - don’t do it as a side project.
• Collecting examples of visual inconsistencies
• Show how an effective design system will help to meet business goals faster and at lower cost
• Reusing elements saves time. 2x longer to build but almost free to use
• Collect examples of visual inconsistencies. Quantity the cost of duplicated effort.
• Buttons are incredibly complex, and hundreds of thousands to design and build
• Site-wide changes are fast and easy (vs time-consuming and fiddly)
• Universal patters can be updated everywhere the pattern is used
• An improvement to a component is realised everywhere - making it easier to maintain
• Possible to prototype and ship features faster → start by experimenting with existing components
• Brand unity at scale + visual consistency
• Makes it easier to scale the number of teams
• Where to start?
• Agree on your goals and objectives. For Example
‣
1) Systematise the interface
• Define design principles
• Define reusable design patterns
• Establish a pattern library
• Set up master design files
• Refactor code and front-end architecture to support the modular approach (a lot of work)
‣
2) Establish shared process and governance
• Set-up a knowledge sharing process
• Promote the pattern library and encourage usage
• Promote shared design language across-teams and disciplines
• Update the induction process to include a design system introduction
• Break down objectives into smaller tasks and create a roadmap
• Design systems are long term investments. Their value increases gradually over time. Set expectations that improvements will be gradual and steady.
• Make progress transparent - stick things on the wall, write blog posts.
• Share knowledge across teams and disciplines. Create a pattern wall, slack channels, catchups, workshops and tutorials to introduce new patterns.
• Dedicate each day to a new pattern
• Keep up team morale - aim to complete the bulk of the work in one go. Split into two phases if you don’t have enough time.
• Get the whole team involved in conducting an audit → promotes a shared sense of ownership. Then let a few people do the majority of the work.
• 80/20 principle - what tasks provide the most benefit for the least effort.
• Skip the engineering integration - or code representations, to make progress quickly.
• Exercise for systematising an interface:
• Identify key behaviours or aesthetic qualities
• Audit existing elements
• Define patterns

Chapter 8: Systemising Functional Patterns

• Products encourage or enable certain behaviours. Articulating them helps define patterns in a way that’s more future proof - because behaviours don’t vary by platforms
• Build a Purpose-Directed Inventory
• To define the most essential design patterns. To get a mutual understand in the team.
• Group ui elements by purpose (or behaviours) not by visuals.
• This would mean buttons and links would be together. And you’d look to define when to use each
• Non-Goal: account for all the inconsistency
• Do this after you’ve worked out the UX of your product.
• Include different disciplines (include design and front end)
• Identify the most important screens and user flows (10-12).
• Steps
1. Identify key behaviours. User needs and behaviours you want to support in each part of the journey
• note pages with conflicting behaviours → the most important actions should be clear and not in conflict with each other
• When you name behaviours - choose words carefully, they shape how we think
• Break down behaviours into actions (many actions make a behaviour)
• Some actions might be repeated throughout the interface BUT the elements that represent them aren’t always the same (duplication / opportunity!)
2. Group existing elements by purpose
• For each behaviour - look across all the pages to find the elements that support it
• Cut out and arrange the elements into groups and label each group
• These are pattern candidates
3. Define Patterns
• Decide how to deal with the items in each group. Should they be merged or kept separate?
• Use a specificity scale to help decide. From Specific to Generic. Deciding the level of specificity is the tricky part of modular design. The more specific the less reusable.
• E.g: Do we need a different pattern to advertise events vs advertising exhibitions
• Map out a patterns content structure. List the core content slots. Determine the hierarchy. Make sketches to visualise the structure. If you struggle to unify the elements without compromising their purpose - it’s an indication that they shouldn’t be merged.
• Create variants when elements have the same structure but need to look or behave differently. Select a default pattern.
• If I change this module - do I want others to change in the same way?
• Naming → 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.
• E.g. Buttons and Links
• Link: navigates the user away from the current page
• Button: submits an action and toggles something in the interface
• Consistency is key - users need to know what to expect.
• If the action occurs on the current page - use a CTA button.
• If the action takes the user away from the current context - use a CTA link.
• Calls to action are different links, which are pathways to optional information (typically embedded text, titles or images)
• Most interfaces have equivalents of primary and secondary buttons.
• Flat buttons can be necessary or mandatory actions
• Ghost buttons are optional or infrequent actions
• Atlassian → Primary buttons represent the most important action - should only appear once per screen
• Basic button as a default - other styles to flex up or down on importance
• Don’t be overwhelmed by the number of elements and patterns. Start with core patterns, fundamental to the experience.
• Do this regularly - it’s like gardening.

Chapter 9: Systemising Perceptual Patterns

• To influence perception - you need to be aware of the patterns that create it
• Even with a standardised colour palette - there’s room for interpretation, what variation should you use? how do they work together?
• You need to keep the meaning of the styles constant across the interface.
• Shared colours isn’t enough - you need shared use of colour in the context of the product
• Shared use of typography requires clear guidelines and patterns of usage which everyone can understand.
• With functional patterns - we look at behaviours first.
• With 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?
• Signature patterns kick-off exercise
• Ask everyone to write down the most memorable and distinct elements that make your product feel a certain way
• What styles and tones come to mind?
• How do users describe your aesthetic? Anything they like?
• Anything that feels off brand?
• List the colours and the proportions between them.

• For each style - systemtise 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
• Each one will need it’s own inventory.
• There will be overlaps (typography and spacing) - this is OK and it’s useful to see how things relate to each other
• Colour Example:
• Define: type of objects applied to, example, hex value and feel (emotion)
• Agree on the use of colour by defining design patterns: When do you use each? What is the meaning of a red CTA? What is the difference between a Black and Red heading?
• Specify building blocks. Reduce the number of variants that you need. Start with only what you need. If you have a light and dark mode - or do data visualisation, you’ll need many more colours.
• Test colour contrast with a WCAG contract ration tester
• Specify a base value - with 20% lighter and darker increments / shades / tints
• If your goal is to change the current design of your website - do it before you do your systematisation exercise
• Animations → follow the same process. Start with purpose, collect and group styles, define patterns and building blocks.
• Purpose - animation effects (colour, opacity, scale, sliding, pulsing, wiggling) - feel
• Animation concepts
• Timing → how long an animation takes (with distance speed is determined)
• Easing → how something is animated, e.g ease-in or ease-out (ease in = start slow and speed up)
• Animation is about feel.
• Voice and tone → often defined by a different team, get them involved.
• Audit voice and tone patterns.
• Define patterns - and formulate guidelines → Tone should shift to match the emotional condition of the user.
• Agree on guiding principles
• Summary → each style should be approached like a system in it’s own right. They should be interconnected and directed towards achieving a larger purpose.

Chapter 10: Pattern Libraries

• It’s hard to take a systematic approach to designing a product without a pattern library
• The library isn’t the system - it’s just a tool for documenting and sharing patterns.
• Agree on the main goals and objectives
• Break up objectives into stories and a roadmap for the system
• Make your progress transparent - by documenting and sharing it
• Create a culture of knowledge sharing.
• Practice thinking in systems - through experiments, workshops and group exercises
• Multidisciplinary pattern libraries are more resilient and enduring
• Don’t fall into the tool trap - just start documenting the content of the library (just use Google Docs if you’re stuck)
• Make sure everyone can use your tool, make edits and start using it as a reference right away.
• How to organise patterns → You can iterate on the structure later. Just make sure that the team are on the same page.
• Abstracting perceptual patterns → think of it as components and styles. Perceptual patterns are connected and work together. Abstracting them makes it easier to be aware of their role in the system.
• Refer to functional patterns as ‘components’
• Organise functional patterns for find-ability. Options: alphabetically, hierarchically, by type or by purpose.
• Alphabetical - avoids time consuming conversations about classification.
• Hierarchical - complexity (molecules < organisms < templates < pages)
• Helps with re-usability and consistency
• You’ll spend time debating classification
• Purpose or Structure - gives team guidance and inspiration for where to use a specific module - also fit with our purpose-directed approach for defining patterns.
• Make sure your choice is grounded in how people who use it will think
• Pattern Documentation → Many things can be documented alongside each pattern, but don’t try to do it all at once. Start with the important things and add as you go.
• Name - focused, memorable and embodies the purpose of the pattern. Make the names prominent.
• Purpose - Explain what the pattern is and what it’s for in as few words as possible.
• Examples / Recommendations - for using effectively (no more than 12 facts at no more than 3 lines)
• Variants - present alongside each other as a suite - list how the options are different from each other
• Contributors - include the people involved in the creation of the pattern
• Versioning - sometimes documenting changes to previous versions is helpful
• Related patterns - link to alternatives for similar use cases
• Documenting Perceptual Patterns → Focus on the building blocks (colour palette etc) BUT also show how those properties are used and how they work together
• Specify usage - not just building blocks
• Do’s and Don’ts format can be useful - certainly if you’re expecting misuse
• Cross-reference styles → Even if it means duplications, referencing styles as the module level, as well as separately is useful (so you get a feel for how things come together)
• Show the relationship between typography and spacing
• Show the relationship between buttons and interaction states
• Workflow: teams with effective pattern libraries have adapted them into their workflow
• Have a process for adding new patterns (agreed format, place to document, place to review and agree)
• Key Questions for new components: What is it? What is it for? How does it achieve it’s purpose?
• Teams struggle to agree what counts as a new pattern. Two approaches:
• Add everything
• Add things only once they’re re-used
• You can treat new components (promotional) as one-offs. Don’t make anything specific unless absolutely necessary. Consider if one-offs can be made more generic to help with other use cases
• If you have a design systems team - you might have ‘curator’ and ‘producer’ roles. The design system team should be seen as partners - not police.
• Aligning parts of the system → Code + Design + Pattern Library
• Approaches to naming, structure and understanding of purpose need to be the same
• If you’re aligned conceptually - it’s easier to sync code and design.
• Keep your pattern library up to date - the pattern library must be the source of truth. If you do, design and engineering can move closer together.