atomic-design.md

Atomic Design (2016)

Brad Frost

---

▪ It was 2013, and we huddled with Brad Frost and Jennifer Brook around a sunlit kitchen table in Brooklyn. The four of us had just begun work on a new website for TechCrunch, and we were sketching wireframes in Jennifer’s apartment, wrestling with the new demands of responsive design. Brad pulled out his laptop: “I’ve been playing with a new idea.”

▪ this was a shift in perspective, a way to move away from conceiving a website design as a collection of static page templates, and instead as a dynamic system of adaptable components.

▪ It was an inspired way to approach this responsive website—and all responsive projects for that matter.

▪ Brad’s new idea was atomic design, and it changed the way we work in this astonishingly multi-device world.

▪ This wonderful book explains the philosophy, practice, and maintenance of atomic design systems.

▪ His This Is Responsive site is the go-to resource for finding responsive solutions to any UX problem

▪ The page has been with us for a long time now. A few millennia, actually.

▪ The page metaphor has been baked into the lexicon of the web since the very beginning. Tim Berners-Lee invented the World Wide Web so that he, his colleagues at CERN, and other academics could easily share and link together their world of documents.

▪ This document-based, academic genesis of the web is why the concept of the page is so deeply ingrained in the vocabulary of the internet.

▪ The page was – and continues to be – a very visible and helpful metaphor for the users of the web. It also has a profound influence on how web experiences are created.

▪ All of the statements above make the fundamental mistake of assuming a page is a uniform, isolated, quantifiable thing. The reality is that the web is a fluid, interactive, interdependent medium. As soon as we come to terms with this fact, the notion of the page quickly erodes as a useful means to scope and create web experiences.

▪ Ultimately, a project’s level of effort is much better determined by the functionality and components contained within those pages, rather than on the quantity of pages themselves.

▪ The page metaphor has served its purpose helping users familiarize themselves with the web, and provided creators with the necessary transitional language with which to create for a brand new medium. But to build thoughtful interfaces meant to be served to a multitude of connected devices, the time has come for us to evolve beyond the page.

▪ Slowly, but surely, these concepts found their way into web designers’ workflows. In the early 2000s we saw the introduction of libraries like YUI and jQuery UI that provided developers with a toolkit of widgets and patterns to create more consistent user interfaces.

▪ If modularity has been around for such a long time, why are we talking about it now?

▪ The short answer is that modularity matters more than ever. Right now, our entire industry is drowning in a sea of devices, viewport sizes, and online environments. And things aren’t slowing down anytime soon.

▪ Disruption will only accelerate. The quantity and diversity of connected devices — many of which we haven’t imagined yet — will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won’t hold up. Today’s onslaught of devices is already pushing them to the breaking point. They can’t withstand what’s ahead. The Future-Friendly manifesto

▪ To address this reality while maintaining our sanity, it’s absolutely necessary for us to take a step back and break these giant responsibilities into smaller, more manageable chunks.

▪ Every organization is finally realizing that bulldozing their entire website and replacing it with a New-And-Shiny™ website every three to eight years isn’t (and never was) an optimal solution.

▪ Wanting to be more agile is commendable. But agile is a loaded term, with big differences between capital-A Agile and lowercase-a agile. Capital-A Agile is a specific methodology for software development, equipped with a manifesto and accompanying frameworks like Scrum and Lean.

▪ Even though it may be impossible to adopt a truly Agile process, it’s still a sound idea to work in cross-disciplinary teams, get into the final environment faster, ship early and often, and break bigger tasks into smaller components.

▪ To properly address this increasingly diverse and eclectic digital landscape, we need to dramatically overhaul our perception of content and the tools we use to manage it.

▪ Methodologies like OOCSS, SMACSS, and BEM have cropped up to help web designers create and maintain modular CSS architectures.

▪ As the number of viewports and environments proliferate, it’s become untenable to produce static mockups of every page of a web experience. As Stephen Hay quipped, presenting fully baked Photoshop comps “is the most effective way to show your clients what their website will never look like.”

▪ That’s not to say static design tools like Photoshop and Sketch aren’t important. Far from it. But it’s the way we use these tools that has changed dramatically. While creating hundreds of full-on comps isn’t realistic, these static tools excel at providing a playground to establish what Andy Clarke calls “design atmosphere”:

▪ Atmosphere describes the feelings we get that are evoked by colour, texture and typography. You might already think of atmosphere in different terms. You might call it “feel”, “mood” or even “visual identity.” Whatever words you choose, the atmosphere of a design doesn’t depend on layout. It’s independent of arrangement and visual placement. It will be seen, or felt, at every screen size and on every device. Andy Clarke

▪ Establishing design atmosphere early is critical to a project’s success, which is why designers have found ways to facilitate these important conversations without having to generate full mockups. Designer Samantha Warren developed design artifacts called style tiles, which demonstrate color, type, and texture explorations in a nice encapsulated one-pager.

▪ Designer Dan Mall built on Samantha’s idea with a concept called element collages, which demonstrate design atmosphere explorations in an exploded collage of interface elements.

▪ Systematic UI design

We’re not designing pages, we’re designing systems of components. Stephen Hay

▪ A few years ago Ethan Marcotte introduced us to the idea of responsive web design and its three core tenets: fluid grids, flexible media, and CSS media queries. These three ingredients provided a much needed foundation for designers to create flexible layouts that smartly adapt to any screen size.

▪ Perhaps more importantly, responsive design helped get designers excited about creating thoughtful, adaptable, multi-device web experiences.

▪ This need to address growing device diversity while still sanely getting projects out the door has given rise to front-end frameworks like Foundation by Zurb and Bootstrap. These user interface frameworks provide designers with a collection of preassembled HTML patterns, CSS styles, and JavaScript to add functionality to interactive components like dropdowns and carousels.

▪ In essence, these frameworks are handy tool kits for quickly assembling interfaces.

▪ These frameworks’ popularity is a testament to the fact that designers and developers are seeking solid ground to stand on in this ever-complex web landscape.

▪ Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs. These living code samples are self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web. Dave Rupert

▪ The cornerstones of good design systems are style guides, which document and organize design materials while providing guidelines, usage, and guardrails.

▪ As it happens, there are many flavors of style guides, including documentation for brand identity, writing, voice and tone, code, design language, and user interface patterns.

▪ Brand identity guidelines define the assets and materials that make a company unique. Logos, typography, color palettes, messaging (such as mission statements and taglines), collateral (such as business card and PowerPoint templates), and more are aggregated and described in brand identity guidelines.

▪ It’s essential for a brand to present itself in a cohesive manner across an increasing number of media, channels, and touchpoints. How can everyone within an organization speak in one voice and feel part of a singular entity? How do third parties know which Pantone colors to use and how to correctly use the brand’s logo? Brand identity guidelines provide answers to these fundamental questions in one centralized hub.

▪ Historically, brand identity guidelines were contained in hard-cover books (remember, those things with the pages?), but as with everything else, brand style guides are making their way online.

▪ While brand identity guidelines are fairly tactile, design language guidelines are a bit harder to pin down. Design language style guides articulate a general design direction, philosophy, and approach to specific projects or products.

▪ To present itself in a cohesive way across a growing range of products and media, Google developed a design language called material design. The material design style guide defines its overarching design philosophy, goals, and general principles, while also providing specific applications of the material design language.

▪ Voice is an elemental aspect of a brand’s identity, so typically brand identity guidelines include some reference to the brand’s voice. However, these guidelines usually aren’t very nuanced, which is why voice and tone guidelines are so important.

▪ Mailchimp’s Voice and Tone guidelines

▪ Writing style guides can be extremely granular, defining particulars around punctuation and grammar, but they don’t always have to be so detailed. Dalhousie University’s writing style guide provides a concise list of principles and best practices for content contributors to follow.

▪ GitHub’s code style guide provides best practices for writing HTML, CSS, JavaScript, and Ruby within their organization.

▪ Code style guides provide conventions, patterns, and examples for how teams should approach their code. These guidelines and guardrails help rein in the madness so that teams can focus on producing great work together rather than refactoring a bunch of sloppy, inconsistent code.

▪ The rest of this book will concentrate on how to approach interface design in a systematic manner, and detail how to establish and maintain pattern libraries.

▪ Web style guides promote consistency and cohesion across a user interface. This consistency benefits both the people who create these interfaces and also their users.

