Chapter 3 Tools of the Trade

Greetings, reader! The following text is a work in progress so be warned you will encounter incomplete thoughts, grammar errors, and more. If you see something worth fixing, please submit an issue on Github. Thanks and happy reading!

In the last chapter, I introduced the atomic design methodology for constructing user interfaces. Hopefully you’ll find atomic design to be a helpful mental model for constructing UI design systems, but now it’s time to climb down from the ivory tower and actually put atomic design into practice in the real world.

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. As we discussed in Chapter 1, the benefits of pattern libraries are many:

That all sounds wonderful, right? I can almost hear you saying, “I need this whole pattern library thing in my life.” But how do we make pattern libraries happen? Well, you’ve come to the right place, friend, because the rest of this book is dedicated to exactly that. This chapter will introduce helpful tools for creating pattern libraries, and the following chapter will discuss how to make patterns a cornerstone of your design and development workflow.

I’ll be talking about the qualities of effective pattern libraries through the lens of a tool called Pattern Lab, an open-source project created by me and Dave Olsen to execute atomic design systems. While I’ll excitedly discuss Pattern Lab and its various features, I want to stress that the point of this chapter is to cover the characteristics of well-constructed pattern libraries, not sell any one specific tool to you. Hell, Pattern Lab isn’t even for sale! No single tool will be a perfect fit for all readers, but be sure to keep the following principles in mind when deciding what tools to use to create your pattern libraries.

Just what exactly is Pattern Lab?

Before we dive into the nuts and bolts of how Pattern Lab works, it’s important to take time to explain what the tool is and isn’t.

Pattern Lab is…

Pattern Lab isn’t…

Let’s walk through these points, starting with the term static site generator. Static site generator tools take in some source code & assets, compile them, and spit plain-ol’ HTML, CSS, and JavaScript out the other end. Pattern Lab takes source code – namely patterns – and compiles those patterns into a functional front-end UI inside a pattern library shell.

So what does Pattern Lab look like out of the box? Drumroll, please.

The default Pattern Lab dashboard. What it lacks in good looks, it makes up for in utility.
The default Pattern Lab dashboard. What it lacks in good looks, it makes up for in utility.

Not a terribly inspiring design, eh? Believe it or not, this minimal (one may even say “lack of”) design is deliberate. To avoid incorrect classification as a UI framework like Bootstrap, the design is deliberately stripped down so no one would mistakenly use Pattern Lab’s demo UI as suggested styles. Pattern Lab doesn’t give you any answers as to how to design or architect your front-end code; you have to do all that work yourself. The look & feel, naming conventions, syntax, structure, libraries, and scripts you choose to use to create your UI is entirely up to you. Heck, you can even use UI frameworks like Bootstrap within Pattern Lab. Pattern Lab is just there to help stitch everything together.

As a technical aside, Pattern Lab uses PHP as the engine that stitches patterns together and generates the pattern library. However, you don’t need to be a PHP wizard to use Pattern Lab any more than you have to know how to build an internal combustion engine in order to drive a car. Moreover, your final website doesn’t have to be built with PHP in order to use the tool, as Pattern Lab’s output is backend-agnostic HTML, CSS, and JavaScript. But if you’re one of those cool kids who thinks using a PHP-based tool will somehow ruin your reputation, there’s also a Node.js version thanks to web developer Brian Muenzenmeyer.

If that all sounded like gibberish to you, don’t worry. This chapter focuses on the over-arching features and principles behind Pattern Lab rather than going too far down the technical rabbit hole. You can check out Pattern Lab’s documentation to dive into the nitty gritty.

Building atomic design systems with Pattern Lab

In order to understand the core concept behind Pattern Lab, you need to understand Russian nesting dolls.

Russian nesting dolls. <a href='https://www.flickr.com/photos/tromal/6901848291/'>via Flickr user Tromal</a>
Russian nesting dolls. via Flickr user Tromal

