design-systems.md

Design Systems (2017)

Alla Kholmatova

---

▪ In recent years, web designers have started embracing more modular, pattern-driven design practices. And with good reason: we’re being asked to create compelling experiences for more screens, more devices, more places, more people than ever before. As a result, we’ve started to break our interfaces down into tiny, reusable modules, and begun using those patterns to build products, features, and interfaces more quickly than ever before.

▪ But by themselves, design patterns aren’t enough. They need to live within a larger process, one that ensures these little interface modules feel unified, cohesive, connected. Part of a whole. In other words, they need a design system to thrive — and that’s where Alla’s book comes in.

▪ Alla shows us how to establish a common, shared language among our teams, which allows us to more effectively collaborate; she’ll tell stories of how different organizations have created their design systems, and put them into practice; and she’ll discuss different models for evolving these systems over time.

▪ Alla has drawn a clear, bright map for us, one that outlines a more sustainable model for digital design. And if we walk the paths she’s drawn for us, we’ll learn to grow better design systems — and with them, better designs.

▪ What are the key qualities of a well-functioning, enduring design system? This question intrigued me so much I spent a huge amount of time researching and thinking about it.

▪ Throughout the book, I distinguish between functional patterns related to behaviors, and perceptual patterns related to brand and aesthetics.

▪ As the web continues to change rapidly and become more complex, thinking of it in terms of static pages has become untenable, and many of us have started to approach design in a more systematic way.

▪ And yet not all design systems are equally effective. Some can generate coherent user experiences, others produce confusing patchwork designs.

▪ Some inspire teams to contribute to them, others are neglected. Some get better with time, more cohesive and better functioning; others get worse, becoming bloated and cumbersome.

▪ This book is aimed mainly at small and medium-sized product teams trying to integrate design systems thinking into their organization’s culture.

▪ This is a design book, but it isn’t about what to design. Neither is it an attempt to create a comprehensive guide to designing digital products.1 It is about how to approach your design process in a more systematic way, and ensure your design system helps to achieve the purpose of your product and fits with the culture of your team.

▪ Patterns interconnect, and together they form the language of your product’s interface. Shared practices are how we choose to create, capture, share and use those patterns — by following a set of principles, or by keeping a pattern library.

▪ A design system cannot be built overnight — it evolves gradually with your product. But there are certain principles and practices that we can follow to make sure the system develops in the right direction and provide us some degree of control over it.

▪ I use the word pattern to refer to any repeating, reusable parts of the interface (such as buttons, text fields, iconography styles, colors and typography, repeating user flows, interactive behaviors) that can be applied and repurposed to solve a specific design problem, meet a user need, or evoke an emotion.

▪ Functional patterns or modules These terms are used interchangeably throughout the book, to refer to tangible building blocks of the interface, such as a button, a header, a form element, a menu.

▪ Perceptual patterns or styles These are more descriptive and less tangible design patterns, such as iconography styles or colors and typography, typically used to create a certain kind of aesthetic and strengthen an emotional connection with a product.

▪ Pattern language or design language A set of interconnected, shareable design patterns forms the language of your product’s interface. A pattern language combines functional and perceptual patterns, as well as platform-specific patterns (such as the hamburger menu), domain patterns (such as modules specific to an e-commerce site, or finance software, or a social app), UX and persuasive patterns, and many other types meshed together in an interface for a specific product.

▪ There isn’t a standard definition of “design system” within the web community, and people use the term in different ways — sometimes interchangeably with “style guides” and “pattern libraries.”

▪ In this book, by design system I mean a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.

▪ Pattern library and style guide A pattern library is a tool to capture, collect and share design patterns and guidelines for their usage. Creating a pattern library is an example of a (good) design practice.

▪ Traditionally, a style guide focuses on styles, such as such as iconography styles, colors and typography, while a pattern library includes a broader set of patterns.

▪ five other companies of different sizes and approaches to design systems: Airbnb, Atlassian, Eurostar, Sipgate, and TED

▪ Airbnb4

When interviewed in August 2016, Roy Stanfield (Principal Interaction Designer) gave me plenty of detail about the Design Language System5 at Airbnb.The distinguishing aspect of DLS is its strictness. Patterns are specified and used precisely and rules are followed closely. The team has placed a number of practices and tools in place to achieve that.

▪ While there’s a dedicated team who curates the patterns, they also have an open source model for contributions. Everyone in the company is not only allowed, but actively encouraged to contribute to the system. The challenge with this model is to find a balance between giving people enough freedom to contribute, yet making sure the system stays managed and curated.

▪ The Sipgate pattern library11 was established in 2015, but after a year the team found that there were too many patterns, mainly due to a lack of communication between the product teams. More recently, they were in the process of working on a new pattern library, with a goal to unify the design language across several product websites.

▪ Among the many people who support TED.com, a small handful of UX practitioners and front-end developers are responsible for design system decisions.

▪ So far they haven’t felt a need to establish a comprehensive pattern library.

▪ Pattern libraries are sometimes thought of as interchangeable with design systems. But even the most comprehensive and living pattern library is not the system itself. It’s a tool that helps to make a design system more effective.

▪ The effectiveness of a design system can be measured by how well its different parts work together to help achieve the purpose of the product.

▪ There isn’t a standard definition of “design system” within the web community and people use the term in different ways. In this chapter, we’ll define what a design system is and what it consists of.

▪ A design system is a set of interconnected patterns and shared practices coherently organized to serve the purpose of a digital product.

▪ Patterns are the repeating elements that we combine to create an interface: things like user flows, interactions, buttons, text fields, icons, colors, typography, microcopy.

▪ Practices are how we choose to create, capture, share and use those patterns, particularly when working in a team.

▪ The choice of design patterns is influenced by many factors. Some of them come from the domain the product belongs to, and from its core functionality: those are functional patterns.

▪ To use trading and market analysis software, for instance, you’d need to be accustomed to task bars, data fields and grids, charts and data visualization tools. For an online learning site, it could be articles, videos, discussion threads, progress indicators and interactive activities.

▪ An e-commerce site would most likely include a product display, list filters, shopping cart and a checkout.

▪ By that I mean things like tone of voice, typography and color choices, iconography styles, spacing and layout, specific shapes, interactions, animations, and sounds.

▪ Without perceptual patterns you wouldn’t feel that much difference between products from within the same domain, which have similar functionality.

▪ Although HipChat and Slack have similar purposes and functionality, they feel quite different, largely due to how brand is expressed throughout their interfaces.

▪ There are many kinds of patterns at play when it comes to creating a digital product. That’s why design is hard.

▪ Patterns need to interact, connect, yet still work seamlessly together.

▪ The idea of design patterns was introduced by the architect Christopher Alexander in his seminal books, The Timeless Way of Building and A Pattern Language.

▪ A pattern is a recurring, reusable solution that can be applied to solve a design problem.

▪ “Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem.” — Christopher Alexander, A Pattern Language

▪ A Pattern Language contains 253 architectural design patterns, starting from the larger ones, such as a layout of a city and road systems, down to the smallest ones, such as lighting and furniture in a family house.

▪ We use patterns to offer feedback, to show how many steps are left in a process, to allow people interact with each other, to view and select items. Design patterns can intrigue and encourage, make tasks easier, create a sense of achievement or an illusion of control.

▪ Example of persuasive pattern “recognition over recall” on UI Patterns3.

▪ Most of the design patterns are established and familiar. They make use of people’s mental models and allow design to be understood intuitively.

▪ Entirely new patterns require users to learn and adopt them first — they are relatively rare.

▪ What makes a product distinct from its competitors is not the novelty of patterns it uses, but how those patterns are executed and applied, and how they interconnect to achieve a design purpose

▪ A set of interconnected patterns forms the design language of your product’s interface.

▪ A design language emerges as we work on a product. We don’t always know what this language is.

▪ In his article “Researching Design Systems,”7 designer Dan Mall noted that one of the main goals of a design system is “extending creative direction.”

▪ If you need to get a group of people to follow a creative direction consistently, reliably and coherently, patterns need to be articulated and shared.

▪ The visual loudness guide6 by Tom Osborne is an example of how buttons and links can be approached systematically. Instead of listing them individually, they are presented as a suite, each one having a different “volume” corresponding to its intended visual prominence.

▪ Articulating your language allows you to gain more control over the system.

▪ Instead of spending hours on designing a dropdown, you can spend that time with the users and domain experts, finding out if a dropdown is needed in the first place.

▪ When the design language is shared knowledge, you can stop focusing on the patterns themselves and instead focus more on the user.

▪ To extend the analogy with language, functional patterns are a bit like nouns or verbs — they are concrete, actionable parts of the interface; whereas perceptual patterns are similar to adjectives — they are descriptive. For example, a button is a module with a clear function: allow users to submit an action. But the typographic style in the label of the button, its shape, background color, padding, interactive states and transitions are not modules. They are styles; they describe what kind of button it is.

▪ From a front-end perspective, modules always have a basis in HTML, and perceptual patterns are typically CSS properties.

▪ What exactly is a button? An outlined area that you can click on? An interactive element on a page that links somewhere? A form element that allows users to submit some data?

▪ In her book How to Make Sense of Any Mess, Abby Covert suggests that a shared language should be established before you think about interfaces, by discussing, vetting and documenting our language decisions.

▪ It’s not only about developing a shared language — we need also to develop a shared use of language. It’s not enough to have a shared understanding of the term button. People must also know why and how to use a button, in what contexts, and the purpose a button can serve.

▪ Ideally, everyone involved in the creation of the product should know what this element is: its name and purpose, why it’s been designed that way, and how and when it should be used.7

▪ It should be known to everyone as “Sequence,” not “Wizard control” or “Fancy bubbles.” If designers refer to it as “Fancy bubbles,” developers call it “Wizard control” and users interpret it as set of optional tabs, then you know your language doesn’t work.

▪ If the user has a mental model of the interaction that doesn’t fit with the system image provided by the design team, then the user will be continually challenged by unexpected behavior from the system.