▪ Style guides help iron out these inconsistencies by encouraging reuse of interface elements. Designers and developers can refer back to existing patterns to ensure the work they’re producing is consistent with what’s already been established.

▪ A shared vocabulary

What does “utility toolbar” mean? Does everyone understand what a “touch slider hero” is?

▪ For true collaboration to occur, it’s essential for teams to speak a common language. Style guides are there to help establish that shared vocabulary.

▪ In her book Front-End Style Guides, Anna Debenham deftly explains the many advantages of creating style guides, including one of the most crucial benefits: education.

▪ Education isn’t just important for clients and stakeholders. A good style guide helps inform designers and developers of the tools they have in their toolbox, and provides rules and best practices for how to use them properly.

▪ By making a style guide a cornerstone of your workflow (which we’ll detail in chapter 4), designers and developers are forced to think about how their decisions affect the broader design system.

▪ Federico Holgado, lead UX developer at MailChimp, explained how MailChimp’s pattern library initially consisted of patterns created from the four primary screens of their app. But once they moved on to other areas of the site, they realized they were able to use existing patterns rather than having to generate brand new patterns from scratch every time.

▪ A style guide provides a rock-solid foundation for all future work, even if that future work may look totally different.

▪ But to reach style guide nirvana, you must first overcome the many treacherous challenges that come with the territory.

▪ To benefit from style guides, organizations must first appropriate the necessary time and budget to make them happen.

▪ A matter of time

The hard part is building the machine that builds the product.” Dennis Crowley

▪ Pattern libraries are often treated as auxiliary projects, rather than as the component parts of the final product.

▪ By treating pattern libraries as something separate from the core project, they tend to fall into the nice to have category and become first on the chopping block when the going gets tough.

▪ This auxiliary project conundrum reminds me of sentiments I often hear around factoring accessibility into projects. They say, “Oh, we wish we had the time and budget for accessibility, but…” The notion that accessibility (and other principles like performance and responsiveness) is a costly extra line item is a fallacy.

▪ Pattern libraries, like accessibility, are good ideas to bake into your workflow whether or not the project plan explicitly calls for them.

▪ A maintenance and governance strategy is critical to style guides’ success. Style guides will be thrown in the trash (right beside all those PSDs and wireframes) and abandoned without a proper strategy in place for who will manage, maintain, and enforce them.

▪ Yelp's style guide homepage sports a handsome design and important intro text explaining the purpose and audience for the guide.

▪ Context is key to understanding a design system. Unfortunately, most pattern libraries out in the wild don’t provide any hints as to when, how, and where their components get used. Without providing context, designers and developers don’t know how global a particular pattern is, and as a result wouldn’t know which pages of their app would need to be revisited, QA’d, and tested if changes were made.

▪ As much as I adore the pattern libraries out there, I can’t help but notice a lack of structure in many of them. Don’t get me wrong, I think it’s absolutely fantastic that teams are thinking systematically and are documenting their UI patterns. But I often feel like many pattern libraries are little more than loosely arranged sprays of modules. I think there’s room for improvement.

▪ For us to create experiences for this eclectic web landscape, we must evolve beyond the page metaphor that’s been with us since the birth of the web. Thankfully, organizations are embracing modularity across every aspect of the web creation process, which is leading to smarter work and more sustainable systems.

▪ As the number of devices, browsers, and environments continues to increase at a staggering rate, the need to create thoughtful, deliberate interface design systems is becoming more apparent than ever.

▪ As it turns out, loads of other fields such as industrial design and architecture have developed smart modular systems for manufacturing immensely complex objects like airplanes, ships, and skyscrapers.

▪ In the natural world, atomic elements combine together to form molecules. These molecules can combine further to form relatively complex organisms.

▪ Of course, I’m simplifying the incredibly rich composition of the universe, but the basic gist remains: atoms combine together to form molecules, which further combine to form organisms. This atomic theory means that all matter in the known universe can be broken down into a finite set of atomic elements:

▪ Josh Duck’s Periodic Table of HTML Elements beautifully articulates how all of our websites, apps, intranets, hoobadyboops, and whatevers are all composed of the same HTML elements.

▪ Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. The five stages of atomic design are:

Atoms Molecules Organisms Templates Pages

▪ These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional.

▪ For example, a form label, search input, and button can join together to create a search form molecule.

▪ Creating simple components helps UI designers and developers adhere to the single responsibility principle, an age-old computer science precept that encourages a “do one thing and do it well”

▪ Therefore, creating simple UI molecules makes testing easier, encourages reusability, and promotes consistency throughout the interface.

▪ The header forms a standalone section of an interface, even though it contains several smaller pieces of interface with their own unique properties and functionality.

▪ Building up from molecules to more elaborate organisms provides designers and developers with an important sense of context.

▪ Another important characteristic of templates is that they focus on the page’s underlying content structure rather than the page’s final content.

▪ Design systems must account for the dynamic nature of content, so it’s very helpful to articulate important properties of components like image sizes and character lengths for headings and text passages.

▪ You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is. Mark Boulton

▪ With actual content in place, we're able to see if the UI components making up the page properly serve the content being poured into them.

▪ Here are just a few examples of template variations:

A user has one item in their shopping cart and another user has ten items in their cart. A web app’s dashboard typically shows recent activity, but that section is suppressed for first-time users. One article headline might be 40 characters long, while another article headline might be 340 characters long. Users with administrative privileges might see additional buttons and options on their dashboard compared to users who aren’t admins.

▪ In all of these examples, the underlying templates are the same, but the user interfaces change to reflect the dynamic nature of the content. These variations directly influence how the underlying molecules, organisms, and templates are constructed.

▪ Therefore, creating pages that account for these variations helps us create more resilient design systems.

▪ In his book The Shape of Design, Frank Chimero beautifully articulates the power this traversal provides:

▪ The painter, when at a distance from the easel, can assess and analyze the whole of the work from this vantage. He scrutinizes and listens, chooses the next stroke to make, then approaches the canvas to do it. Then, he steps back again to see what he’s done in relation to the whole. It is a dance of switching contexts, a pitter-patter pacing across the studio floor that produces a tight feedback loop between mark-making and mark-assessing. Frank Chimero

▪ Atomic design provides us a structure to navigate between the parts and the whole of our UIs, which is why it’s crucial to reiterate that atomic design is not a linear process. It would be foolish to design buttons and other elements in isolation, then cross our fingers and hope everything comes together to form a cohesive whole.

▪ So don’t interpret the five stages of atomic design as “Step 1: atoms; Step 2: molecules; Step 3: organisms; Step 4: templates; Step 5: pages.” Instead, think of the stages of atomic design as a mental model that allows us to concurrently create final UIs and their underlying design systems.

▪ Discussing design and content is a bit like discussing the chicken and the egg. Mark Boulton explains:

Content needs to be structured and structuring alters your content, designing alters content. It’s not ‘content then design’, or ‘content or design’. It’s ‘content and design’. Mark Boulton

▪ A well-crafted design system caters to the content that lives inside it, and well-crafted content is aware of how it’s presented in the context of a UI. The interface patterns we establish must accurately reflect the nature of the text, images, and other content that live inside them.

▪ Similarly, our content should be aware of the manner in which it will be presented. The close relationship between content and design requires us to consider both as we construct our UIs.

▪ Atomic design gives us a language for discussing the structure of our UI patterns and also the content that goes inside those patterns.

▪ While there is a clean separation between the content structure skeleton (templates) and the final content (pages), atomic design recognizes the two very much influence each other. For instance, take the following example:

▪ Person One would suggest, “Why not just name them elements, modules, and components?”

▪ The issue with terms like components and modules is that a sense of hierarchy can’t be deduced from the names alone.

▪ That being said, naming things is hard and imperfect. The names I’ve chosen for the stages of atomic design have worked really well for me and the teams I’ve worked with as we create UI design systems.

▪ As we showed our initial design system concepts that used the Atomic Design taxonomy to our colleagues, we were met with the some confused looks. […] The evidence was clear, for this to be successful within our organization we had to make the taxonomy more approachable. Jeff Crossman, GE Design

▪ “Atomic design” as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma.

▪ Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

▪ But it’s important to understand that atomic design applies to all user interfaces, not just web-based ones.

▪ You can apply the atomic design methodology to the user interface of any software: Microsoft Word, Keynote, Photoshop, your bank’s ATM, whatever. To demonstrate, let’s apply atomic design to the native mobile app Instagram.