Matryoshka dolls, also known as Russian nesting dolls, are beautifully-carved hollow wooden dolls of increasing size that are placed one inside the other. 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 helps keeps things DRY, which is a long-standing computer science principle that stands for “Don’t Repeat Yourself.” Make a change to a pattern, and anywhere that pattern is employed will magically update with those changes. This saves an extraordinary amount of time and grief, and certainly beats the pants off sifting through hundreds of Photoshop documents for every instance of a pattern just to make a simple change.

To make this happen Pattern Lab uses the include feature of Mustache, a logic-less templating language. Here’s what a Mustache include looks like:


{{> atom-thumbnail }}

This is Mustache code, in case the double curly braces ({{}}) that look like little mustaches didn’t give it away. The greater than symbol (>) is Mustache’s way of telling Pattern Lab “hey, I want you to include an atom pattern called “thumbnail”. Pattern Lab will go searching through its folders of patterns to find an atom named “thumbnail”.

This is what Pattern Lab's default patterns folder structure looks like. You can name and categorize these folders however you'd like, even removing the labels 'atoms', 'molecules', and 'organisms'. The most important consideration is to establish naming & categorization that is most clear for your team.
This is what Pattern Lab's default patterns folder structure looks like. You can name and categorize these folders however you'd like, even removing the labels 'atoms', 'molecules', and 'organisms'. The most important consideration is to establish naming & categorization that is most clear for your team.

Now that we know what an include looks like, let’s put it into practice and take a look at a few patterns from a website I helped make for Time Inc. Here’s one reusable pattern we designed:

For Time Inc.'s website, we created a basic block pattern consisting of a thumbnail image, headline, and excerpt.
For Time Inc.'s website, we created a basic block pattern consisting of a thumbnail image, headline, and excerpt.

This pattern should look fairly familiar. A thumbnail image, headline, and excerpt working together as a single unit is a common pattern found on countless websites. Let’s take a peek behind the curtain to see how this pattern is constructed:

[Note from Brad: Forgive the mess with the markup formatting. I need to look into how to properly escape characters and highlight syntax in a way that works for the site but also for the eventual ebook.]



\<div class="block-post"\>
    \<a href="{{ url }}"\>
        {{> atoms-thumb }}
        \<h3\>{{ headline }}\</h3\>
       \<p\>{{ excerpt }}\</p\>
    \</a\>
\</div\>


You can see we have HTML markup consisting of a wrapper div with a class name of block-post, a link, a Mustache include for the thumbnail image, a <h3> tag for the headline, and a <p> tag for the excerpt. You’ll notice there’s more Mustache code for url, headline, and excerpt, which we’ll use later to dynamically swap in actual content. More on that in a bit.

Now that we have our pattern markup established, we can now include that chunk of code in even bigger patterns using the same include method:


{{> molecules-block-post }}

Now let’s move up to more complex organisms like the website’s header, which looks a little something like this:

The website header consists of fairly common conventions like a logo atom, primary navigation molecule, and a search form molecule.
The website header consists of fairly common conventions like a logo atom, primary navigation molecule, and a search form molecule.

When we crack open the hood to look at the header’s markup in Pattern Lab, we see the following:



\<header role="banner"\>
    {{> atoms-logo }}
    {{> molecules-primary-nav }}
    {{> molecules-search }}
\</header\>


What’s going on here? Well, we have a basic <header> tag, and inside that tag we’re including the logo image atom, the primary navigation molecule, and the search form molecule.

And now we can include that relatively complex pattern anywhere we need it.


{{> organisms-header }}

Hopefully by now you can see the Russian nesting dolls taking shape. The smallest atoms are included in bigger molecules, and those molecules get included in even bigger organisms. Now let’s take these components and plug them into a layout. Take the homepage template, for instance:

The Time Inc. homepage template consists of a few repeatable patterns: a global header, a hero area, a few sections (containing an image, headline, excerpt, and call to action), an area featuring four items, a 'factoid' area, and a global footer.
The Time Inc. homepage template consists of a few repeatable patterns: a global header, a hero area, a few sections (containing an image, headline, excerpt, and call to action), an area featuring four items, a 'factoid' area, and a global footer.

Take a quick stroll through the homepage template and you’ll see some pretty standard patterns: a site header at the top, a site footer at the bottom, and a full-screen hero area. You’ll also see a few other patterns repeating themselves throughout the template.