▪ An effective design language bridges the gap between the system image and the (assumed) user model.

▪ As your language becomes richer and more complex, you need an efficient way to capture and share it.

▪ A design system consists not only of patterns, but also techniques and practices for creating, capturing, sharing and evolving those patterns.

▪ A pattern library is a tool to collect, store and share your design patterns, along with the principles and guidelines for how to use them.

▪ Even though pattern libraries have become popular on the web relatively recently, the concept of documenting and sharing design patterns in various forms has existed for a long time.

▪ Palladio’s The Four Books of Architecture, first published in 1570 in Venice, is one of the most important and influential books on architecture. It is also one of the earliest examples of system documentation. Drawing inspiration from Greco-Roman architecture, Palladio provided rules and vocabulary for designing and constructing buildings, including principles and patterns, with detailed illustrations and explanations of how they work.

▪ In modern graphic design, systems have also long been documented, from early typography and grid systems, to Bauhaus design principles. For the last few decades, companies have documented their visual identities in the form of brand manuals, with NASA’s Graphics Standards Manual from 1975 being one of the more well-known examples.

▪ On the web, pattern libraries started as extended brand identity documents that focused on logo treatments, corporate values and brand styles, such as typography and color palettes.8

▪ Yahoo’s pattern library was one of the first examples of documented interface patterns.

▪ For companies less resourceful than Yahoo, a pattern library would typically live in a PDF or a wiki, which meant that it was static and difficult to keep up to date. The aspiration for many designers and developers today is a more dynamic or “living” pattern library that contains the design patterns, as well as the live code used to build them.

▪ MailChimp’s pattern library9 is one of the most influential early examples of living pattern libraries on the web.

▪ A pattern library doesn’t guarantee a more cohesive and consistent design. It might help to correct small inconsistencies or make a codebase more robust, but a tool alone will have very little impact on the user experience. No pattern library will fix bad design. Patterns can still be badly designed, misused or combined in ways that don’t work as a whole.

▪ As Michael McWatters, UX architect at TED, noted in an interview: “Even a SquareSpace template can be ruined by sloppy design thinking.” And conversely, a product with a coherent user experience can be created without a comprehensive pattern library (as we will see in chapter 6 in the example with TED’s design system).

▪ A living pattern library is associated with better collaboration. Yet you might end up in a situation where only a small group of people uses it, or there might be too many disconnected patterns as a result of a lack of communication between the teams.

▪ When up-to-date, a pattern library is a glossary for the shared language. But that doesn’t mean there isn’t still room for interpretation. It’s the discussions around the interpretation which are often the key to a pattern library’s success or failure.

▪ On the other hand, pattern libraries are sometimes blamed for stifling creativity, leading to generic looking websites. But again, a pattern library reflects the design system behind it. If your system is fundamentally rigid and restricting, the pattern library can reveal and emphasize the rigidity.

▪ For example, the purpose of FutureLearn is “to inspire lifelong learning in everyone, anywhere.” We could ask, how effective is the design language of the interface to help us achieve this, and how effective are the practices of the team?

▪ If the interface is confusing and people don’t achieve their goals, then the design language is not effective.

▪ A design system can be considered effective when it combines cost-effectiveness in the design process, and efficiency and satisfaction of the user experience in relation to the product’s purpose.

▪ In Thinking in Systems, Donella Meadows explains that one of the most important qualities systems have is how they’re connected and organized: subsystems are aggregated into larger systems, which in turn form part of something larger.

▪ Your design system might have a smaller subsystem within it: editorial rules to control the layout of the page; or it might include a method for scaling your logo responsively in a certain way. At the same time, it is also part of other larger systems: your product, your team, your company culture.

▪ In highly effective systems, we see that subsystems are connected and aligned toward a shared purpose: a design approach is mirrored in the front-end architecture; design patterns follow the guiding principles; the pattern language is applied consistently in design, code and the pattern library. We see harmony in the way those systems function: their workflow is more efficient, and the user experiences they generate feel more meaningful and coherent.

▪ When there are gaps, it’s also easy to see them. A fragmented design system leads to a fragmented user experience, full of conflicting messages. We want the user to sign up for our newsletter, but we also want them to check out our latest products.

▪ We want them to progress through the steps, but we also need to make sure they rate each recipe. “Sequence” is used to preview the steps in one area of the site; in another, it is suddenly a tabbed navigation. The interface is full of various shades of the same color and multiple versions of the same button. The team’s productivity is also affected: making the tiniest change is time-consuming and fiddly because of the confusing, tangled up code. Designers spend their time copying pixels and reinventing solutions to the same problems, instead of understanding and solving real user needs.

▪ We understand the domain of cooking, and enough research has already been done to inform our design decisions. So what we’re trying to do is not figure out what the experience should be, but see how we can establish design system thinking for this new website.

▪ One of the first things we’d do is try to understand who our users are, their goals, needs and motivations. To keep it simple, let’s say that we know they are busy professionals and their goal is to get a tasty, healthy meal without hassle and hours spent cooking.

▪ If we were to express the purpose in a single sentence, it would be along the lines of: Motivate and empower people to cook delicious healthy meals in no more than ten minutes. This purpose is the core of the product, and it should inform design and development decisions. The team should recognize that purpose and believe in it — it shouldn’t feel forced.

▪ For example, everyone on the ten-minute cooking recipe site team understands the value of time. They are motivated by having a time limit on the recipes, and as a result they all strive to make interactions on the site short, simple, fast and smooth. This principle will be expressed not only through design patterns, but the performance of the site, its tone of voice, and even how the team operates

▪ These principles might not necessarily be official or even written down. But having an agreement and awareness in the team on what they are is essential to keep everyone’s effort and priorities in sync. It can also help with decision-making: from which feature to build first and which approach to use, to working out UX flows, or how buttons should look and the choice of typeface.11

▪ Naturally, the design details will change as we work on the site, but those key behaviors would remain the same. Those behaviors will inform the core functional modules and interactions of the site: ingredient thumbnails, recipe cards, step sequence, timer.

▪ Around the same time, we’d need to work out how we want to be perceived by someone using the ten-minute cooking recipes site. Are we simple and down-to-earth or glamorous and sophisticated? Are we serious or playful? Bold or subdued? Utilitarian or emotional? What are the aesthetics that capture the personality and ethos we want to portray through the interface? We’d start thinking about the brand.

▪ At this point we would probably put together some mood boards and start experimenting with visuals until the brand feels right.13 Once we achieve this, we can define core visual brand elements such as typography, color palette, tone of voice, and any distinguishing features of the brand; for example, illustrations, image styles, specific shapes, unique interactions that capture the essence of our service and present content in the best way.

▪ Shared Language

Alongside this process we will be making language decisions by choosing to refer to concepts in certain ways. What is a “recipe”? What do we mean by “steps”? What makes a “delightfully simple” interaction? The words we choose will influence how the team thinks. And indirectly, they will shape the design.

▪ At first, the patterns and language choices will be shared informally. But as our team and the product grow, so will the language. Eventually we’ll need a more structured way to capture, share, and organize our design vocabularies.14

▪ 1.The patterns on FutureLearn are chosen to support reflective learning. The learner needs to focus on the task at hand and not be distracted by displacement activities. The goal was to create an atmosphere that feels calm and contemplative.

▪ 2.The website UI Patterns is a great source of common design patterns, grouped by purpose and the design problem it solves. For a comprehensive read on UI patterns, I also recommend Designing Interfaces: Patterns for Effective Interaction Design by Jenifer Tidwell.

▪ 4.Until the swipe gesture had emerged as a mobile pattern, no one would have known how to engage with it. Now we see whole products built on this pattern (such as Tinder). The transition to using what people know and exploring something new is very delicate; products live and die based on when and how they do this.

▪ Having clarity on the purpose is paramount because all other decisions should be shaped by it, even if indirectly. How do we make sure that the purpose of the product is manifested through design? By establishing a few grounding values and principles.

▪ In some companies, especially early on, trying to articulate shared guidelines can be hard. Design principles are not something that can be measured and quantified, and defining them can take a few iterations. There might also be some confusion about what principles are exactly. Depending on the company, they can be more focused on the brand, the team culture, or the design process.

▪ The principles at Pinterest1 are more brand-focused (“Lucid,” “Animated,” “Unbreakable”), whereas at the UK’s Government Digital Service2 (GDS) they’re directed more at how the team operates (“Do less,” “Iterate. Then iterate again”).

▪ Sometimes principles are used for a limited time, for a specific project. Designer Dan Mall likes to write a “design manifesto” at the start of every project, to make sure creative direction and objectives are clearly expressed.3

▪ Larger companies might have separate sets of principles for the user experience, the brand and the design system.5

▪ Additionally, each team working in a company might also have their own team principles.

▪ While this works for some, others can find that having multiple sets of guidelines can contribute to a design system’s fragmentation.

▪ “It is one system. The principles are there to connect the dots.” — Jürgen Spangl, head of design, Atlassian

▪ Principles

Approaches to design principles are unique to every company and can take many forms. Principles can be overarching or more granular, temporary or long-lasting.

▪ In the context of this book, design principles are shared guidelines that capture the essence of what good design means for the team, and advice on how to achieve it; in other words, agreed criteria for what constitutes good design in your organization and for your product.

▪ I’m sure you’re familiar with these principles: “Simple. Useful. Enjoyable.” They are ubiquitous, we hear them everywhere. There’s no argument that products that are designed well follow a certain set of common principles (take Dieter Rams’ ten commandments of good design, for example). But qualities like these should be a given — they should be done by design — along with other concerns, such as accessibility and performance. I’ve yet to see a consumer digital product which has “Complex,” “Useless,” and “Painful to work with” among its principles.

▪ Knowing that your product should be useful and enjoyable is not going to be hugely helpful in guiding your design decisions, because these qualities can be interpreted in a variety of ways. What would make them more helpful is knowing exactly what those words mean to your team and your product. What does innovative entail? When is a design considered useful? How do you know if it’s really delightful? Good design principles define qualities that can be interpreted in different ways, and ground them in the context of a specific product.