▪ Let me be clear about this: atomic design has nothing to do with web-specific subjects like CSS or JavaScript architecture.

▪ The cornerstone of pattern-based design and development is the pattern library, which serves as a centralized hub of all the UI components that comprise your user interface.

▪ They promote consistency and cohesion across the entire experience. They speed up your team’s workflow, saving time and money. They establish a more collaborative workflow between all disciplines involved in a project. They establish a shared vocabulary between everyone in an organization, including outside vendors. They provide helpful documentation to help educate stakeholders, colleagues, and even third parties. They make cross-browser/device, performance, and accessibility testing easier. They serve as a future-friendly foundation for teams to modify, extend, and improve on over time.

▪ No single tool will be a perfect fit for every setup and scenario, but be sure to keep the following principles in mind when deciding what tools to use to create your pattern libraries.

▪ Matryoshka dolls (also known as Russian nesting dolls) are beautifully carved hollow wooden dolls of increasing size that are placed inside one another. Patterns in Pattern Lab operate in a similar manner: the smallest patterns (atoms) are included inside bigger patterns (molecules), which are included in even bigger patterns (organisms), which are in turn included in even bigger patterns (templates).

▪ Constructing UIs in this manner keeps things DRY, which is a long-standing computer science principle that stands for “don’t repeat yourself.”

▪ This Russian nesting doll approach to building UIs is simple but tremendously powerful. The structure allows designers and developers to keep patterns DRY, saving time, effort, and money. The approach allows teams to build a final UI while simultaneously creating the underlying UI design system.

▪ Historically, designers working with static tools have had a tendency to only design best-case scenarios. You know what I’m talking about: the user’s name is Sara Smith and always fits neatly on one line; her profile picture looks like it was clipped out of a magazine; her profile is completely filled out; the two columns of her profile content are exactly the same height.

▪ Of course, these best-case scenarios rarely, if ever, occur in the real world.

▪ To create more robust and resilient designs, we need to concurrently account for the best situations and the worst – and everything in between.

▪ What if the user doesn’t upload a profile picture? What if the user has 87 items in their shopping cart? What if the product has 14 options? What if the blog post title contains 400 characters? What about a returning user? A first-time user? What if the article doesn’t have any comments? What if it has seven layers of nested comments? What if we need to display an urgent message on the dashboard?

▪ Articulating these UI variations in a static design tool is an exercise in tediousness and redundancy, which may explain why they’re rarely designed.

▪ Sometimes we may need it to be a full-bleed element occupying the entire viewport. Other times we may need to include it in the context of an article. And still other times we may want to include it in the sidebar.

▪ The dream is to build our components fluidly and they’ll adapt their styles and functionality to fit whatever containers we put them into.

▪ Indeed, this is the promise of container queries. Container queries let elements adapt based on their parent containers rather than the entire viewport, which is how we manipulate elements using media queries at the moment.

▪ While still being developed as a native browser capability, container queries will allow us pattern-crazed designers and developers to easily create and deploy fluid UI systems.

▪ Many early responsive design testing tools focused on viewing designs on popular mobile device widths, such as 320px (an iPhone 4 in portrait mode), 480px (an iPhone 4 in landscape mode), 768px (an iPad in portrait mode), and so on. But, of course, the web is much more diverse than a mobile view, a tablet view, and a desktop view.

▪ Companies like Lonely Planet have achieved the holy grail of pattern libraries, which is to say their pattern library and production environment are perfectly in sync.

▪ Ultimately, whichever pattern library tool you decide to use should have some form of code view.

▪ Perhaps more importantly, the pattern libraries you create should showcase the types of code that enable you and your development team to be as effective as possible.

▪ Pattern Lab displays important pattern documentation right alongside the living pattern examples, which helps teams communicate definitions, usage, examples, outside resources, and more.

▪ Thanks to the Russian nesting doll include approach described earlier, Pattern Lab can display what patterns make up any given component, and also show where those patterns are employed in the design system.

▪ When choosing tools to create your pattern library, you should keep your eyes open for these qualities and features of effective pattern libraries:

Providing pattern descriptions and annotations. Showcasing the relevant pattern HTML, templating, CSS, and/or JavaScript code. Viewing patterns across the entire resolution spectrum. The ability to showcase pattern variations, such as active or disabled tabs. The ability to dynamically add real representative content into the patterns’ structures. Providing contextual information, like which patterns make up a particular component, as well as where that component is used.

▪ At the end of the day, it’s not about the tools we use to create pattern libraries, but rather how we use them.

▪ Creating and maintaining an effective design system means dramatically changing your organization’s culture, processes, and workflows.

▪ If that sounds hard to you, it’s because it is. But fear not!

▪ The interface inventory exercise generates a ton of screenshots, so naturally you’ll need software to capture and display those screenshots.

▪ We’ve come a long way from simply transplanting print PDFs to the World Wide Web, but print design still casts a long shadow and continues to influence how things get done online.

▪ The design process is weird and complicated, because people are weird and complicated. Mark Boulton

▪ You can have all the right technologies in place, use the latest and greatest tools, and even have extraordinarily talented individuals on board, but if everyone involved isn’t actually cooperating and communicating with one another then you’re not going to create great work. It’s as simple as that.

▪ That’s not to say you can’t create good work, but more often than not you’re going to create one of the many disappointing shades of bad work.

▪ Establishing and maintaining successful interface design systems requires an organization-wide effort, and this chapter will discuss how to overcome human beings’ many quirks to make them happen.

▪ So when’s the best time to establish an interface design system? Short answer: now.

▪ Design systems and their accompanying pattern libraries are often created in conjunction with a new design or redesign project, replatforming effort, or other initiative.

▪ Piggybacking off another project is a great way to sneak a pattern library into your organization.

▪ Introducing a new way of doing things is no easy task, as it requires changing people’s existing mentalities and behaviors.

▪ It’s necessary to introduce the concept of interface design systems to your clients, colleagues, and stakeholders. Explain what these design systems are and the many ways they can help the organization.

▪ Alas, I’ve found that I can hype design systems until I’m blue in the face, but the suits don’t always see things through the same lens as the people on the ground.

▪ Design systems lead to cohesive, consistent experiences. That means users master your UI faster, leading to more conversions and more money based on the metrics your stakeholders care about.

▪ Design systems speed up your team’s workflow. Rather than reinventing the wheel every time a new request comes through, teams can reuse already established UI puzzle pieces to roll out new pages and features faster than ever before.

▪ Centralizing UI components in a pattern library establishes a shared vocabulary for everyone in the organization, and creates a more collaborative workflow across all disciplines. With everyone speaking the same language, more time is spent getting work done and less time is spent dealing with superfluous back-and-forth communications and meetings.

▪ Design systems make cross-browser/device, performance, and accessibility testing easier, vastly speeding up production time and allowing teams to launch higher-quality work faster. Also, baking things like accessibility into a living design system scales those best practices, allowing your interfaces to reach more users while reducing the risk of you getting sued!

▪ Framing things in terms of time and money helps the people controlling the purse strings understand why a design system is a worthwhile pursuit.

▪ Many are familiar with the concept of a content inventory. Content audits are usually performed in the early stages of a website redesign process to take stock of all a site’s content. It’s a tedious process involving spreadsheets and caffeine, but all that hard work pays off. By the end of the exercise the organization’s content is laid out on the table, giving teams valuable insights into how to handle their content as they tackle the project.

▪ An interface inventory is similar to a content inventory, only instead of sifting through and categorizing content, you’re taking stock of and categorizing all the components that make up your user interface. An interface inventory is a comprehensive collection of the bits and pieces that make up your user interface.

▪ How do you go about conducting an interface audit? How do you round up all the components that make up your UI? The simple answer is screenshots. Lots of them! Creating an interface inventory requires screenshotting and loosely categorizing all the unique components that make up your user interfaces.

▪ I’ve encountered many ambitious designers and developers who have taken it upon themselves to start documenting their organization’s UI patterns. While I certainly applaud this individual ambition, it’s absolutely essential to get all members of the team to experience the pain of an inconsistent UI for them to start thinking systematically.

▪ For the interface inventory to be as effective as possible, representatives from all disciplines responsible for the success of the site should be in a room together for the exercise. Round up the troops: UX designers, visual designers, front-end developers, back-end developers, copywriters, content strategists, project managers, business owners, QA, and any other stakeholders. The more the merrier! After all, one of the most crucial results of this exercise is to establish a shared vocabulary for everyone in the organization, and that requires input from the entire team.