So how does this look in code? As you might expect, it involves more includes!



{{> organisms-header }}
\<main role="main"\>
    {{# hero }}
    {{> molecules-hero }}
    {{/ hero }}
    \<section\>
        {{# experience-block }}
        {{> molecules-block-main }}
        {{/ experience-block }}
        {{# experience-feature }}
        {{> organisms-story-feature }}
        {{/ experience-feature }}
    \</section\>
    \<section\>
        {{# factoid-advertising }}
        {{> organisms-factoid }}
        {{/ factoid-advertising }}
    \</section\>
    \<section\>
        {{# advertising }}
        {{> molecules-block-main }}
        {{/ advertising }}
    \</section\>
    …   
  \</main\>
  {{> organisms-footer }}
\</div\>


At this stage in the game the smaller patterns are already constructed, so all the template needs to do is pull them into the context of a page layout and give them unique names.

Taking a closer look at the code, notice certain patterns like {{> organisms-header }} and {{> organisms-footer }} are included the same way we’ve done with the prior examples. But there are also a few other includes patterns that are supplemented by some additional information, like the following:



{{# factoid-advertising }}
{{> organisms-factoid }}
{{/ factoid-advertising }}


We’re including organisms-factoid the same way as all the other patterns, but we’re also naming it factoid-advertising by wrapping the include in a mustache section, indicated by the mustache code containing the # and / symbols. By giving the pattern instance a unique name, we can latch onto it and dynamically replace the content of the pattern. More on that in the next section!

This Russian nesting doll approach to building UIs is simple but tremendously powerful. This structure allows designers and developers to keep patterns DRY saving time, effort, and money. This approach also allows teams to build a final UI while simultaneously creating the underlying UI design system. After all, the final interface is one instantiation of its underlying design system. Teams can also traverse between abstract and concrete, zeroing in on a particular pattern to fix bugs (“The header’s broken!”), while also seeing how changes to small patterns affect the overall page layout.

Working with dynamic data

It’s important to articulate the underlying content structure of UI patterns within the context of a pattern library. That’s why we’ve been looking at dimension-displaying grayscale images and placeholder text containing character limits. But while this information is helpful for creative teams, grayscale images and lorem ipsum text are not what end users interact with on your actual site. We need a way to replace our default dummy content with real representative content in order to ensure our UI patterns match the reality of the content that lives inside them.

To demonstrate how Pattern Lab dynamically swaps in real content into templates, let’s take a look at a side-by-side comparison of Time Inc.’s homepage template and page levels:

A side-by-side comparison of Time Inc.'s homepage template and page levels. The template articulates the content structure of the design system, while the page shows what the system looks like with real content poured into it.
A side-by-side comparison of Time Inc.'s homepage template and page levels. The template articulates the content structure of the design system, while the page shows what the system looks like with real content poured into it.

On the left we have the template level, which articulates the content structure of the patterns making up the webpage. And on the right we have the page level, where we’re pouring in real representative content to demonstrate what the final UI might look like and test the effectiveness of the design system.

So how do we swap dummy content for real content in Pattern Lab? Pattern Lab uses JSON (as well as YAML, Markdown, and other data formats) to define and swap out the dynamic bits of content in our designs.

The default placeholder data is defined in a file called data.json that lives in Pattern Lab’s source directory. Inside this file we define all the text, image paths, and other dynamic data that will make up our UI. Here’s a small sample from Time Inc.’s data.json file:



"hero" : {
  "headline": "Lorem Ipsum",
  "img": {
    "src": "/images/sample/fpo_hero.png",
    "alt": "Hero Image"
  }
}


For developers, this type of format most likely looks familiar. If you’re not a developer, don’t freak out! Once you look beyond the curly braces and quotes, you’ll see that we’re defining a hero object (for the full-bleed hero area directly below the header) that has a headline value of “Lorem Ipsum” and an img with a src value of “/images/sample/fpo_hero.png”. We’re simply defining this object’s attributes and providing values for those attributes.

Once those objects are defined, then we can override their attributes at Pattern Lab’s page level. This is accomplished by creating a new JSON file that matches the page pattern name (for Time Inc.’s homepage, we’ll call it homepage.json) inside the pages directory.

Inside the 'pages' directory we have the homepage pattern as well as a JSON file that matches the name of the pattern. This is where we'll override the default content with page-specific content.
Inside the 'pages' directory we have the homepage pattern as well as a JSON file that matches the name of the pattern. This is where we'll override the default content with page-specific content.

When we open up homepage.json we can override the placeholder data we established earlier. Here’s what that might look like:



"hero" : {
  "headline": "Moving People",
  "img": {
    "src": "/images/hero_beyonce.jpg",
    "alt": "Beyonce"
  }
}


By overriding the default data, the hero headline now reads “Moving People” instead of “Lorem Ipsum”. And instead of pointing to a grayscale FPO (for placement only) hero image, we’re now pointing to a picture of Beyoncè located at "/images/hero_beyonce.jpg".

This process of establishing defaults for dynamic data then replacing it with page-specific content continues for each section of the website. In addition to replacing simple strings like headings, we can also dynamically set variables to true or false, loop through an array of items, and more. We can even dramatically alter the UI with just a few changes to a JSON file, which we’ll talk about next!

Articulating pattern variations with pseudo-patterns

Historically designers working in static tools have had a tendancy 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 magically are exactly the same height.

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

In order to create more robust and resilient designs, we need to concurrently account for the best situations, 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? Return user? 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. But if we want to create systems that address all the variables and realities of our content, we must take those “what if” questions into account.

How do we address all manner of UI variation without exhausting ourselves in the process? Pattern Lab’s pseudo-pattern feature allows us to articulate (sometimes wildly) different scenarios with just a few changes to our data.

Let’s say we’re making an app whose dashboard displays a list of project collaborators. The UI might look something like this:

A list of project collaboratos in our hypothetical app
A list of project collaboratos in our hypothetical app

To create the dynamic content inside each of these blocks, we’ll define our list of collaborators as an array inside dashboard.json:



"collaborators" : [
  {
    "img": "/images/sample/avatar1.jpg",
    "name" : "Steve Boomshakalaka",
    "title" : "CIA"
  },
  {
    "img": "/images/sample/avatar2.jpg",
    "name" : "Gingersnap Jujubees-Daniels",
    "title" : "President of the Longest Company Name in the World Corporation, Global Division"
  },
  {
    "img": "/images/sample/avatar3.jpg",
    "name" : "Sarunus Marciulionis",
    "title" : "Golden State Warriors"
  },
  {
    "img": "/images/sample/avatar4.jpg",
    "name" : "Sara Smith",
    "title" : "Short Title"
  }
]


By default, our design assumes the user is a regular user and not an administrator, but what if we wanted to give administrators the ability to manage project collaborators from the dashboard? That UI might look something like this:

The administrator's dashboard UI introduces extra 'edit' and 'delete' actions.
The administrator's dashboard UI introduces extra 'edit' and 'delete' actions.

In order to show additional admin “edit” and “delete” actions on the dashboard in Pattern Lab, we can create a pseudo-pattern, a new file in the pages folder that looks like this:



dashboard~admin.json


The tilde (~) symbol indicates a pseudo-pattern. dashboard~admin.json will inherit all the data contained in dashboard.json, but also gives us the opportunity to append or override additional data. That means the list of collaborators we defined earlier in dashboard.json is still available, but we can add additional data inside dashboard~admin.json like so:



"isAdmin" : true


We’re defining a variable called isAdmin and setting it to true. We can now use that to conditionally include the additional actions inside the block pattern.



\<div class="block"\>
  \<img src="{{ img }}" alt="{{ name }}" /\>
  \<h3\>{{ name }}\</h3\>
  \<h4\>{{ title }}\</h4\>
  {{# isAdmin }}
  {{> molecules-block-actions }}
  {{/ isAdmin }}
\</div\>


The first few lines are pulling in the img, name, and title we defined in dashboard.json. But pay close attention to what’s wrapped in the isAdmin mustache section. What we’re saying here is “if isAdmin is set to true, include a molecule pattern called block-actions.” The block-actions pattern contains the “edit” and “delete” buttons, and will only display if isAdmin is set to true (or anything besides false). In our default dashboard.json, isAdmin isn’t set so the extra actions won’t display. In dashboard~admin.json, we’re setting isAdmin to true so the extra actions will display. You can extend this technique to dramatically alter the entire UI (like altering the primary navigation, showing additional panels on the dashboard, adding extra controls, etc) just by changing a single variable. Powerful stuff indeed.

Whew. If you’ve made it this far, congratulations! You now know how to add and manipulate dynamic data in Pattern Lab. Pattern Lab’s ability to design with dynamic data provides some very crucial benefits:

We’ve now covered Pattern Lab’s core functionality, but we’re not done yet! Next we’ll cover a few additional features that should be considered irrespective of what tool you use to create your pattern library.

Viewport tools for flexible patterns

The myriad of devices now accessing the Web has forced designers to re-embrace the intrinsic fluidity of the medium. Thankfully, techniques like responsive web design allow us to create layouts that look and function beautifully on any screen.

It’s a no-brainer that we need to establish flexible UI patterns if we want to create responsive designs, but creating fluid patterns has additional advantages. The more fluid a UI component is, the more resilient and versatile it becomes. Imagine being able to take a component — let’s say a photo gallery slider — and plunk it anywhere we need it. 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 themselves based on their parent container rather than the entire viewport, which is currently how we adapt elements using @media queries. 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.

So between responsive design, container queries, and good ol’-fashioned common sense, we now understand why it’s so imperative to create flexible UI patterns. But how do we do that? And how can our pattern library tools help us think and act flexibly?

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, “tablet” view, and a “desktop” view. To help designers better consider the entire resolution spectrum when testing their responsive designs, I created a tool called ish..

The tool is called “ish.” because selecting the small button results in a “small-ish” viewport. Selecting it again provides a different “small-ish” viewport. Selecting the medium button gives you a “medium-ish” viewport. And the large button results in a — wait for it — “large-ish” viewport. These randomized values help designers and developers better consider the entire resolution spectrum rather than a handful of popular device dimensions.

Ish. is baked into Pattern Lab, which means we can view our UIs and their underlying patterns across the entire resolution spectrum.

Pattern Lab displaying a design in a small-ish viewport.
Pattern Lab displaying a design in a small-ish viewport.
Pattern Lab displaying a design in a medium-ish viewport.
Pattern Lab displaying a design in a medium-ish viewport.
Pattern Lab displaying a design in a large-ish viewport.
Pattern Lab displaying a design in a large-ish viewport.

While ish. helps designers and developers uncover bugs along the viewport continuum, I’ve found it to be more helpful as a client and colleague education tool. By building a device-agnostic viewport resizing tool directly into the pattern library, clients and colleagues can better appreciate the fact that their design system should look and function great no matter what the viewport size is.

A look under the hood with code view

A common pattern library feature is the ability to peek under the hood and view the underlying code that makes up a particular component. Exposing a UI pattern’s code speeds up development time (I love copying and pasting as much as the next coder) and helps team leaders enforce code syntax and style conventions. This becomes especially rewarding when a ton of developers are touching an organization’s codebase.

The types of code to be highlighted in a pattern library nauturally varies from organization to organization, in order to meet the requirements of the myriad environments, technologies, and conventions used. Most pattern libraries out there in the wild demonstrate patterns’ underlying HTML, while others also include pattern-specific CSS and/or JavaScript. Salesforce’s Lightning design system, for example, shows a pattern’s HTML as well as all the (S)CSS pertaining to that pattern.

Salesforce's Lightning design system showcases the UI components' HTML and SCSS code.
Salesforce's Lightning design system showcases the UI components' HTML and SCSS code.

Showcasing patterns’ front-end code leads to authors writing more consistent code, but that doesn’t guarantee perfection. There’s still room for developers to go rogue and write sloppy, incongruent code, which is why some organizations have gone above and beyond to establish incredibly sophisticated design systems. 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. We’ll discuss the Holy Grail in more detail in the next chapter, but it’s worth brining up in this section to demonstrate how that affects the code exposed in the context of a pattern library. Rather than surfacing HTML and CSS, Lonely Planet’s Rizzo style guide surfaces the include code for teams to pull in the appropriate UI component.

Lonely Planet's Rizzo design system pattern library showcases the template usage.
Lonely Planet's Rizzo design system pattern library showcases the template usage.

This setup allows the core development team to maintain a single source of truth for all patterns’ frontend code. That means the pattern library only needs to provide the code to include a particular pattern in order for developers to get up and running.

Pattern Lab provides the ability to view both a pattern’s underlying HTML as well as the template code used to generate the HTML. It can also be extended to also showcase accompanying CSS and/or JavaScript code.

Pattern Lab's code view demonstrates any pattern's HTML code and
Pattern Lab's code view demonstrates any pattern's HTML code and

Ultimately, whichever pattern library tool you decide to use should have some form of code view feature. And perhaps more importantly, the pattern libraries you create should showcase the types of code that enables you and your development team to be as effective as possible.

Living Documentation and Annotations

In a traditional siloed design process, it’s typical to see lengthy wireframe and spec documents created, debated, and ultimately approved. These documents typically take the form of gigantic PDFs, which is unfortunate considering they often contain all sorts of valuable insights, instructions, and documentation about the design system. Sadly, these bulky artifacts are often thrown into a (virtual) trashcan by the time the project makes its way into production.

This shouldn’t be the case. A UI’s documentation should contain insights from every discipline involved in creating it, and — this is key — should be baked into the living, breathing design system.

Effective pattern libraries carve out a space to define and describe UI components, articulating considerations ranging from accessibility to performance to aesthetics and beyond.

Pattern Lab provides several ways to add pattern descriptions and annotations to a design system. Pattern descriptions can be added by creating a markdown that corresponds with the name of a pattern (i.e. pattern-name.md), which will show the pattern description in the library list view.

Pattern Lab's annotation feature  shows pattern descriptions alongside the patterns themselves.
Pattern Lab's annotation feature shows pattern descriptions alongside the patterns themselves.

Pattern Lab also provides a (dare I say) cool feature that enables you to attach annotations to any UI element and view those annotations in the context of the living, breathing design. When annotations are switched on, each annotated element receives a number when clicked jumps you to the corresponding annotation. This allows teams to view pattern considerations within the context of the full UI. Pretty neat!

Pattern Lab's annotation feature is interactive and baked into the living UI.
Pattern Lab's annotation feature is interactive and baked into the living UI.

Providing context with pattern lineage

When looking at various patterns in a library, I’ve found myself wondering “Great, but where is this component actually used?” Defining and describing pattern characteristics is one thing, but there’s an opportunity to provide additional contextual information about your UI patterns.

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

Pattern Lab's lineage feature displays what patterns make up any component, and also shows all the places that component is employed.
Pattern Lab's lineage feature displays what patterns make up any component, and also shows all the places that component is employed.

In the above example, we have a molecule pattern called block-media-link, which contains an image, headline, and call to action. Looking at the pattern’s lineage, we can see it contains another pattern called atoms-square, which is the circular thumbnail-sized image (the naming is a bit confusing, but we’re using CSS to round the square image’s corners). We can also see where exactly this pattern gets utilized: the profile-nav molecule, the section-media-list organism, the settings-account template, and the settings-account-edit template.

This contextual information is amazingly helpful for designers and developers; I know I use the lineage feature all the time in my own workflow. Let’s say we wanted to make changes to a particular pattern, like doubling the size of the image or adding an additional text element, we’d immediately know which patterns and templates would need retested and QA’d to ensure nothing breaks with the changes. The lineage feature also helps point out unused or underutilized patterns so that teams can weed them out of the pattern library.

To each their own

So there you have it. Pattern Lab provides several helpful features for teams to create deliberate, thoughtful design systems. But as I mentioned before, no one tool is going to be perfect for everyone and every situation. There are ton of tools out there to help you create effective pattern libraries, and which tools you decide on will undoubtedly be influenced by your organization’s environment, technologies, workflow, and personalities.

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

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 next chapter will detail the entire process of creating and maintaining a successful design system to set your organization up for long-term success.