▪ If you tell them “We like things to be delightful here. Make it delightful!” it’s probably not going to help them do their job. You’d need to define what delight means and share practical examples of what delight looks like in the context of your interface.

▪ But even the best-worded principle can still be interpreted in a variety of different ways. Nothing can make a principle more practical than pairing it with a real-life example to show how it can be applied in practice. Find specific parts of your interface where a principle is clearly represented and connect the two together. Can you point to a place which clearly shows having “only one number 1 priority”? Can you demonstrate how a pattern can be truly “unbreakable” despite having rich interactions?

▪ One of the challenges I’ve had in my work as a designer is working out how to materialize higher-level concepts, such as design principles and brand values, into concrete UI elements. How exactly are they embodied in the design patterns we create?

▪ Treat Content as a Hypothesis

Here’s a paradox. We’re expected to design content-first, but at the same time we’re expected to build modules in a way that can fit any kind of content. A way to do this is not necessarily by starting with content, but with the purpose. Then we can treat content not as a known asset but as a hypothesis. This allows us to test if we’ve defined the purpose of the module well, and if the design works for that purpose.

▪ Functional patterns are the tangible building blocks of the interface. Their purpose is to enable or encourage certain user behaviors.

▪ On the ten-minute cooking site, some of those behaviors included selecting ingredients, choosing a recipe, and following steps within an allocated time. The functional patterns we design will be informed by those behaviors.

▪ Functional patterns, or modules1, are largely shaped by the domain a product belongs to. The patterns in our cooking app would be quite different from, say, finance software. Instead of recipe cards we’d be dealing with task bars, data fields, grids, charts and graphs.

▪ Functional patterns can be simple or they can combine to create more complex patterns. A recipe card is made of a meal title, image, ingredients, and an action button. Each module within the recipe card has its own goal: the title tells us what the meal is; the image provides a preview of the final result; ingredient icons allow us to scan the cards more easily. Together, those modules help to achieve a shared purpose: to encourage people to cook the meal shown on the recipe.

▪ As the product evolves, so do the patterns. We might start allowing our users to rate the recipes, and the rating display will become part of the recipe card. Or we might decide that the layout of the card can be improved, or that ingredient icons should be made clearer, or that we need to introduce a compact version of the card. We test and iterate the patterns to try to make them work better to achieve their purpose; that is, encouraging the behaviors more effectively.

▪ These patterns went through a few changes after they were first designed over three years ago. Their styles, and even functionality and interactions, have changed. Yet their purpose fundamentally stayed the same, as it’s connected to the core idea of how FutureLearn works.

▪ As often happens in the early start-up days, because of time constraints and other priorities, many core functional patterns weren’t defined. As FutureLearn’s interface and educational functionality grew, patterns were duplicated. We ended up with several course progress modules, variations of a comment module, and a few different course blocks and course cards across the site. Perhaps this was inevitable. Or could some of those duplications have been prevented?

▪ Defining patterns early in the design process doesn’t have to take a lot of time. There are techniques that can be integrated into your process without extra effort. Here are a few that I find particularly helpful.

▪ To map out your customers’ needs, goals and motivations you might have done customer experience mapping2, “job to be done,”3 or a similar exercise around customer journeys. The outcomes typically feed into the early design explorations and prototypes. At this point, there’s usually a fairly clear understanding of the behaviors we want to encourage or enable in our users: learn about a course, join a course, engage in a discussion. But once we focus on the interface, sometimes we get lost in the details.

▪ In other words, we lose the connection between user behaviors and the exact patterns that encourage or enable those behaviors.

▪ Keeping this map in my mind helped me to think in families of patterns joined by a shared purpose, rather than individual pages. For example, instead of designing a course list page, I’d think of the “Discovery” area as a whole.

▪ The interface inventory process4, described by Brad Frost, has become a popular way to start modularizing an interface. The idea is simple. You print out the screens of your interface on paper, or collect them in Keynote or PowerPoint. You then separate out various components either by cutting them out or pasting them in Keynote.

▪ An inventory doesn’t have to encompass everything (although the very first one you do should be comprehensive). It can focus on one pattern group at a time, such as promotional modules, headers, or all the product display modules. You can do an inventory focused specifically on typography, or color, or animations.

▪ To be most effective, interface inventories should be done regularly. Even if your team maintains a pattern library, new patterns will emerge that need to be folded into the system. If you get into a habit of running inventories every few months, each time shouldn’t take more than a couple of hours. And every time you do it, you understand your system better and can improve it.

▪ To understand the purpose of a pattern, try focusing on what it does rather than what you think it is. In other words, try to find an action that best describes the behavior a pattern is designed for. Describing a pattern with a verb rather than a noun can help you to broaden potential use cases for a pattern and define its purpose more accurately.

▪ But by describing a pattern in this way, you could be making it too specific to its presentation or content. You might end up limiting its use to a particular context. On the other hand, if you define it in terms of actions — from your user’s perspective as well as your own — you can uncover its purpose: “Promote a course” and “Discover a course”; and “Get inspired to join a course” and “Encourage people to join.” By focusing on the action, you connect pattern with behavior and keep it open for various use cases. What else can this pattern promote?

▪ Once you have a shared understanding of a pattern’s structure, it’s easier to make sure that the way the module is designed is reflected in the markup. A designer can work on the visual explorations, while a developer can start putting together a prototype (or both can prototype, depending on how you work). Designers understand how much they can push a pattern visually before it becomes something different. Developers know the reasons for the design choices and don’t get unexpected designs thrown to them over the wall. Everyone is aware of how the pattern is constructed and how changing it will affect other places.

▪ Try placing similar patterns on a scale, in relation to one another. For example, there could be a few promotional patterns in your system, with varying degrees of intensity. Similar to the visual loudness scale7 I mentioned in chapter 1, promotional modules can be compared with one another.

▪ We could define its purpose as “Supporting the main message with additional bits of easily scannable information.” The “bits” could be key features, short pieces of advice, or quick steps. We can build a pattern for content that fits this hypothesis (concise and scannable, supplementary rather than the main content on the page), and then test it.

▪ When we don’t start with the purpose and the structure, we can end up with modules that are too closely tied to their content. For example, we had a case at FutureLearn where the copy was pushing important tabs below the visible area.

▪ An example of a fragile module, which was too specific to its content.

▪ The tabs were meant to stay visible. To get around the problem, we almost introduced a custom smaller size heading, simply to nudge the tabs up a bit. But had we done that, we would have ended up with a module that wasn’t robust. If the title got longer or if we added an extra line, we would have been stuck with the same problem. Had we started with the purpose of the module and its structure, the tabs would probably have been placed at the top, since they’re such an important element of design.

▪ The purpose determines everything else that follows: the structure of the pattern, its content, its presentation. Knowing the purpose of the pattern (knowing which behaviors it’s designed to encourage or enable) can help us design and build more robust modules. It can help us know how much a pattern can be modified before it becomes something entirely different.

▪ Being clear on the purpose also makes it easier to test the patterns to see how effective they really are.

▪ If functional patterns are objects in the interface, then perceptual patterns are more like styles — they describe what kind of objects they are and how they feel.

▪ If we had to make a distinction between the two, I see functional patterns in a more generic way, as a kind of a Platonic ideal, and modules as the embodiment of functional patterns, which can be different in different interfaces.

▪ Imagine we both have a house, with the same set of furniture: a table, a few chairs, a bed, and a wardrobe. Even though the furniture is the same, our houses can feel distinctly different: it could be because of the style of the furniture, the materials, colors, textures, the fabric on the bed covers, the style of the ornaments, how we lay out the room, the lighting, or even the music we play inside. I refer to such attributes as perceptual patterns.

▪ Examples of perceptual patterns in digital products include tone of voice, typography, color palette, layouts, illustrations and iconography styles, shapes and textures, spacing, imagery, interactions or animations, and all the specific ways in which those elements are combined and used in an interface.

▪ Perceptual patterns are always present, even if they’re not purposefully designed. Even a purely functional tool has an aesthetic.

▪ Products can feel different, even if they belong to the same domain and have similar modules. To write this book I tried dozens of word processors with very similar functionality. Only a couple of them, including the one I’m using now, had the kind of writing environment that helped me focus and be most productive.

▪ 3.Spotify’s vision “The right music for every moment” and their design principle “emotive” are inline with the feel created through perceptual patterns.

▪ Designing for Emotion by Aarron Walter (see also “Personality in Design”)

▪ For great practical advice on designing microinteractions and integrating them into a product, see Microinteractions: Designing with Details by Dan Saffer.

▪ Digital products are built by teams. Everyone will have their own specific goals to accomplish and personal deadlines to meet. Inevitably, this means that sloppy patterns will be added, or that modules will be duplicated or misused.

▪ Can we make sure a product still feels cohesive and whole, even when many people work on it? Yes, if we have a shared understanding in the team of what our design system is and how it works.

▪ In The Timeless Way of Building, Christopher Alexander introduced the idea of a “pattern language” as a way to create buildings that feel alive and a pleasure to be in.

▪ At the core of his book is the observation that many great buildings (Chartres, the Alhambra, Brunelleschi’s Dome) weren’t created by one master architect working laboriously at the drawing board. They were built by groups of people who all had a deep, shared knowledge of the design patterns that were capable of bringing those buildings to life.

▪ “…groups of people can conceive their larger public buildings, on the ground, by following a common pattern language, almost as if they had a single mind.” — Christopher Alexander, The Timeless Way of Building

▪ A similar idea can be applied to building digital products. The language can empower people to create products that feel whole, even when multiple contributors work on different parts.

▪ But what Alexander doesn’t mention in his book, is exactly how much work the pattern language approach takes to achieve. Medieval cathedrals took decades to build, and stonemasons went through years of apprenticeship to learn the pattern language. Similarly, it can take a lot of effort to establish a shared language in a product team and make it work.