▪ It's important for all participants to capture screenshots using the same software so they can be combined later.

▪ I’ve found online slide-building software like Google Slides to be very effective as it provides a canvas for free-form image positioning, they’re chunked out into slides for easier categorization, and they’re web-based so can be shared with ease.

▪ Bear in mind this exercise doesn’t mean capturing every instance of a particular UI pattern, but rather capturing one instance of each unique UI pattern.

▪ Assign each participant a UI category. You may need to pair people or have participants document multiple categories, depending on how many people are taking part in the exercise. Once again, it’s helpful to have as many participants as possible since more people screenshotting will result in more thorough documentation.

▪ What interface element categories should be captured? Obviously, the categories are going to vary from interface to interface, but here are a few categories to start with:

▪ Global elements: components like headers, footers, and other global elements that are shared across the entire experience.

▪ Navigation: primary navigation, footer navigation, pagination, breadcrumbs, interactive component controls, and essentially anything that’s used to navigate around a user interface.

▪ Image types: logos, hero images, avatars, thumbnails, backgrounds, and any other type of image pattern that shows up in the UI.

▪ Icons: icons are a special type of image worthy of their own category. Capture magnifying glasses, social icons, arrows, hamburgers, spinners, favicons, and every other interface icon.

▪ Forms: inputs, text areas, select menus, checkboxes, switches, radio buttons, sliders, and other forms of user input.

▪ Buttons: buttons are the quintessential UI element. Capture all the unique button patterns found throughout the experience: primary, secondary, big, small, disabled, active, loading, and even buttons that look like text links.

▪ Headings: h1, h2, h3, h4, h5, h6 and variations of typographic headings.

▪ Blocks: also known as touts, callouts, summaries, ads, or hero units, blocks are collections of typographic headings and/or images and/or summary text (see Nicole Sullivan’s write-up about the media object as an example of a block).

▪ Lists: unordered, ordered, definition, bulleted, numbered, lined, striped, or any group of elements presented in a list-type format.

▪ Interactive components: accordions, tabs, carousels, and other functional modules with moving parts.

▪ Media: video players, audio players and other rich media elements.

▪ Third-party components: widgets, iframes, stock tickers, social buttons, invisible tracking scripts, and anything else that isn’t hosted on your domain.

▪ Advertising: all ad formats and dimensions.

▪ Messaging: alerts, success, errors, warnings, validation, loaders, popups, tooltips, and so on. This can be a challenging category to capture as messaging often requires user action to expose.

▪ Colors: capture all unique colors presented in the interface. This category can be aided by fantastic style guide bootstrapping tools like CSS Stats and Stylify Me.

▪ Animation: animation is an elemental aspect of user interfaces, and should therefore be documented. This requires using screen recording software such as QuickTime to capture any UI element that moves, fades, shakes, transitions, or shimmies across the screen.

▪ It’s important to set time limits on the screenshotting exercise to avoid going down a rabbit hole that ends up lasting all day.

▪ The amount of time you allocate will vary depending on how many people are participating, but I find between 30 and 90 minutes to be sufficient for a first pass of an interface inventory.

▪ Have each participant spend five or ten minutes presenting each UI category to the group.

▪ Presenting to the group allows the team to discuss the rationale behind existing UI patterns, kick-starts a conversation about naming conventions, and gets the team excited to establish a more consistent interface.

▪ Naming things is hard. It’s fascinating to hear the inconsistent names designers, developers, product owners, and other stakeholders all have for the same UI pattern. “Oh, we call that the utility bar.” “Oh, we call it the admin nav.” “Oh, we call it the floating action area!” This exercise is an opportunity to unearth and iron out disparities between pattern labels, and also establish names for previously unlabeled patterns.

▪ Don’t feel like you need to come to a consensus on patterns’ final names in the course of ten minutes; this exercise is simply meant to open up a broader discussion.

▪ Once every category has been presented and discussed, all the participants should send their slides to the exercise leader. The leader will then combine everything into one giant über-document, which will soon become a wrecking ball of truth and justice.

▪ One of the most powerful benefits of interface inventories is that you can show them to anyone, including non-designers and developers, and they’ll understand why inconsistent UIs are problematic. You don’t need to be a designer to recognize that having 37 unique button styles probably isn’t a good idea. Here’s your opportunity to make it crystal clear to stakeholders that approaching your UI in a more systematic way makes great sense for both your users and your organization.

▪ It’s very likely the initial exercise didn’t capture every unique UI pattern, so you may need to conduct another interface audit exercise to capture a more complete picture of your UI patterns. This may involve a large group again, but in reality a smaller, cross-disciplinary team will be going through the über-document and establishing next steps for the design system.

▪ Once the gaps in the interface inventory have been filled, the working group can have some important conversations about next steps for the design system project.

▪ Captures all patterns and their inconsistencies: an interface inventory rounds up all the unique patterns that make up your UI. Seeing all those similar, but still different, patterns next to each other exposes redundancy and underscores the need to create a consistent, cohesive experience.

▪ Establishes a scope of work: an interface inventory helps design teams determine the level of effort required to design and build each UI pattern as part of a design or redesign project.

▪ Taking the time to organize the pieces that make up your final creations allows you to approach the work in a more deliberate and efficient manner.

▪ No doubt organizing takes time, planning, and effort. It doesn’t come for free. The fact that this configuring isn’t visibly represented in the final product may tempt us to say it serves as a distraction to the real work that needs to be done.

▪ Creating a library of your available materials allows you to approach the project in a more methodical way, and saves immense amounts of time in the process. Rather than rummaging through a haphazard pile of bricks and burning time reinventing patterns, you can create an organized system of components that will help produce better work in a shorter amount of time.

▪ When I say “set expectations” I’m really saying “reset expectations.” You see, we all bring our own experiences, opinions, and biases to a project. Our industry is still incredibly young, so many people working on web projects are coming from other industries with their own established Ways Of Doing Things™.

▪ Even people who have worked exclusively in the digital world have felt the baggage of industries past. Moreover, the guiding principles, best practices, and tactics of digital design are still very much being codified.

▪ It’s ludicrous for anyone to utter the phrase, “This is how we’ve always done things” in an industry that’s only 25 years old.

▪ Design in the print world focuses heavily on visual aesthetics. After all, you can’t do much more with a poster than look at it. To be clear, I’m certainly not implying print design is easy or one-dimensional; the world of print is steeped in nuance and craft.

▪ What I am saying is that the bidirectional and interactive nature of the web adds many more dimensions to what constitutes good design. Speed, screen size, environment, technological capabilities, form-factor, ergonomics, usability, accessibility, context, and user preferences must be considered if we want to create great work for this brave new digital world.

▪ During the formative years of the web we created experiences meant to be consumed solely by desktop computers, which is understandable since desktops were really the only game in town. The real estate provided by desktop screens made the idea of simply translating a PDF onto the web feasible and enticing. So that’s what we did—and for a while it actually worked!

▪ However, this didn’t come without consequences. This print-like perspective of the web reinforced the notion that web designs, like their offline counterparts, could and should look the same in every environment. It also kept the focus on how a web design looked rather than how it worked, ignoring all the unique characteristics of this rich new medium. Moreover, it strengthened the belief that we could apply the same linear processes used to create print work to our digital work.

▪ Time went by, of course, and mobile exploded, technology improved, and the web become the incredibly large and diverse landscape we know today. Gone are the desktop-only days of yore, and in their place is a time of smartphones, dumb phones, tablets, phablets, netbooks, notebooks, e-readers, wearables, TVs, game consoles, car dashboards, and so much more.

▪ The diversity of today’s web landscape has shattered the consensual hallucination of the desktop web, where we could simply bolt on the mentalities and processes of print to this new medium. Simply looking at a smartphone, tablet, and desktop machine next to one another quickly erodes the assumption that a web design should look the same in every environment.

▪ We’re still at the very beginning of the Big Bang of connected devices. The device and web landscape of tomorrow will undoubtedly be even bigger and diverse than today’s. In addition to current devices and the nascent technologies already on the horizon, the future web will involve technologies and ideas that haven’t yet been conceived.

▪ It’s our job to create great experiences for people using a diversity of devices, screen sizes, network speeds, device capabilities, browser features, input types, form factors, contexts, and preferences.

▪ That’s undoubtedly a Herculean task, but all these variables really underscore the need to extend far beyond visual aesthetics when creating interface design systems.

▪ Comps, like any other design artifact, are used to facilitate a conversation with the project stakeholders. If their feedback is, “This feels all wrong,” then it’s back to the drawing board to create a new comp. But if their feedback suggests, “Can we move this from here to here? Can we add a gray border around the article text? Can we increase the size of this image?” that’s a sign the overall direction is in good shape and those relatively minor issues can be addressed in the browser.

▪ Embrace the ubiquity of the web by creating accessible, resilient design systems. Recognize that a whole slew of people with a vast spectrum of capabilities will be accessing our experiences, so construct design systems to be as inclusive as possible.

▪ Create flexible layouts and components so our interfaces look and function beautifully irrespective of any particular device dimension or screen size.

▪ Treat performance as an essential design principle and create fast-loading experiences that respect users and their time.

▪ Progressively enhance our interfaces by establishing core experiences then layering on enhancements to take advantage of the unique capabilities of modern devices and browsers.

▪ Create future-friendly design systems meant to stand the test of time and anticipate inevitable changes to the device and web landscape.

▪ Of course, there are many other design considerations that should be included in our interface design systems (ergonomics, input type, Section 508 compliance, legibility, and so on), but the key takeaway here is to expand the definition of what constitutes good digital design beyond visual aesthetics

▪ What’s wrong with the design, exactly? Maybe it’s the seven typefaces and nine unique button styles peppered throughout the comps. Maybe it’s the desktop-centric, impossible-to-actually-execute layout. Maybe it’s the perfect-yet-improbable user-generated content.

▪ The waterfall process may make sense for print, architecture, manufacturing, and other physical media since mistakes and changes are extraordinarily costly. If a team overlooks an error made early in the process, they’ll pay dearly for it later. However, the digital world isn’t constrained by the same limitations as the physical one. Pixels are cheap.

▪ Changes can happen in an instant, hypotheses can be quickly tested out, and designs and code can be iterated on again and again.

▪ The waterfall process hinges on the premise that work must flow in a sequential order: the UX designer’s work must be completed before visual design can start; the visual designer must finish their job before front-end development can begin. This simply isn’t true. There is much work that can and should happen in parallel. To create sound UI design systems, we must reset our stakeholders’ expectations and get them comfortable with a blurrier, more collaborative process.

▪ Of course, the bulk of research, information architecture, and other elemental aspects of UX design will tend to happen earlier in the process, but that work shouldn’t delay the other disciplines from starting their jobs. And even when the bulk of a person’s active work is done, they should never simply fade away from the project. It’s crucial for every discipline to continue to consult with the others to ensure their vision makes it into the final product. So rather than a rigid, sequential waterfall process, a more collaborative process over time looks something like this:

▪ A more collaborative workflow involves a cross-disciplinary team working together throughout the entire process. While active work will wax and wane, each discipline continues to consult with the other team members to ensure their insights are present in the final work.

▪ When a previous employer discovered I wrote HTML, CSS, and presentational JavaScript, they moved me to sit with the engineers and back-end developers. Before too long I was being asked, “Hey, Brad. How long is that middleware going to take to build?” and “Can you normalize this database real quick?”

▪ There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still code, front-end development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages.

▪ This misunderstanding tends to give many front-end developers, myself included, a severe identity crisis.

▪ Designers and developers often sit on different floors, in different buildings altogether, in different cities, and sometimes even in different countries on different continents. While some of this organizational separation may be justified, creating a division between designers and front-end developers is an absolutely terrible idea.

▪ The fact remains that HTML, CSS, and presentational JavaScript build user interfaces—yes, the same user interfaces that those designers are meticulously crafting in tools like Photoshop and Sketch.

▪ For teams to build successful user interface design systems together, it’s crucial to treat front-end development as a core part of the design process.

▪ When you show stakeholders only static pictures of websites, they can naturally only comment and sign off on pictures of websites. This sets the wrong expectations. But by getting the design into the browser as fast as possible, you confront stakeholders with the realities of the final medium much sooner in the process.

▪ Working in HTML, CSS, and presentational JavaScript allows teams to not only create aesthetically beautiful designs, but demonstrates those uniquely digital design considerations like:

flexibility impact of the network interaction motion ergonomics color and text rendering pixel density scrolling performance device and browser quirks user preferences

▪ Crucially, jumping into the browser faster also kick-starts the creation of the patterns that will make up the living, breathing design system.

▪ This is not to say teams must design entirely in the browser. As with anything, it’s about using the right tools at the right time to articulate the right things. Having the design represented in the browser in addition to other design artifacts gives teams the ability to paint a richer, more realistic picture of the UI they’re crafting. Teams may demonstrate an aesthetically focused design idea as a static image, and simultaneously demonstrate a working prototype of that same idea in the browser.

▪ An iterative digital process is similar to subtractive stone sculpture, where fidelity is built up over many iterations.

▪ It’s more important to make steps in the right direction than exhaust a ton of effort painting unrealistic pictures of what you want the final piece to be.

▪ A sound design system doesn’t roll off an assembly line, but is rather sculpted in iterative loops, building up fidelity as the project progresses.

▪ If this all sounds a bit messy, that’s because it is! To the dismay of some project managers, the design process doesn’t fit neatly into the rigid borders of Excel spreadsheets and Gantt charts. True collaboration between disciplines is fuzzy and chaotic, and that’s not a bad thing. Constant communication, tight feedback loops, and true collaboration therefore become the glue that holds the process together. Get your entire team to commit to honest conversation and genuine collaboration, and the details of your process will fall into place.

▪ It’s essential to agree on an overall design direction and paint the broad strokes first before moving into high-fidelity design and development. This requires restraint and expectation management, but results in more focused decision-making and more realistic work.

▪ In a traditional waterfall process, many UX designers have gone about this task by generating high-fidelity wireframes that document every screen of the entire user experience. These wireframe documents, stuffed to the gills with black rectangles and annotations, spec out the details of what the interface will accomplish, and are used to get stakeholder buy-in.

▪ As thorough as these documents tend to be, they don’t paint the full picture and often make dangerous assumptions about visual layout and technical functionality.

▪ Rather than jumping straight into such high-fidelity documents, it’s better to start with lo-fi sketches that establish what appears on a particular screen and in what general order.

▪ Establishing the experience’s basic information architecture can be accomplished with a simple bulleted list and a conversation. For a project I did for the Greater Pittsburgh Community Food Bank, I started by stubbing out the basic information architecture for a page on a site.

▪ Making lo-fi wireframes mobile-first means using the constraints of small screens to force the team to focus on the core content and hierarchy. You can now ask, “Do we have the right things on this screen?” “Are they in the right general order?”

▪ As I’ve discovered from subsequent projects, content and display patterns can be effectively communicated in an even simpler format: the lowly spreadsheet.

▪ A simple spreadsheet can articulate what content and display patterns go on a given page while describing their order and purpose.

▪ A visual designer’s job is to create an aesthetic language and apply it to the user interface in a way that aligns with the project’s goals.

▪ To do this, it’s essential for a visual designer to unearth the stakeholders’ aesthetic values.

▪ Historically, visual designers have gone about this by creating full comps—often many comps—to feel out the aesthetic values of the organization. Throw some comps against the wall and see what sticks. As you might imagine, generating a slew of comps from scratch takes an immense amount of time and effort, and unfortunately much of that work finds itself on the cutting room floor. There must be a more efficient way.

▪ A fantastic exercise for quickly establishing aesthetic values is the 20-second gut test. Typically done as part of the project kick-off meeting, the exercise involves showing the stakeholders a handful of pertinent websites (about twenty to thirty of them) for twenty seconds each. The sites you choose should be a healthy blend of industry-specific sites and other visually interesting sites from other industries.

▪ For each site presented, each person votes on a scale from 1 to 10, where a score of 1 means “If this were our site I would quit my job and cry myself to sleep,” while a score of 10 means “If this were our site I would be absolutely ecstatic!”

▪ Instruct participants to consider visual properties they find interesting, such as typography, color, density, layout, illustration style, and general vibe.

▪ This exercise exposes stakeholders to a variety of aesthetic directions early in the process, allows them to work through differences in taste, and (with any luck) helps arrive at some shared aesthetic values.

▪ The visual designer can then latch on to these insights and begin to translate those aesthetic values into a visual direction for the project.