▪ James Britton, an influential British educator, explains in Language and Learning1 that by conferring names on objects, we start “bringing them into existence,” just like children use language “to draw out of nothingness” the world around them.

▪ “The main problem with presentation based naming is that you can’t find what you are looking for when the number of patterns in your library increases. It also gives you no guidance or inspiration for where to use a specific pattern. People start to build more and more new patterns instead of reusing and enhancing the existing ones, which makes the problem worse and worse over time.” — Tobias Ritterbach, experience owner, Sipgate

▪ Like with any language, you need to use it to keep it alive. It needs to be part of day-to-day conversations. That’s why it’s important to make a conscious effort to keep referring to the patterns by the names you agreed on — no matter how bizarre this might sound.

▪ Until we gave it a proper name, we kept referring to it as “that thing with the lines and an icon in the middle.” It was easy to call it that. It took more effort to start calling it “Whisperbox.” But until you start calling a pattern by its actual name, it doesn’t exist in your system as a solid actionable block to work with.

▪ And every time you do use the name, you strengthen the element you call on, and evolve your design language.

▪ It can be hard, especially if you’re not used to it (imagine you joined a team where everyone is talking about minions, bosses and whisperboxes!). But very soon those names become part of a normal conversation and people get used to it. The goal is to get to the point where everyone knows exactly what you’re talking about just by calling a name. Everyone knows the purpose of sequence navigation and refers to it as “Sequence navigation,” and not “Fancy bubbles” or “Wizard control.”

▪ At FutureLearn, we created an internal induction online course, which includes a dedicated chapter about the pattern library, with quizzes and bite-size lessons.

▪ Everyone hates meetings. But design system catch-ups are worthwhile if you want to keep everyone on the same page when evolving your system. It’s the time when all designers and developers can fully focus on the system together.

▪ In any team there will be people who are more fluent in your pattern language and more enthusiastic to work on the system, and they might naturally gravitate towards working with each other.

▪ One of the most effective practices for sharing and evolving a design language is to keep a glossary of the terms you use

▪ Creating and keeping a glossary allows you to be consciously aware of the words you use, as you have to articulate things to write them down

▪ rite them down. For example, at Intercom, a customer messaging platform, the team keep a glossary of terms to make sure they use “the same language from code to customer.”

▪ The Intercom Glossary8

▪ And, of course, an up-to-date, easily accessible pattern library can also be a reliable glossary of design patterns and a reference point for the entire team (as well as being the actual toolkit of patterns for designing and building an interface).9

▪ The value of a glossary is not only in the tool it provides: it is also in the language practices it cultivates.

▪ By establishing and keeping a glossary, you get into a habit of vetting, discussing and articulating your language decisions as a team — you acknowledge that words matter.

▪ Not all teams are equally collaborative and open to discussing design principles and patterns every day. Establishing a shared language requires a certain kind of team culture. But it can also work the other way around — integrating language-focused processes can lead to better collaboration.

▪ Establishing a shared language is always a gradual, piecemeal process. Sometimes it will be messy and slow, but if you just keep going, you’ll see your language evolving and strengthening.

▪ Purpose

The purpose of a design system is to help achieve the purpose of the product: “Cook a healthy meal in ten minutes”; “Spread the talks as far and as wide as possible”; “The right music for every moment.” Everything in a system — from how a team operates, down to the smallest pattern — should be optimized toward that purpose.

▪ Principles

Teams choose how to achieve the product’s purpose through design. Their design approach and priorities can be captured in a set of principles: “Design for first impressions”; “Appropriate over consistent”; “Timeless, not cutting edge.” The more aligned the team are on their principles, the more cohesive the patterns they create.

▪ Through the interface we aim to help people accomplish certain goals and feel a certain way: learn a new recipe; focus on writing; feel productive; feel inspired. Our design intent is rendered through design patterns.

▪ Functional patterns support user behaviors and actions: “select ingredients,” “choose a recipe,” “follow recipe steps,” “rate a recipe.”

▪ Perceptual patterns focus on how a product should feel intuitively: “utilitarian,” “newspaper-like,” “openly enthusiastic.”

▪ The purpose of the patterns needs to be thoroughly understood by the team. Only then can we make sure it is interpreted as intended by our users.

▪ The patterns should be connected through a shared language — a deeply rooted knowledge in the team about how to create and use design patterns for a particular product to create effective and coherent user experiences. This knowledge is propagated through a shared design approach, front-end architecture, brand vision, and daily practices such as collaborative naming, cross-discipline pairing, making patterns visible, conducting regular interface inventories, and maintaining a pattern library

▪ The language should be evolved, strengthened, iterated and continuously tested.

▪ A design system is not built overnight, but shaped gradually, through our daily practices.

▪ If you are working on a digital product, the foundations of your system probably already exist.

▪ One way or another, interfaces are designed and built, and end up in front of users. Unless this process is entirely random, you have a system. The question is, what kind of system is it? Is it flexible and adaptable, or is it designed for one specific purpose? Is it cohesive or fragmented? Is it easy to work with, or is it time-consuming? Does your system thrive on freedom and autonomy, or is it strictly hierarchical?

▪ To make a design system more effective, we need to know how it works, what it consists of, what makes it function well and what doesn’t. If we don’t have this knowledge, the same problems keep occurring (systematically!).

▪ We tidy up all the buttons and six months later end up with too many buttons again. We can solve a problem but if the mechanism that created it remains, the same problem will keep coming back.

▪ Different design systems work in different ways. Your organization, team culture, design approach, the project, and even the physical space you’re in, will shape your system.

▪ To see how these factors play out, I find it useful to characterize design systems using three attributes: strictness of the rules, modularity of the parts, and distribution of the organization.

▪ Airbnb has over 2,000 employees worldwide and around 60 product designers working across multiple work streams. The system is managed entirely by their Design Language System (DLS) team which consists of six designers and their engineering partners for web, native mobile, and React Native platforms.

▪ •It’s cost-effective, because those modules can be reused

▪ •They can be built quicker as one-offs, because there’s no need to spend time on making the parts reusable

▪ •They are easier to coordinate, since everyone on the team works towards one purpose

▪ To become cost-effective, modules need to be reused, which can take time. Some teams struggle for a while to see a return on investment in a modular system, which makes it hard to justify the investment in the first place.

▪ All the product teams documented their patterns diligently and efficiently. There was no shortage of enthusiasm. But a year later, there were so many modules that it became extremely difficult to find the one they were looking for, and to understand which one to use. It became easier to just add a new one. After a year of maintaining a pattern library, their product websites were still full of duplicated patterns, albeit thoroughly documented ones.

▪ A design system doesn’t start or end with building a pattern library. There are many factors that shape a system: the structure of your organization, your team culture, the type of product you’re working on, and your design approach, among other things.

▪ Some systems are strict, others benefit from being more loosely set up.

▪ The design system at Airbnb is strict: there are precise rules and processes in place that are rigorously followed.

▪ In Airbnb’s system, design and engineering are fully synchronized. Specifically this means three things:

•Design modules in the master Sketch file have an exact equivalent in the code, and they are in sync.

•Names in the Sketch file and the code match.

•All modules are cross-platform: every component drawn in the Sketch file has a matching component that is as similar as possible in iOS, Android, React Native, and responsive web libraries.

▪ The synchronization is seen as a priority. The team creates custom tools, such as Sketch plug-ins, to achieve that.

▪ The DLS team aims to provide all the patterns required by the product designers across the company. Their goal is to reuse around 90% of the existing modules, so creation of new patterns is relatively infrequent.

▪ There’s a strict process for introducing new components:

1. A designer submits a proposal using a Sketch template with instructions about related behavior and rules. They suggest a suitable name and provide an example of how the proposed component can be used in context.

2. The proposal then goes to the product support team via JIRA, along with the Sketch file. In many cases, the support team finds that a similar module exists already, or that an existing module should be updated.

3. If a need for a new module is justified, the proposal goes through to the DLS team, who consider the requirement and decide if the proposed design will work. Sometimes they use the proposed solution, sometimes they adapt or redesign it, to make sure it fits with the system.

▪ Needless to say, documentation is fully in sync with the Sketch file and the code.

▪ On the opposite end of the strictness scale we have companies with looser structures. Such systems are optimized more towards experimentation and sensitivity to context. They can be effective too.

▪ Design what’s right, not what’s most consistent. The best utility of the page is a priority. We’ll modify the page to make it work. Dogmatic consistency and established patterns are not what should drive design decisions.” — Michael McWatters, UX architect, TED

▪ There’s a lot of scope for creative experimentation with this kind of system. Because each page can be fine-tuned, it can adapt to specific contexts and use cases.

▪ Instead of detailed specs, TED’s team can often use a whiteboard or low-fi paper sketch with rudimentary notes. It is then shared in person or posted in Dropbox or InVision, where the team exchanges comments and feedback. Designers and developers then work collaboratively as they bring it to a higher fidelity.

▪ At TED a simple sketch with notes is often used instead of detailed design spec.

▪ These were two contrasting examples, but, of course, these parameters are not binary: all teams sit somewhere along this scale.

▪ It can seem that strictness is related to company size — younger smaller systems tend to be (and can get away with) being looser, to allow more freedom and experimentation.

▪ All systems are made of parts. But in the context of design systems, modularity means not just that a system is made of parts, but that the parts are interchangeable and can be assembled together in various ways to meet different or changing user goals.

▪ •It’s agile, because multiple teams can design and build modules in parallel

▪ •It’s relatively easy to maintain, since you can fix a problem in one module without affecting the others

▪ •It’s adaptable, because modules can be assembled in the ways that meet different user needs

▪ •It can have a generative quality, which means that you can create entirely new outcomes by introducing new patterns or combining them in new ways

▪ An opposite of a modular structure is an integrated design approach. An integrated design can also be made of parts, but those parts are not interchangeable because connections between them are not designed to fit in different ways

▪ Integrated designs also have a number of benefits:

▪ •They can be specific to a particular content, context, story or art direction