▪ It’s essential to establish a solid visual direction for the project, so how does a visual designer do that without burning a ton of time on up-front high-fidelity comps? That’s the question that designer Samantha Warren answered when she created style tiles, a deliverable that’s more tangible than a mood board but not as high-fidelity as a fully baked comp.

▪ They can be designed much faster because they’re not encumbered by the expectations of high-fidelity comps, which means feedback and discussion can happen sooner

▪ Crucially, style tiles also reinforce pattern-based thinking by educating stakeholders about design systems rather than pages. Presenting color swatches, type examples, and textures exposes stakeholders to the ingredients that will underpin any implementation of the design system.

▪ Somewhere in between style tiles and full comps live element collages, which are collections of UI component design explorations. Element collages provide a playground for designers to apply design atmosphere to actual interface elements, yet still be free from layout and highly polished presentation.

▪ It’s very clear these collages aren’t an actual website, but stakeholders can still get a sense of what the site could look like.

▪ Conversation about these element collages can give visual designers more ideas and direction about where to take the design next, and because of their lo-fi nature, designers can quickly iterate and evolve ideas.

▪ No doubt other tactics exist to establish aesthetic direction for your projects, and which techniques you decide to employ will vary from project to project. But the key is to paint some broader strokes before spending a lot of time and effort on highly detailed design work.

▪ Including front-end development as a critical part of the design process requires changes to both project structure and team members’ mentalities.

▪ In the restaurant business, an important yet unsung role is that of the prep chef. A prep chef chops vegetables, marinades meat, and makes salads in preparation for the following day’s work. By having ingredients prepared ahead of time, the kitchen staff can focus on collaboration and cooking rather than menial tasks. Without the up-front work of the prep chef, the flow of the main chefs would be interrupted and the fast pace of the kitchen would grind to a halt.

▪ A prep chef chops vegetables, marinades meat, makes salads, and prepares other ingredients so that the main kitchen staff can focus on cooking meals and collaboration.

Front-end developers need to be the prep chefs of the web design process.

▪ If developers aren’t coding from day one of the project, there’s something wrong with the process.

▪ “But Brad,” I can hear you saying, “how can I start coding if I don’t know what I’m supposed to code?”

▪ This front-end prep chef work frees up developers’ time to collaborate with designers, rather than working after design is complete. With basic markup in place, developers can work with designers to help validate UX design decisions through conversations and working prototypes. They can help visual designers better understand source order and web layout, and can quickly produce a fledgling codebase that will eventually evolve into the final product.

▪ UX designers can create lo-fi sketches to establish basic information architecture and some anticipated UI patterns.

▪ Visual designers can gather the teams’ aesthetic values by conducting a 20-second gut test exercise, then create style tiles and element collages to explore initial design directions.

▪ Frontend developers can set up project dependencies, stub out basic templates, and write structural markup for patterns the team anticipates using in the project.

▪ This work can happen concurrently but shouldn’t happen in isolation. Sure, there will need to be some initial head-down time for each discipline to get set up, but all team members should be fully aware of each discipline’s explorations in anticipation of working together to evolve these ideas.

▪ Ideas are meant to be ugly. Jason Santa Maria

▪ The point is for the team to generate ideas and solve problems, not to enforce a rigid order of operations.

▪ By approaching this design exploration in a cross-disciplinary way, teams can find balance between aesthetics, technical feasibility, usability, and functionality.

▪ But how do teams turn a vague sense of direction into a beautiful, functional, usable, and complete design system?

▪ Turning explorations into finished patterns is a blurry, imperfect process. This should come as absolutely no surprise to you by this point in the book.

▪ Seeing these partially designed prototypes might look unusual to those used to more traditional, pixel-perfect design deliverables. But it’s far more important to communicate progress than a false sense of perfection, which is why rolling updates are preferable to big reveals.

▪ But I’ll never forget this client feedback we received on the first pattern-driven project I worked on: “These element collages look great, but it’s like you’re asking me to comment on how beautiful a face is by showing me the nose.”

▪ Static comps are effective at painting a full picture of what the UI could look like. The trick is knowing when to paint those full pictures, and knowing how long to dwell in static design documents

▪ For the TechCrunch project, we created a comp for the article template only after the client was feeling good about our element collage explorations.

▪ Creating full comps requires a lot of effort, which is why we established the design direction first to mitigate the risk of all that full-comp effort going straight into the trash if we got it totally wrong.

▪ Static comps can be great for shaping the overall aesthetic direction of a template, but users will ultimately view and interact with the experience in a browser. That’s why designs should be quickly translated into the final environment and iterated on there.

▪ Static design comps cannot deal with all these considerations, so they should be treated merely as hypotheses rather than set-in-stone specifications. Only when transferred to the browser can any design hypothesis truly be confirmed or rejected.

▪ Let’s change the phrase “designing in the browser” to “deciding in the browser.” Dan Mall

▪ Once the designs are in the browser, they should stay in the browser. At this stage in the process, the point of production shifts to team members adept at crafting HTML, CSS, and presentational JavaScript. Patterns should be created, styled, and plugged in wherever they’re needed. Designers can react to these in-browser implementations and can create spot comps in static tools to help iron out responsive wrinkles at the organism level. This back-and-forth between static and in-browser tools establishes a healthy loop between design and development, where the front-end code becomes more solid and stable with each iterative loop.

▪ By getting designs into the browser sooner, teams can iterate over the design and address the many considerations that can only be dealt with once the design is in the browser.

▪ UX designers are hitting the prototype hard to make sure the flows and interactions are all logical and intuitive. Visual designers are combing over the interface and proposing design tweaks to the UI to polish up the design. Front-end developers are testing the experience in a slew of browsers and devices while also addressing design feedback. Back-end developers are hard at work integrating the front-end UI into the CMS (we’ll talk more about the relationship between front-end and back-end in chapter 5). And, of course, the clients and stakeholders are making last-minute demands—I mean suggestions—about the design and content. The whole team is contributing documentation for the style guide, cleaning up the patterns in the pattern library, and working hard to get the website off the ground.

▪ And then there are external agencies, contractors, and consultants. What is the role of a third party when it comes to long-term maintenance of a client’s design system? On one hand, external partners are at a bit of a disadvantage since they don’t actually work for their client’s organization.

▪ There’s a very real risk that a style guide will end up in the trash can right alongside all the PSDs, PDFs and those other static artifacts of the design process. Despite everyone’s best intentions, all the time and effort that went into making a thoughtful design system and style guide can go straight down the drain.

▪ A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. Nathan Curtis

▪ A style guide can provide documentation and serve as a helpful resource, but the simple existence of a style guide doesn’t guarantee long-term success for the underlying design system. A design system needs ongoing maintenance, support, and tender loving care for it to truly thrive.

▪ To save our style guides from the bowels of a trash can, we must once again fundamentally rewire people’s brains.

▪ Once the pattern library ceases to reflect the current state of the products it serves, it becomes obsolete. And when the pattern library managing the design system is no longer accurate, the website maintenance process devolves into a smattering of hotfixes and ad hoc changes, ruining all the thoughtfulness that went into creating the original design system.

▪ This “design system first” mentality inserts a bit of friction into the maintenance process, and that friction can be friendly. It forces us to step back and consider how any improvements, client requests, feature additions, and iterations affect the overall system rather than only a sliver of the whole ecosystem.

▪ Broken behavior and opportunities to enhance the UI will often be realized at the application level, but those changes should often be acted on at the system level.

▪ Adding this bit of friendly friction into your workflow ensures improvements are shared across the entire ecosystem, and prevents the system from being eroded by a series of one-off changes.

▪ Another expectation we must revisit is our definition of done. Creating things for print and other physical media involves making permanent, tangible objects. That sense of finality simply doesn’t exist in the digital world, which means change can happen with much less effort and friction than other media.

▪ Clients, colleagues, and stakeholders should embrace the pliable nature of the digital world to create living design systems that adapt to the ever-shifting nature of the medium, user needs, and the needs of the business.

▪ If we’re committed to creating genuinely useful work that truly meets the needs of our clients and organizations, we must fundamentally redefine the scope of our work. As Nathan Curtis says, a design system shouldn’t be a project with a finite scope, but rather a product meant to grow and evolve over time:

▪ Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products. Nathan Curtis

▪ The web is never done, and the creation of a design system is merely the first step in a long (and hopefully fruitful!) journey. A design system should be a long-term commitment with the ambitious goal of revolutionizing how your organization creates digital work.

▪ Organic beginnings are all well and good, but in order to establish a truly impactful design system that creates long-term success for your organization, the design system needs to evolve into an officially sanctioned endeavor. That means thinking of it as a true product rather than a simple side project, and consequently allocating real time, budget, and people to it.

▪ Get team members from different disciplines to back you up and discuss the initial success of the system, and also pull in others who are sympathetic to the cause who would stand to benefit from an expanded design system.

▪ With approval from the highest levels, you’re now able to put a plan into action that involves: allocating or hiring people to work on the design system; developing a plan to make it more robust; establishing a clear governance strategy; and laying out a product roadmap.

▪ First things first. It’s important to recognize that there will inevitably be people at the organization who help make and maintain the design system, and there will be people who will be users of the design system.

▪ But here’s the thing: not everyone in the organization needs to contribute directly to the design system, but someone (or more likely, some people) must take ownership of it.

▪ The design system makers are the ones who create, maintain, and govern the system, and they need to work closely together to ensure that the system is smart, flexible, scalable, and addresses the needs of the users and business. The design system users are the teams across the organization who will take the system and employ its interface patterns to specific applications.

▪ The design system makers and design system users need to maintain a close working relationship to ensure the patterns defined within the system serve the needs of the applications, and that all documentation is clear. Makers provide a birds-eye perspective of the entire ecosystem the design system serves, while users provide an on-the-ground perspective focused on specific applications of the system

▪ Both outlooks are critical to the success of the design system, which is why it’s so important for makers and users to have a healthy relationship that involves frequent communication and collaboration.

▪ Large organizations are able to dedicate serious resources to managing design systems. Salesforce, for example, maintains an official design systems team, which currently includes about a dozen full-time employees, last I heard.

▪ When a design system is serving literally thousands of users, it’s a smart idea to dedicate at least a few full-time employees to manage and expand the system.

▪ Smaller organizations most likely don’t have the luxury of building an entire team to service a design system. Team members in smaller organizations have to wear many (hopefully stylish!) hats out of necessity, so governing the design system will likely become another responsibility.

▪ Typically, design system makers at smaller organizations will be senior-level staff who have the experience to make thoughtful decisions, and the authority to enforce the design system.

▪ A successful design system needs to become part of an organization’s DNA, and since third parties exist outside the company’s walls, their influence is intrinsically limited.

▪ But on the other hand, external parties can often provide a sense of perspective that’s hard to see while working inside a company. This is where outsiders can really shine. In my work as a consultant, I work with organizations to establish long-term design system maintenance strategies, and help get the right people and processes in place.

▪ While the long-term success of the system will ultimately be up to the organization, third parties can teach them to fish and provide important strategic guidance, feedback, and perspective.

▪ Who are the people responsible for using the design system to build new features and applications? Who are the people who talk with the system makers to report issues and request features?

Once again, the answers to these questions will largely depend on your organization’s size and structure.

▪ You may work on a singular product at a scrappy startup, so your small team could be simultaneously creating and using the design system. Or you may work at a large multinational corporation with development teams and third-party partners scattered all across the globe. If this is the case, design system makers and users may seldom (or ever) meet, which means that helpful documentation and a sharp birds-eye perspective become that much more important.

▪ A cross-disciplinary team should be established to properly manage, maintain, and extend the system. All disciplines at an organization – UX designers, visual designers, content strategists, front-end developers, back-end developers, product managers, project managers, executives, and other stakeholders – have unique perspectives that can undoubtedly inform and shape the work.

▪ There will inevitably be disciplines that actively do the work, while others may take on more of an advisory role. Those responsible for designing and building the user interface – UX designers, visual designers, front-end developers — will likely serve as the hands that do the work and make updates to the design system.

▪ Other people may not be the ones actively doing the work, but must be consulted to make sure their perspectives are properly reflected in the system.

▪ Change is the only constant, as they say. The living part of a living design system means that it needs to roll with the punches, adapt to feedback, be iterated on, and evolve alongside the products it serves.

▪ A misconception about design systems is that once they’re established, they become an omnipotent and unchangeable source of truth.

▪ Thinking in such a rigid way is a surefire way to have your design system effort backfire. If users feel handcuffed and pigeonholed into using patterns that don’t solve their problems, they’ll perceive the design system as a unhelpful tool and start searching elsewhere for something that will better address their needs.

▪ A solid governance strategy starts by answering some important questions about handling change.

▪ What happens when an existing pattern doesn’t quite work for a specific application? Does the pattern get modified? Do you recommend using a different pattern? Does a new pattern need creating?

▪ How are new pattern requests handled?

▪ How are old patterns retired?

▪ What happens when bugs are found?

▪ Who approves changes to the design system?

▪ Who is responsible for keeping documentation up to date?

▪ Who actually makes changes to the system’s UI patterns?

▪ How are design system changes deployed to live applications?

▪ How will people find out about changes?

▪ There are likely many more specific questions to answer, but the point is your team should have answers and processes in place to address inevitable changes to the system.

▪ Make it as easy as possible for users and makers to communicate. Set up a design system Slack or Yammer channel, establish regular office hours, make sure your bug ticket software helps facilitate conversation, and keep the doors open for ad hoc chats and calls.

▪ If users are stuck on something, they should know exactly where and who to turn to for help.

▪ In addition to informal day-to-day conversation between makers and users, schedule regular “state of the union” meetings to review the design system with makers, users, and other key stakeholders.

▪ Keeping patterns fresh is essential for the long-term health of the design system.

▪ Care should be taken when adding patterns to the library. If every whim results in a brand new pattern, the design system will become a bloated and unwieldy Wild West.

▪ It’s worth asking if this is a one-off situation or something that can be leveraged in other applications.

Perhaps you may want to assume a one-off until a different team encounters a similar use case.

▪ The biggest existential threat to any system is neglect. Alex Schleifer, Airbnb

▪ Many systems fall into a state of disrepair because the effort required to make updates is far too high. If it’s difficult and time-consuming to update patterns, documentation, and applications, people will eventually get so frustrated that they stop making the effort and the design system will begin its drift into oblivion.

▪ Making updates to UI patterns, documentation, and applications should be as frictionless as possible, so reducing this friction should become a high priority for the design system team.

▪ The design system holy grail involves creating an environment where the pattern library and live applications are perfectly in sync.

▪ The idea is that you should be able to make a change to a UI pattern and see that change automatically reflected in both the pattern library and anywhere the pattern is included in production.

▪ As it turns out, this dream can be a reality. Lonely Planet, the travel guide company, was one of the first to establish a holy grail design system called Rizzo.

▪ Keeping a pattern library in sync with production environments requires sharing code in a smart, scalable, and maintainable way.

▪ In his article “Chasing the Holy Grail*,” web developer Marcelo Somers details various technical approaches to achieving the holy grail. He highlights the pros and cons of each strategy for feeding a design system into applications to keep both codebases in lockstep.

▪ While I won’t detail each of Marcelo’s strategies, it’s worth noting there is a spectrum of approaches to choose from: crude, manual front-end code copying-and-pasting on one end, to baking the pattern library directly into the production environment on the other.

▪ In my experience, I’ve found that sharing CSS and presentational JavaScript with production environments is relatively easy, while sharing markup is tough.