▪ •They tend to be more coherent and connected (unlike modular structures which can feel disjointed

▪ But the extent of modularity should depend on your team and your product

▪ In architecture, there are examples where modularity doesn’t only add to the experience but becomes its core characteristic

▪ In short, more modular is not always better. The extent of modularity should depend on what you’re trying to achieve.

▪ A modular approach is adaptable, scalable and cost-effective in the long run. But modularity comes with some drawbacks.

▪ First, building reusable modules is typically more time-consuming than creating a one-off solution designed to accomplish a specific goal. You have to think through different use cases and plan how they will work across the system.

▪ Second, modules typically have to be fairly generic to accommodate a variety of cases. The result can be predictable generic designs where power of composition and story are lost in favor of efficiency.

▪ When teams choose a modular approach they need to find other ways to innovate — distinct content or service, a strong voice, or effective use of perceptual patterns.

▪ And paradoxically, even though there is a lot of consistency across the modules, there is little coherence in the overall experience. To prevent that, we should focus not only on the modules, but also on the connections between them: the rules of how they relate to one another, their relative importance (such as visual loudness), their role in the overall user journey, their hierarchy in the overall composition.

▪ Integrated designs can be more specific because they’re optimized for one purpose. They also tend to be more coherent and work better as a whole

▪ The degree of modularization can change over time. Your system can start with a few shared styles and principles. As it grows, you might notice more and more repeating patterns, and increased modularity becomes a logical progression for your product.

▪ At FutureLearn we have a largely modular system. But we noticed that having to work with reusable patterns on high-impact sales pages can feel limiting.

▪ In a centralized model, rules and patterns are managed primarily by one group of people.

▪ •they define the patterns and rules

▪ •they have veto power over the system

▪ •they manage the pattern library or other resources where patterns are stored

▪ The most obvious advantage of this structure is ownership. If someone is responsible for it, it is more likely that the system will be curated, maintained and evolved.

▪ It also helps the creative direction to be focused and opinionated, because it comes from one source.

▪ An alternative approach is a distributed model, where everyone who uses the system is also responsible for maintaining and evolving it.

▪ This type of structure provides autonomy for individuals and empowers them to make decisions

▪ It tends to be more agile and resilient — if one team misses something, another one can pick it up

▪ Design knowledge and creative direction are distributed, rather than concentrated in the minds of a few people.3

▪ For a small company like FutureLearn, it was impractical to have a dedicated design systems team.

▪ While a distributed approach works for FutureLearn, it’s not for everyone. Many companies I spoke to had a different experience when trying it. People were enthusiastic at first but without someone in charge, the work could slow down or stop completely.

▪ After switching to centralized approach, the team made a much better progress

▪ A fully distributed approach seems to require a certain type of team culture to work

▪ A centralized approach provides ownership and reliability. At the same time, it can work against the team. Because the responsibility falls on one group of people, they can become a bottleneck, slowing down the entire product’s life cycle.

▪ For smaller teams, like FutureLearn or TED, it may also be impractical taking someone away from the product to allow them to dedicate most of their time to focusing on the system.

▪ A distributed approach promotes more autonomy and empowers the whole team to create. It’s more agile, more resilient, because it doesn’t depend on a small group of people. But it’s challenging to make it work in a way that’s sustainable and that doesn’t dilute creative direction.

▪ Like the relative strictness of a system’s rules and its degree of modularity, ways of organizing a system don’t depend on the size of the team. In a small company, creative direction can come from a single source, such as CEO or a creative director. In larger companies, a distributed system can work also.

▪ For example, Atlassian is a relatively large organization with over 2,000 employees. There’s a dedicated team that curates the patterns, but there is also an open source model for contributions

▪ contributions. Everyone in the company is not only allowed but also actively encouraged to contribute

▪ At the BBC, GEL provides “platonic ideal” versions of patterns, and then each department has its own implementation

▪ The Airbnb system is strict, modular and centrally organized. It operates through rules and processes which are followed strictly. There’s a lot of certainty and consistency with this kind of system

▪ On almost the opposite end of the scales we have systems like TED’s, which are much more loosely set up and where creative direction is distributed throughout the team. These systems typically allow more experimentation, fine-tuning and sensitivity to context

▪ Another important aspect is, of course, a team culture, which is inevitably reflected in the design system they will produce

▪ As Conway’s law states:

“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”7

▪ To make it work, they had to make a few changes in their design process and how they collaborate. The team now put more emphasis on having a shared methodology and the design approach, rather than efficient documentation of the patterns.

▪ For them it wasn’t only a change in direction — it was also a cultural shift

▪ The right system for you is not some else’s system. Whatever works for one team might not work for another.

▪ But every approach has its downsides. The right system for you is the one where you’re able to manage the downsides.

▪ Conway’s law emerged out of an observation made in 1967 by Melvin Conway, a computer scientist and programmer.

▪ Designers become frustrated always solving the same problems, or not being able to implement their designs properly. Developers are tired of custom styling every component and dealing with a messy codebase.

▪ essy codebase. Both struggle to meet the deadlines and demands of a growing product. Without a shared design language and practices, collaboration is difficult

▪ But to make a real difference, working on a design system as a side project is not enough. You need widespread support — not only from your peers but the senior stakeholders in the business.

▪ An image of inconsistent buttons might be a compelling graphic but it’s not always enough to make a CEO or your manager see the value of the changes you’re proposing.

▪ At FutureLearn, building a relatively simple custom component for the first time can take about three hours. Building the same component in a modular way (getting the structure right, making it flexible for various use cases, coming up with a good name, adding it to the pattern library) can take twice as long

▪ But when the same component is used again, it’s almost free

▪ “If your enterprise has 25 teams each making buttons, then it costs your enterprise $1,000,000 to have good buttons.”1 — Nathan Curtis

▪ In his article “Designed for Growth,”2 Etsy’s Marco Suarez described how technical and design debt slow their team down.

▪ He shared an example of a diff of Jessica Harllee’s work for updating the styling of buttons on etsy.com. The deleted code is shown in red, and the code written in green. Evidently, far too much code was touched in order to make a simple visual change.

▪ If you visit a patisserie and order a selection of ready-made pastries you will get an entirely different quote from ordering a custom-made cake

▪ At FutureLearn, product managers understand the different timescales for developing a feature made from existing modules versus new ones

▪ “Having a pattern library for sipgate.de allows us to build pages 10–20 times faster than for other product sites which are not connected to the library.” — Tobias Ritterbach, experience owner, Sipgate

▪ Creating consistency is like making small promises throughout the interface (when you see a pink button it is always an action; the “Cancel” button always comes before “Submit”). When people can be confident of what will happen, they can rely on the product.

▪ A shared language is fundamental to collaboration, and that’s exactly what an effective design system provides. It gives people the tools and processes to create things together.

▪ “We collected components in a master Sketch file. After a week or two we began to see huge leaps in productivity by using the library when iterating on designs.”3 — Karri Saarinen, Design Lead, Airbnb

▪ “Trying a design system on a small test project allows you to see the effect it can have on your work and to demonstrate how much time you’re saving.”

▪ What are the main outcomes you’re hoping to accomplish with this work? Having clear goals gives a team direction and motivation. It helps them organize their time and balance priorities.

▪ For instance, one of them can be focused on the interface, and the other on the way team operates

▪ Systematize the Interface(s)

▪ Define guiding design principles

▪ Define and standardize reusable design patterns

▪ Establish a pattern library

▪ Set up master design files with up-to-date patterns

▪ Refactor code and front-end architecture to support the modular approach

▪ Establish Shared Processes and Governance

▪ •Set up knowledge-sharing processes (through conversations, collaboration, pairing, training, and so on).

▪ Promote the pattern library and encourage its use across the company

▪ Promote shared design language across teams and disciplines

▪ Make introduction to the design system part of the induction process

▪ it is also helpful to create a simple roadmap for your design system

▪ At FutureLearn we also integrated design system stories into the main product’s roadmap

▪ This helped to make the rest of the team aware of the work we were doing and balance it with other priorities

▪ A design system is a long-term investment — its value increases gradually over time. It’s important that people expect to see gradual and steady improvements rather than quick dramatic ones.

▪ In my observations, teams who have made public some of their work on the design systems tend to progress faster than those who kept everything under wraps

▪ Dan Jackson at Eurostar explained in an interview the importance of making their style guide public early on, even when it wasn’t perfect.

▪ Some teams write short blog posts about their system as it evolves

▪ As we saw in the example of Sipgate in the previous chapter, a team can have an up-to-date pattern library, but it won’t provide as much as value without effective cross-team collaboration

▪ Set up a dedicated Slack channel to collaborate on defining and naming design patterns and to discuss system related questions

▪ Create a pattern wall to make the process open and transparent to the rest of the company and encourage more people to join in

▪ •Encourage collaboration not only within individual teams but across teams and disciplines. In particular, encourage people who are more knowledgeable about the design system to work with everyone, so they have an opportunity to share their knowledge and enthusiasm with people who are less immersed in the system.

▪ One of the guerilla tactics Vitaly Friedman and his team have been applying is dedicating each day to a component in the interface

▪ They’d have a carousel day, a lightbox day, an accordion day, and so on. Everybody would receive a print-out highlighting the component and its variants, including front-end code and related styles

▪ We put it next to the kitchen sink and in the bathroom. A month later, everybody remembers the naming of all the components, including the cleaning personnel!” — Vitaly Friedman, editor-in-chief, Smashing Magazine

▪ Working on a design system is a long-term process. Your team might not see the rewards of what you’re doing for some time.

▪ Rather than chipping away at an endless list of tasks, aim to complete the bulk of the work in one go, and then continue the rest as part of ongoing work. At Atlassian, initial progress was made through design spikes by two or three people. Matt Bond, a product designer who led the initial work on the Atlassian Design Guidelines (ADG), explained in one of his blog posts that having a two-phase approach allowed the team to get through the initial stages quickly and to then maintain momentum:

▪ “It was high output, getting many new patterns to 80% completion in a short amount of time. We’d then spend the next week or so dedicating small amounts of time to refine a pattern and get the guidelines and code up to scratch to include in the ADG.”6

▪ For some of the work, such as conducting an interface audit or setting up a pattern library, it’s useful to get the whole team (or representatives from multiple teams) involved, at least in the initial stages

▪ If it’s not possible owing to other priorities, let a smaller group do the groundwork and involve others as needed

▪ At FutureLearn, our goal was to make all the components living. This meant that the code for the modules on the website, and in the pattern library, would need to be the same. But achieving that involved refactoring every module. As we refactored them, we added them to the pattern library, one by one. It was a painfully slow process and the team started to lose motivation

▪ We then realized that we could provide value quicker by adding all the patterns in one go and displaying them as screenshots instead of code. This allowed the team to start using the pattern library for reference right away. In the following months we gradually replaced the screenshots with living modules, as we continued refactoring them. Had we not done that, it would probably have taken another year before all the patterns were documented.

▪ •Modules didn’t have a clear purpose. The differences between them were mostly presentational.

▪ •We didn’t define and name them.

▪ •We didn’t put a lot of thought into how they would be reused.

▪ •Their role in the overall system was unclear.

▪ If your team is new to this way thinking, it’s useful to first explore what modular means by experimenting on a side project or on a small area of your product first.

▪ 1. Identify key behaviors or aesthetic qualities

▪ The steps are slightly different for functional and perceptual patterns. With functional patterns, the focus will be on the user behaviors, on defining individual modules and naming them.

▪ We will look at perceptual patterns more as a whole, focusing on the feel and aesthetics, and on the general principles of how they work together.

▪ The order you do it is not critical. Some teams find it helpful to look first at the foundational styles, such as typography; others start with core functional modules.

▪ It is also possible to look at both simultaneously in parallel.

▪ In both cases, we consider the big picture first, and then deconstruct the interface into smaller parts.

▪ Design intent can be rendered in countless ways — patterns don’t have to be visual. They can be represented in physical objects (like the interior of a book store), or they can be read out by a voice.

▪ This means rather than focusing on making all buttons look consistent, we will first try to understand when to use a certain type of button, when to use a link instead of a button, when not to use a button at all and instead click directly on the object. Of course, in the process of doing that we will improve visual consistency, but it won’t be the focus.

▪ Similarly, digital products encourage or enable certain behaviors.

▪ Consider how Slack supports ways of working which are more collaborative compared with email or other chat apps. Or think how Tinder promotes casual, commitment-free relationships with its swiping interaction.

▪ Products can be designed around similar user goals and needs, while encouraging entirely different behaviors. That’s why thinking of behaviors can be helpful when connecting patterns with the design intent and ethos of the product.1

▪ Articulating the behaviors helps to define patterns in a way that is more futureproof, because behaviors are platform-neutral.

▪ The interface inventory2 is a popular exercise to start systemizing an interface. It involves taking screenshots of various UI elements, and then grouping similar-looking things together.

▪ But while the idea is straightforward, it can be done in a variety of ways. Sometimes inventories focus on the visual consistency of the interface; for example, making sure all buttons look the same, all menus are consistent, and so on.

▪ The main goal of the process described in this chapter is not to account for all the visual inconsistencies; it’s to define the most essential design patterns and get mutual understanding in the team on how they should work across the system.

▪ While a visual inventory typically groups things by appearance and type (buttons, tab controls, and so on), in the following exercise you might end up with things in the same group that look different, because you’re grouping them by purpose (the behaviors they’re designed to encourage or enable).

▪ In a purpose-directed inventory, things in the same category might look different because they’re grouped by purpose rather than visually.

▪ Having different perspectives can help you to be more objective and account for more use cases. It’s important that designers and front-end developers take part, but ideally involve a back-end developer, someone with a content background, and a product manager.

▪ The ideal group size is around 4–8 people. If a larger group needs to be involved, consider running the initial exercise with a few representatives from different disciplines, and then hold follow-up sessions to debrief more people.

▪ Identify the key screens and user flows that are absolutely fundamental for your product, those without which the product couldn’t exist. Typically, about 10–12 screens is enough, sometimes fewer. They can be design mock-ups, or screenshots of an existing interface.

▪ Print out two copies of each screen. Put the first set on the wall, in the order of a typical user journey. The second set will be used for cutting out patterns and grouping them.

▪ Start by identifying the key user needs and behaviors you want to support at each segment of the user journey

▪ To return to the public library website example, you might group some of your pages based on these behaviors:

▪ Take note of the pages with conflicting behaviors: situations where we encourage people to look at new books, download something, sign up for a newsletter, and check the latest events all at the same time.

▪ Even if a screen supports several behaviors, the most important actions should be clear and not in conflict with one another. When dealing with multiple behaviors, focus on the core user journeys and most important behaviors first.

▪ The words we choose matter. They influence how we think. For a few months the team I worked in at FutureLearn had “retention” as our metric. It focused on getting more people to continue learning on a course after it began. Designing for retention was hard. It also wasn’t clear how exactly retention benefited our users. Had the metric been called “engagement,” it might have led to different design outcomes. And perhaps even more, had the metric been centered on quality and satisfaction of learning, rather than the time spent on the site.

▪ Taking one behavior at a time, look across all the pages to find the elements that support it. For example, to “View a book” we might be using different items on the promo pages, in the catalog search results, and in the wish list.

▪ “View a book,” “Refine a list,” and so on. They are the candidates to be defined as patterns

▪ While it seems like a simple concept, deciding the level of specificity is one of the trickiest things about modular design. The more specific something is, the less reusable it is. And conversely, to make something more reusable, you also need to make it more generic. With more specific parts, the system becomes harder to maintain and to keep consistent. But too many generic modules lead to generic designs. Like with many things, there’s no right way to define patterns and it all depends on what we’re trying to achieve.

▪ If there’s no reason to differentiate between the two types, we should unify them into one pattern: things to do in the library. Doing that will make the pattern more generic because it would have to work for both cases. But it would also mean that every change we make to events will apply to exhibitions.

▪ Consistency will be easier to achieve but at the expense of flexibility.

▪ 1. List the core content slots a module needs to be effective. Can this module function without the image or is the image essential to its purpose? Is a label always necessary? Mark optional elements.

▪ 2. Determine the hierarchy of elements and decide how they should be grouped: is the icon part of the key info or is it part of the image?

▪ 3. Make sketches to visualize the structure. The same pattern can be presented in countless ways and sketching helps find the optimal design

▪ Typically, elements that can be merged into one pattern share the same underlying structure

▪ On the other hand, if you struggle to unify the structures of multiple elements without compromising their purpose, it’s an indication that they shouldn’t be merged.

▪ Sometimes elements have a similar structure, but owing to context or our design intent, they need to look or behave differently. In this case we can create variants. A variant is a modified version of the same pattern.

▪ Ask yourself: if I change this module, do I want the others to change in the same way?

▪ With variants, you would normally have a default pattern with the core styles. Variants would have additional styles. It’s important to know which features are core to the pattern, and which are specific to the variants. Then you can predict how a change in one of them will affect the others.

▪ Similarly, this would be a good place to start looking at character counts or image sizing variations. A pattern will work with more content types if different sizes are standardized

▪ As we discussed in chapter 5 on shared language, names affect how patterns are used. A well-chosen name is a powerful tool for shaping your design system

▪ In this case it made sense to use the name “Course tabs” — we didn’t want to reuse them anywhere else. This name also signalled to the rest of the team that they weren’t just any generic tabs — they were specific to the course area. Later we decided that this module could also be useful in other places and changed the name to “Page tabs.” The new name was more generic, and again signaled to the team that it was now available to be used in other areas.

▪ Effective names guide usage and reduce the chances of duplicate patterns.

▪ Typically, this would involve several sessions: one to discuss big-picture user behaviors, and separate ones to look at more granular patterns

▪ If you have elements with similar purposes, think of them in relation to each other rather than independently. How are buttons different from links? How is tabbed navigation different to a list menu? How is a dropdown different from a set of buttons? How is a checkbox different from a toggle button?

▪ Traditionally in web development, links and buttons are different. A link navigates the user away from the current page. A button submits an action and toggles something in the interface.

▪ But in practice, it’s not easy to make design decisions based on this criterion alone.

▪ To me, the most important aspect is a consistent expression of purpose. Users (both those who access the interface visually and via screen readers) need to know what to expect. If buttons are always used only for submitting data, then it would be confusing to have one situation where they behave as links. But if there’s a consistent use of links styled as buttons (such as for standalone calls to action) throughout the interface, then it would be appropriate.

▪ What are the shared meanings of “button” and “link” in your team? What are the basic guidelines for their usage?

▪ Heydon Pickering in Inclusive Design Patterns10. The idea is to differentiate between links and calls to action (CTAs), rather than buttons and links. An important standalone action can be presented as a button, but be marked up either as a link or a button, depending on the interaction. The question of whether it’s a link or button is a matter of variants — first and foremost it’s a CTA

▪ Most interfaces have equivalents of primary and secondary buttons. But what does “primary” mean exactly? Does it signify the most important action in the context of the whole interface, or a specific screen or section? For example, should a “Reserve book” button always be a certain style because of the importance of the action on a library website?

▪ In Marvel’s design system11, “flat” buttons are used to signify “necessary or mandatory actions”; “ghost” buttons are used to signify “optional, infrequent or subtle actions.” Flat buttons can be used alongside each other, when actions are equally important. I like this distinction because it’s simple, clear, and specific to the button’s purpose.

▪ But for more complex interfaces with a larger number of buttons, it’s hard to keep their functions so specific. You may also need to see how buttons relate to each other when used together. In Atlassian’s system12 and Shopify’s Polaris13, primary buttons represent “the most important actions in any experience” and therefore should only appear once per screen.

▪ There will always be special cases. In the library website example, the “Reserve” button could be treated differently. It could include states specific to the action; for instance, its label could change to “Cancel reservation” if the book hasn’t been collected yet

▪ oth the “Progress toggle” button and the library “Reserve” button are things we might want to make more memorable. They are key functions of the brand, and perhaps opportunities for signature moments. Equally special cases like this should be occasional, both so they appear distinct but also so the general pattern rules are maintained

▪ As an aside, if you have too many pages in the same segments supporting similar behaviors, it’s an indication that your information architecture might need work.

▪ Successful businesses join user goals with business goals. If you really struggle to join the two together, your product might have deeper issues a design system won’t be able to solve.

▪ There are general guidelines and best practices (for an excellent resource see Designing Web Interfaces by Bill Scott and Theresa Neil; and Designing Interfaces: Patterns for Effective Interaction Design by Jenifer Tidwell), but some things might be specific to your situation.

▪ Base color values provide consistent defaults. When there are many options to consider, defaults and meaningful increments are easier to remember and work with.

▪ Sometimes we think that if beauty is not what we’re after, we don’t have to place any importance on aesthetics: “It’s just a functional tool. It doesn’t have to feel like anything in particular.” But then we miss a key opportunity to influence how a product is perceived.

▪ What’s important is, of course, not the styles themselves but the effect they have

▪ A functional tool should be useful and usable, but it should also feel simple, safe and robust.

▪ To influence perception in a reliable and scalable way, we need to be aware of the patterns that create it.

▪ But even with a standardized color palette there’s still plenty of scope for interpretation. What do the values represent? Which variation of green should you use? How do the colors work together?

▪ Here’s a counterintuitive thought, for a design systems enthusiast: slight diversions in color aren’t problematic. In fact, having twenty shades of blue isn’t an issue, if blue has a consistent meaning throughout the interface. But if blue represents links in some parts of the site, and in others there are blue headings users can’t click, it can cause usability concerns.

▪ A set of shared colors is not enough — you also need a shared use of color in the context of the product.

▪ Likewise, a well-defined typographic scale alone won’t make your typography more cohesive. Even after we standardized all the text sizes on FutureLearn and introduced a unified type scale, the headings still weren’t always used consistently — designers and developers weren’t sure which size to pick from the scale

▪ A shared use of typography required clear guidelines and patterns of usage which everyone could understand.

▪ With functional patterns we looked first at user behaviors. With perceptual patterns, we will start with aesthetic qualities.

▪ Every interface has a certain feel, even if it’s only represented through text or voice.

▪ If the design has been around for a while, pinning down those patterns isn’t always easy

▪ We’ve seen (with the FutureLearn examples in chapter 4) that as your product grows, its core aesthetic can change.

▪ By the time you look at the styles, you might notice that some of them are more effective than others and have stronger associations with your brand.

▪ Think not only about the properties but high-level principles, combinations of different elements, and the relationships between them.

▪ For instance, instead of simply listing the colors, describe the proportions between them: “Primarily white with pink and blue accents.” Include examples of a typical representation of the pattern.

▪ As you go through them, there will be overlaps: between typography and space, color and text, shapes and borders, borders and iconography. This is good, because you can build on the properties you’ve defined previously and you can see how they relate to each other.

▪ For example, the colors you define will be used in interactive states; interactive states will be used in animations.

▪ When looking at typography and spacing, you can see how size of text affects spacing around it.

▪ The goal of the first step is to make the use of color more consistent. To do that we will start by listing the roles color plays in your interface

▪ •Display different types and hierarchy of text (body, headings, blockquotes).

▪ •Highlight links and actions (main CTAs, supporting CTAs, links).

▪ •Draw attention to messages and differentiate between them (affirmation, warning).

▪ •Separate content or create emphasis (backgrounds, borders).

▪ •Differentiate between types of data (in charts, graphs).

▪ The roles you define will determine the categories for your inventory.

▪ •Type Specify the type of object the color is applied to, such as a call to action, a heading, a feedback message, and so on.

▪ •Feel If the purpose of the color is to create a certain mood or feel, specify that

▪ If there are specific emotional qualities that color is meant to bring into your product, it’s important to capture that. Misuse can weaken the purpose colors were intended for. Using a full gradient in promotional modules on FutureLearn, for instance, would weaken its association with celebration.

▪ Don’t worry about the exact hex values just yet. What matters is that you agree on the use of color across the interface.

▪ In FutureLearn’s interface, we considered changing the square shapes used in the course progress module to circles, before we realized that the course navigation was a signature pattern and replacing the shapes would alter the brand’s feel.

▪ During a color inventory it’s not uncommon to discover dozens of variations of the same color (Marcin Treder discovered 62 shades of gray while doing the color inventory for UXPin6). Most of them are unnecessary and create needless complexities in design and code.

▪ The advantage of a purpose-directed inventory is that it helps you guide and limit color choices. When you start with the role and meaning of color, you get an idea of how many options you really need.

▪ By considering where and how they’ll be used, you will know, for instance, that you only need three variations of blue.

▪ The number of shades and tints will vary, depending on your circumstances. In FutureLearn’s interface, we purposefully avoided darker and lighter varieties of the same color to keep the palette crisp.

▪ Sometimes you need to have more options, particularly if there are multiple themes, or if you’re dealing with data visualization.

▪ But it’s important to avoid including the colors just to add more variety to your palette. The more choices there are, the more complex the system is, then the harder it is to achieve consistent use of color. Start with only what you need and build on it.

▪ If you have more than two variations of the same color, it helps to specify a base value and then add additional shades and tints: 20% lighter than base, 20% darker than base, and so on.

▪ Test the color contrast between text and background. Adjusting or removing the values as needed will limit your palette. For example, among several variations of light gray used for supporting links on the library site, one of the frequently used values passes WCAG 2.0 standards. This would make it an obvious choice for the default value of supporting links.

▪ There are plenty of tools to check color contrast, such as Lea Verou’s Contrast Ratio7, which is quick and straightforward to use.

▪ It’s worth mentioning that adjusting color values needs careful balancing within the overall aesthetic. Change the blue to a darker shade, for instance, and the whole interface can suddenly feel different, perhaps less vibrant.

▪ If your color palette was created without considering color accessibility in the first place, getting the balance right will require some finessing.

▪ There are also plenty of tools for generating contrast-compliant color combinations, or for finding accessible alternatives to the original color, such as Color Safe9 and Tanaguru Contrast Finder10.11

▪ For example, in Sky’s toolkit12 the team explains the reasons for a minimal color palette:

“We allow our great content to be the color that brings the page to life. We do not color code our sites, or sections within our sites.”

▪ The University of Oxford13 explains clearly how and why to use its colors:

“The (dark) Oxford blue is used primarily in general page furniture such as the backgrounds on the header and footer. This makes for a strong brand presence throughout the site. Because it features so strongly in these areas, it is not recommended to use it in large areas elsewhere. However it is used more sparingly in smaller elements such as in event date icons and search/filtering bars.”

▪ Even with more complex patterns, such as animations, we can follow the same process: start with the purpose, collect and group existing styles, define patterns and building blocks.

▪ •Soften transitions between interactive states, such as hover states

▪ •Add emphasis to specific information or an action; for example, a nudge to encourage users to progress to the next step

▪ •Hide and reveal extra information, such as a menu being hidden to the side, a dropdown, or a popover

▪ Timing, especially, is crucial in animation. Getting the timing right is not so much about perfect technical consistency as making sure that the timing feels consistent. Two elements animated at the same speed can feel completely different if they are different sizes or travel different distances.

▪ I like Sarah Drasner’s16 idea to deal with animation timing like we deal with headings in typography.17 Instead of just a single value, start with a base and provide several incremental steps. For example, if the base time is 0.5 seconds, smaller items that travel a shorter distance (such as an icon scaling up) would take less time.

▪ In a recent conversation with Léonie Watson21, an accessibility expert who is also a screen reader user owing to blindness, she noted that her experience of digital products “often comes through in the form of style of writing.”22

▪ However, team members who define the interactions and patterns are often not the same people who will be working on voice and tone. This can lead to a patchy and thoughtless style of writing across the experience.

▪ To make sure voice and tone are expressed consistently and purposefully, design, brand and marketing teams need to coordinate their efforts when defining patterns.

▪ In addition to collecting all the UI copy in a Google doc, there are more creative ways to audit voice and tone. In her blog post23, content strategist Ellen de Vries, shared how she “harvested” the language patterns during Clearleft’s24 voice and tone refresh: from phrases people use in meetings and pitch presentations, to informal conversations with the founders. They even made a mood board to see how language and imagery work together across Clearleft’s website.

▪ Once the copy and other materials have been gathered, define the patterns and formulate guidelines for how they can be applied in the interface. MailChimp’s Voice & Tone25 is one of the most effective examples of how language patterns can be defined

▪ Similarly, Salesforce gives a breakdown of common use cases and suggests patterns of copy to use with each one. The goal of the message affects the emotional tone, such as “suggest a solution using lighthearted language”.

▪ Like the overarching design principles (see chapter 2), guiding principles for individual styles shouldn’t be vague and general. Not only Intuit’s Harmony26 lists the voice and tone principles (“Lead the way,” “Keep it simple,” “Have fun”), they also explain how to do all those things.

▪ Each style should be approached as a system in its own right — typography system, layout system, color system, and so on. They should be interconnected and directed towards achieving a larger purpose — to help shape how a product is perceived

▪ .And conversely, in a project where color accessibility was a factor right from the start, you wouldn’t end up with such widely different palettes

▪ For further reading on color accessibility and balance with aesthetics, I highly recommend Color Accessibility Workflows by Geri Coady.

▪ This second description is much more effective at communicating what the pattern is for. You might even be able visualize the “Fact Grid” just by reading these two sentences.

▪ For some teams, a systematic approach to designing and building digital products is almost unthinkable without a pattern library.

▪ But as we’ve discussed throughout the book, a pattern library is not the system itself, it is a tool for documenting and sharing design patterns. To be effective, it needs a system foundation at its root.

▪ •Practice thinking in systems through experiments, workshops and group exercises

▪ In the experience of every team I spoke to, multidisciplinary pattern libraries are more resilient and enduring.

▪ They facilitate a shared language across the organization and bring value to everyone.

▪ Conversely, a pattern library built to serve the needs of one discipline is more fragile

▪ Going through the process described in the previous two chapters will give you a good grasp of what can go into your pattern library. It can be documented simply, using Google Docs2 or another collaborative writing app. There are two main benefits of this:

▪ •First, everyone on the team can access the content to review, make edits and provide their feedback. By using a tool that’s familiar and easily accessible, you give more people an opportunity to be involved

▪ •Second, a folder in Google Docs is like an MVP pattern library — the team can start using at as a reference right away. Once you have the content, it will be easier to figure out how the website for it should be designed and built.

▪ The structure doesn’t have to be perfect at the start — you can (and probably will) change it later. What’s important is that the team are on the same page. Having a common methodology to organizing patterns will make it easier to add and find things as your pattern library grows. The same thinking can apply not only to the pattern library, but front-end architecture and the design files.

▪ The simplest way to think about the structure is in terms of components and styles (functional and perceptual patterns)

▪ As we saw in the previous chapter, perceptual patterns are connected and work together. Abstracting them makes it easier to be aware of their role in the system. Here are a few examples of how perceptual and functional patterns are referred to.

▪ There seems to be a general consensus to refer to functional patterns as “components,” but more diversity in terminology used for perceptual patterns.

▪ While the number of styles is limited, the list of functional patterns can keep growing

▪ The findability of modules is one of the greatest barriers to pattern library adoption. If team members don’t know that a pattern exists or can’t find what they need, they are likely to create a new one or go outside the pattern system.

▪ In IBM’s Carbon design system, Sky Toolkit13 and Lonely Planet’s Rizzo (among others) components are kept in one list and arranged alphabetically.

▪ Another way to classify functional patterns is in terms of their complexity. Some teams separate granular elements from more complex ones.

▪ Atomic design, pioneered by Brad Frost, is a popular example of hierarchical categorization. Atoms are the basic building blocks, which combine to create more complex standalone elements: molecules.

▪ As a methodology, atomic design can bring many benefits. Thinking of patterns as nested matryoshka dolls can help to reuse the elements, since you’re conscious of how the levels build on each other

▪ But it’s important to remember that atomic design (or any other methodology) might not be right for you right out of the box

▪ What’s more, we spent far too much time debating whether something was a molecule or an organism. Since the team didn’t see enough distinction between the two types, they were merged together. We ended up with two levels of hierarchy: atoms and molecules.

▪ After two years of trial and error we settled on classifying elements by purpose — promotional modules, modules focused on encouraging learner progress, modules around communication with the user, social modules, and so on.

▪ Organizing patterns by purpose gives the team some guidance and inspiration for where to use a specific module. This structure also fit with our purpose-directed approach for defining patterns.

▪ In Shopify Polaris, components are also categorized based on the team’s mental models

▪ The initial grouping was the outcome of an open card sort and usability testing

▪ Even though there isn’t perfect alignment among different disciplines, the internal user research is continuously shaping how patterns are organized

▪ “Designers tended to think in terms of structure. Developers tended to default to functionality. Content strategists tended to combine both. We’re conducting a range of usability studies to understand how well the grouping of components is working for people.”22 — Selene Hinkley, content strategist, Shopify Polaris

▪ Find a structure that’s right for your team. If it doesn’t work, if people struggle to find what they’re looking for, continue experimenting with different approaches. This can take time. The phrase I hear the most from all the teams with effective patterns libraries is that their “work is never done.”

▪ To see tangible benefits sooner, start with a lightweight overview of the main patterns.

▪ When browsing a pattern library, most people skip descriptions, especially long ones. That’s why they should be focused and to the point: typically, one or two sentences explaining what a pattern is and what it’s for is enough.

▪ Although this seems like a simple task, in practice capturing the purpose of a pattern concisely and accurately is not easy. Too often we come up with vague descriptions that don’t have a lot of practical value.

▪ Take a look at how the team at Sipgate initially described a component called “Showcase”:

“Use Showcase to present multiple types of information with a media file.”

Even though factually correct, it doesn’t communicate the purpose of “Showcase”, which makes it more likely to be misused or duplicated.

▪ Later, the team adopted a new practice for defining a pattern’s purpose, and writing descriptions. Here’s how it was applied to another example:

“Fact Grid is a shortlist of facts or bits of interesting information. Use Fact Grid to give the reader an immediate impression about the upcoming content.”

▪ A living instance of a pattern, with component code alongside it, is usually preferred — it can show responsiveness, interactions and animation. But in some cases a static image or a GIF is more helpful, particularly when you need to show a specific behavior or a state that can’t be recreated in a living example.

▪ Carbon uses a combination of live and static examples to illustrate specific behaviors

▪ •Related patterns. Shopify Polaris25 helpfully shows alternatives if the pattern is not quite what you’re looking for. This can reduce the chance of patterns being duplicated.

▪ When documenting perceptual patterns, the focus tends to be on the buildings blocks — color palette, typographic scale, and so on. But as we saw in the previous chapter, it’s also important to know how those properties are used and how they work together. Here are a few tips and examples.

▪ Representation of color doesn’t have to be limited to a list of variables. In its color palette, the GOV.UK style guide27 helpfully specifies the usage of color for text, links, backgrounds, and other roles.

▪ The dos and don’ts format can also be useful, particularly when there’s an expected misuse. In Shopify Polaris28, both indigo and blue are primary colors used for interactive elements. Stating explicitly that blue shouldn’t be used for buttons is helpful in this case, as it would be reasonable to assume otherwise.

▪ Although we separate styles and components to make them easier to work with, in practice they’re closely interlinked. Even if there are duplications, referencing styles at the module level, as well as separately, is useful. A button has many styles that define what kind of button it is (color, shape, style of label, transitions, spacing, and so on). At the same time, some of those styles can be applied to other objects — menus, links, toggle controls.

▪ Sharing styles is what makes those objects feel like they belong to the same system.

▪ To be effective, perceptual patterns should interconnect and work together. By showing the relationships (between colors, between typography and spacing, between voice and tone and the visuals), you help make the whole system more connected.

▪ The same color values can have entirely different effects when applied in different proportions. As Michael McWatters noted, with too much or too little red, TED can feel like a different brand. The color chips in the Open Table style guide31 make the hierarchy of colors clear.

▪ Typography and spacing are also closely interlinked. Large, higher-contrast typography requires more white space. Smaller text can get lost in the same amount of space if you don’t compensate by reducing the padding. Even if you have a limited selection of predefined spacing options (such 8px or 16px units), different designers might have different preferences — some prefer more generous white space, others like it cosier. The values might be consistent, but that doesn’t mean that the visual density will be.

▪ To help guide the density and contrast across the product, in FutureLearn’s interface we tried to show the relationship between typography and spacing.

▪ •Spacious modules have high typographic contrast (large heading in proportion to the body font size) and generous spacing to balance out the high-contrast typography.

▪ •Regular modules form the majority of sections on FutureLearn. They have the default heading and spacing.

▪ •Compact modules have headings only slightly larger than the body copy.

▪ Those settings also reflect the purpose of the modules. High-impact promotional sections benefit from high-contrast typography

▪ On the other hand, modules with a supporting function tend to be more compact.

▪ Teams with effective pattern libraries have systematic approaches ingrained in their workflow

▪ How, exactly, varies across companies. Some teams, like Airbnb, have strict and precisely specified processes with powerful tooling. Others are much more informal.

▪ The team meet every fortnight to discuss new submissions. They go through a Trello backlog and decide if a module should be approved for inclusion or archived.

▪ A common problem teams have is a lack of agreement on what constitutes a design pattern. A way to manage this is to have shared criteria for adding (and also updating and removing) patterns.

▪ If there’s a dedicated design systems team, it’s important to agree on their role, as well as the process for managing contributions. A systems team can have the role of a curator or a producer, and many companies use a combination of both

▪ In both cases it’s important that the systems team are seen as partners, rather than police.

▪ Code, design and the pattern library are facets of the same system. Treating it that way makes it more robust, because the system is supported from multiple angles.

▪ This doesn’t necessarily mean that the patterns must be fully synchronized. What’s important is that the team practises the same approach across the facets — to naming, structure and understanding of the purpose.

▪ They even follow BEM naming conventions for their design files, to help developers and designers talk the same language

▪ When design and code are aligned conceptually, synchronization between them is easier to achieve

▪ Full synchronization between the pattern library and the code is extremely difficult to achieve, and companies manage it with varying degrees of success.

▪ “It’s always slightly off-sync. If it’s too perfect, it’s not going to work. Our design language, as any language, is constantly evolving. We change details and patterns and we add patterns. We constantly build products. So at any given time there are many versions of the design language. We embrace this fact and design a system which can deal with these imperfections.” — Jürgen Spangl, head of design, Atlassian

▪ With pattern libraries gaining the “source of truth” status, in some companies it has become somewhat less important to keep master UI kits perfectly up to date

▪ Designers use the pattern library as the main reference for up-to-date patterns, Sketch or Photoshop are used mainly for exploratory work

▪ Because the majority of the components are defined and named, more and more often the team can get by with paper sketches, without needing detailed design specs

▪ Design systems free our time and energy to solve bigger and more meaningful problems, like understanding our users better and making design languages more inclusive.

▪ In programming and design, Christopher Alexander’s pattern discipline has become one of the most widely applied and important ideas. It is now influencing how many of us think about design systems. But there’s an essential feature we may still be missing from Alexander’s original idea: the moral imperative to create systems that make a positive difference to human lives.

▪ The pattern language for the web we’re creating is powerful. It has the capacity to influence not only the digital world, but the physical one.

▪ The Timeless Way of Building4 by Christopher Alexander

▪ Thinking in Systems: A Primer5 by Donella Meadows

▪ How Buildings Learn: What Happens After They’re Built6 by Stewart Brand

▪ Front-end Style Guides8 by Anna Debenham