▪ You’d provide development teams with a versioned URL (e.g., http://mycdn.com/1.3.5/styles.css) and upgrading is as simple as bumping the version number in the URL. Marcelo Somers

▪ Using HTML templating languages (such as Mustache, Handlebars, Twig, Underscore, Jade, Nunjucks, and a slew of others) makes markup more portable and dynamic.

▪ The vastness and decentralized nature of the organization means that a synchronized pattern library isn’t really achievable without some dramatic restructuring of how federal government websites get built.

▪ If a relatively scattered, decentralized culture is your reality, don’t be disheartened! Even getting some design system in place – a handful of go-to UI patterns, some helpful documentation, and guiding principles – can show your organization the light that points towards the grail.

▪ Of course, a pattern library needs to be helpful for the people actually making use of the patterns, but treating a style guide solely as a developer resource limits its potential.

▪ A style guide has the opportunity to serve as a watering hole for the entire organization, helping establish a common vocabulary for every discipline invested in the success of the company’s digital products.

▪ That’s why the style guide should be an inviting place for everybody, not just design system users.

▪ It should come as a surprise to no one that people tend to gravitate towards attractive things. A big part of making a style guide a cross-disciplinary resource is ensuring the container that houses your pattern library and other documentation is good-looking, inviting, and easy to navigate.

▪ Make a thing. Show that it’s useful. Make it official.

▪ Making a good-looking style guide isn’t just design for design’s sake; it reflects an organization’s commitment to making and maintaining a thoughtful, deliberate design system.

▪ You can create the best style guide in world, use the most sophisticated technology, have an amazing team in place, and have excited users, but if you don’t actively promote the design system and communicate changes, the entire effort will suffer greatly.

▪ Here are some materials that can help communicate change:

Change logs: “Here’s what’s changed in the pattern library this month.” Roadmap: “Here’s what’s coming up over the next few months.” Success stories: “Team X launched this great new application using the design system; read more about how they did it.” Tips and tricks: “Here are a few best practices and considerations for using our system’s buttons throughout your application.”

Having a base for all these materials is a great idea, and keeping them adjacent to (or even within) the style guide itself makes a lot of sense as well.

▪ Design system changes, updates, and requests should be communicated wherever your team hangs out. That may include Slack, Basecamp, GitHub, wikis, Yammer, email lists, company blogs, intranets, and any other internal tools your team uses to communicate and collaborate. If that sounds like a lot of work to you, fear not! Keeping your team and users updated doesn’t have to require a huge manual effort.

▪ Whenever someone makes a pull request, it sends a notification to our #Design slack channel, announcing to the team that there is a proposal change and feedback is required. Micah Sivitz, Shyp

▪ Baking this communication into the team’s everyday workflow keeps makers, users, and stakeholders engaged, and helps reassure users that the pattern library is being actively maintained and improved.

▪ Documentation in the form of a style guide is no doubt helpful, but by itself it’s not enough. It’s essential to provide adequate training and offer ongoing support for your design system’s users to ensure they successfully get up and running with the tool kit and continue to create great work with it.

▪ Training users how to work with the design system can take many forms, including:

Pair sessions: Nothing beats pulling up a chair and working together on a project. While more time-intensive than other training vehicles, it’s the best way to get makers and users collaborating together, learning how the system works, and exposing new opportunities and shortcomings. Workshops: From immersive full-day sessions to quick walk-throughs, it’s incredibly helpful to set up face-to-face training workshops involving both makers and users. These sessions can help smooth out any misconceptions about the system, help level-up users with hands-on guidance, and create a healthy relationship between the people in charge of maintaining the system and the people in charge of working with it. Webinars: If workshops or pair sessions aren’t possible, or you need to train a lot of users at scale, webinars can be fantastic. Users can tune into online sessions to learn about how to properly use the system. When conducting webinars, be sure to build in plenty of Q&A time to field both audio and typed questions, concerns, and comments. Tutorials: A series of blog posts and screencasts can neatly encapsulate core concepts of working with the design system. Not only do these help serve as a training tool, but they can serve as a great reference to keep coming back to. Onboarding: A great way of injecting your design system into your company culture is to bake design system training right into the onboarding process for new employees. New colleagues will understand the importance of modularity, reuse, and all the other benefits a design system brings.

▪ Users will undoubtedly have questions or encounter issues once they get up and running and start building things with the design system. They need to know there’s a robust support system in place to help answer any questions, listen to their requirements, and address bugs. There are a host of mechanisms in place to provide support for users, including:

Issue trackers: Tools like JIRA and GitHub Issues are great for users and makers to report bugs and have technical conversations. Users should be aware of the protocol for filing bugs and feel empowered to contribute. Office hours: Schedule regular times when the design system team is available to field questions, address issues, and talk about what’s next for the design system. Slack and chat tools: The real-time nature of many of our work collaboration tools presents a huge opportunity to keep the pattern-laden conversation going. Thanks to tools like Slack, Yammer, and HipChat, makers and users can engage one another whenever and wherever. Forums: Communities like Stack Overflow and GitHub have proved to be extremely effective at enabling grassroots, community-driven support. Rather than design system makers becoming a support bottleneck, it can be worthwhile to open up support to the entire user community. Outreach: Not everyone has the time or the personality to ask questions and suggest changes. Design system makers should be proactive and reach out to developers using the design system to see if they have any issues or concerns. These kinds of actions can help build a genuine and positive relationship between makers and users.

▪ The Draft U.S. Web Digital Standards system tracks issues using GitHub, providing a place for users and makers to file bugs and have conversations about the nitty-gritty.

▪ Here are some tactics for encouraging user contributions:

Suggestions and pull requests: Encourage anyone using the design system to suggest changes and new features. Better yet, invite users to submit changes in the form of pull requests that can be merged directly back into the codebase. Individual interviews and roundtable discussions: It’s always a good idea to talk to users, so regularly schedule time to chat with the people who are touching these patterns on a regular basis. Take it all in, listen to both the good and the bad, and collectively determine a plan of attack to address any issues and suggestions. Requests for feedback: Managing a system that can potentially be deployed to hundreds of applications can be tricky. Before pulling the trigger on decisions that could impact a lot of people, ask for opinions: “We’re considering deprecating our carousel pattern and would like to hear what you think.” Surveys: If interviews aren’t feasible, you can lean on quick surveys to get a feel for how effective UI patterns and the style guide are. Questions like “On a scale from one to five, how useful is the pattern documentation? Any suggestions?” can help identify blind spots and get users to suggest features that would make their lives easier. Regular “state of the union” meetings: Schedule regular meetings where the design system team discusses the product roadmap, lessons learned along the way, and suggestions and feedback. Encourage anyone to join the meeting, and be sure to record and distribute these sessions so everyone is aware of the master plan.

▪ Publishing your style guide for the world to see increases its visibility, increases accountability, and serves as an amazing recruitment tool.

▪ Public-facing style guides are also hugely helpful for recruiting. Designers, developers, and people working in other disciplines want to work for organizations that embrace modern digital best practices, and (as we’ve discussed throughout this book) design systems are quickly becoming an industry-wide best practice. Publishing your style guide sends out a strong Bat-Signal that can attract passionate, pattern-minded people. For instance, style guide expert Jina Bolton went to work at Salesforce after seeing the company’s style guide for their Salesforce1 product.

▪ Jina’s story is not an isolated one; almost every guest Anna Debenham and I interviewed on the Styleguides Podcast discussed how helpful their public-facing pattern library was for attracting talent. All that means your public style guide makes your organization more competitive, not less.

▪ Intuit's Harmony design system includes a pattern library, design principles, voice and tone, marketing guidelines, and more. Housing this helpful documentation under one roof helps increase its visibility and effectiveness.

▪ Another way to extend the functionality of the pattern library is to include guidelines for native platform patterns alongside web-based patterns. We can look to Intuit’s Harmony design system once again for an example of how native mobile platform patterns for iOS and Android can live beside their web-based counterparts.

▪ Intuit's Harmony pattern library includes buttons to switch between web, iOS, and Android for each pattern. This allows the team to maintain a mostly consistent design system across platforms but also document pattern divergences when they occur.

▪ Fair warning: naming things is really freaking hard. But there are strategies to help you create robust names for your patterns. Conducting an interface inventory (as detailed in chapter 4) helps remove patterns from the context of the page where they normally reside, meaning your team can create names that aren’t distracted by their context. I’ve conducted naming exercises with teams where we’ve blurred out the content residing inside a pattern so everyone can focus on the pattern’s structure rather than the content that lives inside it.

▪ A good exercise when naming patterns is to blur out the content so your names reflect the patterns' structures rather than the content living inside them.

▪ Showcasing UI patterns in a pattern library is all well and good, but you need to demonstrate context for design system users to understand how and where to properly use them.

▪ One way to demonstrate context might include showing screenshots or videos of a component in action. Material design’s documentation does a fantastic job at this; each component is rich with photos, videos, and usage details to give users a clear understanding of what these patterns look like in the context of an application, and demonstrate how each pattern should be used.

▪ Another way to show context is to provide lineage information for each pattern. As we discussed in Chapter 3, a tool like Pattern Lab automatically generates this information, letting you see which patterns make up any given component in addition to showing where each component is employed. This provides a sort of pattern paper trail that helps immensely with QA efforts, as it highlights exactly which patterns and templates would need to be tested if changes were made to a particular pattern.

▪ As we’ve discussed throughout this chapter, making your design system stand the test of time requires a significant amount of time and effort. But isn’t that the case with all living things? Animals need to eat, and plants need water and sunlight in order to survive. Creating a living design system means giving it attention and care in order for it to continue to thrive.