Design Pattern Libraries

No notes for slide

Lucky day, back to back design systems
About me
Jumpstart the process of building a pattern library
This isn’t hard. Pattern libraries aren’t rocket science.

As people who work with digital products, some of our biggest challenges are consistency and upkeep. Patterns libraries can ease that pain and create recognizable experiences for users.

In this presentation I’ll discuss the process of creating, maintaining, and evolving a design language using a pattern library. I’ll also talk about documenting patterns and involving others to create a design consensus.

↳ let’s get this out of the way…

So, what’s a pattern?
Patterns are everywhere. from nature to virtually almost anything that we build.
Provide common understanding for how things should work (books, mice, chairs…they all have an excepted standard for how we interact with them)
Patterns prominent in architecture - imagine trying to build this room without a pattern..it doesn’t work, right?

I’d like to draw a parallel between architecture and digital design because there are a lot of similarities.

↳ Someone who’s widely known for using patterns in architecture is Christopher Alexander

almost 40 years ago architect Christopher Alexander coauthored A Pattern Language with five others
proposed a scalable framework for creating and extending architectural design systems
different scale than what we do, but there are similarities
deal with budgets, scalability, clients, regulations, and other designers.
With this book, Alexander popularized a system to help reduce some of these friction points.

Alexander took inventory and cataloged 200+ architectural patterns
ordered by complexity
Like Atomic Design, the patterns start simple with basic elements (building materials), then scale to rooms, buildings, neighborhoods, towns and regions

↳ The book also recommends a standard for formatting patterns that includes for attributes:

problem statement: This answers the question, “What problem is the solution intended to solve?”
explanation of the solution
example of the solution (in this case an image of the pattern)
explanation of the pattern’s context. How does it play with other patterns and when is it OK and not OK to use a pattern?

Again, I’m referencing this book because its ideas influence how we deal with patterns in digital work
This format will come in handy when we build our own patten library

↳ Dense, technical book, but fascinating

Why should we even care? There are a few reasons.

Represent best practices: These are the ideas that have been tested and validated through frequent use
Increase efficiency: free designers from tedious and repetitive work and give developers reusable code
the end result it faster production of new features and easier maintenance of existing features
Provide Common language: gives team a shared language when we discuss design.

↳ Then the biggest one…Consistent user experience. This can be a huge pain point for users. So let’s talk about consistency.

In order to create products that are useful, usable, and desirable, we need patterns for consistency
consistency is important because helps users gain familiarity and trust with our products

remember Adobe products
Switch between Macromedia and Adobe - relearn and retrain
If they had consistency, it would have improved experience. Users would LOVE products.

We seen this issue with all big players in every industry…When you go from a company’s website, app, portal, admin screens…all look like they come from completely different companies. And that has a huge impact on trust and familiarity with users. So consistency is important.

Let’s pause here and look at the flip side for a minute
I’ve rolled to a number of design systems, and every time some people resist consistency because:
too rigid and monolithic, doesn’t allow variation or consider context of the situation, limits creativity
valid concerns, but ones that we can deal with in other ways that aren’t at the expense of consistency.

↳ So, how can we design for consistency?

We have these awesome things called style guides! Mix together some HTML, CSS, and JavaScript and .

I love web style guides; it’s amazing that we have these resources
insanely lucky to have front-end frameworks like Bootstrap and Foundation. It was less than 4 years ago that Bootstrap was released.
Years ago, start job ask questions about standards

↳ Now frameworks like these are also inspiring teams to roll out their own web style guides. Sites like Lonely Planet, A List Apart, Code for America are all awesome examples

be cool, brand design language: Mozilla’s Sandstone GitHub’s Primer.

my team wanted profound, meaningful name. Looked to art, culture, history. We found a name that was significant to us, and we called called it Blue Ivy. Does anyone know the origin of Blue Ivy?
Anyway…These tools are a huge advancement
Extremely efficient for designers and developers

Style guides are good at showing what the design is and how to implement design
But they don’t typically explain why a pattern is designed a certain way or what the context is

↳ But for designers and developers, style guides leave open to interpretation and fragmentation. Here’s an example.

Let’s take the select list for example. It does what its name says: let’s users make a selection.
We also have radio, toggle, button groups. they do the same things. Style guides are filled with these. How do we know when to use which one?

These are just basic elements. In more specialized apps where custom elements are modular and scalable, and we can turn parts of the design off and on, how do we know when to do what?

↳ Again, I love style guides, but when we’re working with other people, pattern libraries help us make more informed decisions

So let’s talk about the nuts and bolts of building a pattern library: what they are and how to curate one
Pattern libraries are a lot like style guides, but they go beyond how things look . The distinction I’m making is that they provide context and rationale behind design decisions

↳ And if we go back to what I said a few minutes ago, there’s a standard format for documenting a pattern.

So this is it. It’s almost unchanged from what was proposed in A Pattern Language
There are a few small tweaks:
This format is updated to include a summary because…summaries are nice
The second change is the solution example
This is all you need. This is the format for pattern documentation. Any time a new pattern is created, it should include this information.

↳ They typically look like this, which is from YPL

↳ But depending on the makeup, style, or needs of the team, a whole lot more can be documented

This may seem like a lot and it’s not necessary for every team
I know this can seem overwhelming. But a lot of it isn’t text written in a narrative form. On the admin page that runs this thing, you might be checking a simple box that says ready for release.
Related Patterns - go back to example of users needing to make a selection, cross-reference alternative approaches
Dependencies - if you’re building a pattern that uses other patterns, help others understand how that combined pattern is decomposed

↳ This begs the question…how much is too much?

I’ve heard the complaint that nobody reads directions. I know it gives us more street cred to say we threw out the manual, but as designers and developers, it’s OUR J-O-B to know how this stuff works.

OK, i get it, you don’t need instructions for a button. or a select list. Anything less is just being lazy.

The goal of a designer creating a standard should be to document just to communicate a full understanding of a pattern. We want to be concise. If you’ve written more than a page full of content you’ve gone too far.

Something that may not fit into a pattern library is extensive code documentation. If we look at the jQuery UI; it links to the API documentation.

↳ Alright. Now that we’ve talked about formatting patterns, let’s talk discuss what goes into a pattern library

This is where I feel a strong connection to what Brad says when he talks about Atomic Design. elements (HTML)
These are basic building blocks

Element - HTML
Grouped elements - this is what you get when you combine HTML elements together. Something like a select list with a search filter
Pages - like a profile page. One project I was involved in was basically analytics for hospital systems. and we reused the same page pattern for physicians, practice lines, hospitals, and hospital systems. made it easier for us.
Flows - can be something like adding or removing users or a registration process that can involve multiple pages and systems

↳ This stuff is pretty obvious. But where people drop the ball is by only including that stuff. There’s so much more that can be standardized.

Visualizations. When is it OK to use a pie chart vs a line graph?
Here’s a hint: Jan V. White’s Using Charts and Graphs. It has established rules for when to use certain visualizations. Are labels aligned to top, middle, or bottom? If you like Edward Tufte, check out Jan V. White.

Written Content MailChimp’s website voiceandtone.com, which is an awesome example for how to write consistent and contextually-relevant copy. Read every word on that site if you have a hand in writing UI copy or anything on the web.
Gestures: has anyone see the cheat sheets for Adobe products? it’s amazing, and that stuff can’t live in someone’s head.

Motion If you use any kind of motion in your design, there’s a huge potential to create something that looks inconsistent. Getting a single element to behave consistently across a product shouldn’t be a stretch, but getting all elements to feel like part of an ecosystem can be tricky. For example, notifications don’t need to move with the same timing or orientation as the opening and closing of a menu. But they should have the same branded kinetic identity. What do I mean by CI? Each product should move in a manner that’s indicative of their brand. Sites like animate.css and easings.net can help with this.

↳ Now that we know what goes into the library, we need a way to render designs

Standardize your toolsets. If you’re managing the library, provide assets in 1-2 file formats.

I’m not going to tell you which one to pick because I’ll say it depends. Recently though…going with Adobe so that we can play in a few environments, prototype, animate, etc.

↳ Now that I’ve discussed what to format and how to do it, I want to share something that shouldn’t be in a pattern library.

If we’re doing this kind of work, it’s because there’s a gap between designers and developers. This is happening because the intentions of designers aren’t being communicated well. It points to a gap between design and development, and pattern libraries can help bridge that gap by giving these groups a common reference point.`

And by the way, when using a pattern library, this kind of specification only needs to happen when patterns are initially built. Never again should anyone be subjected to this kind of work again.

↳ And this brings us to collaboration

we have problems working with other people, right? I can’t be the only one.
and I want to address some issues that pattern libraries can help with.
Last time I gave this talk somebody made the comment that designing patterns shouldn’t be this hard. and it’s not. but working with other people is. In most jobs, the hardest part is negotiating and playing well with others. I really don’t think there’s anything harder. Design looks easy compared to issues I’ve seen come between people.

↳ But when you mix design and people together, it can be especially challenging. I saw a quote a few months ago that really struck me and I’d like to share it with you.

It’s something that Kim Goodwin tweeted, and it’s attributed to Abi Jones, who’s a designer at Google.
She says, “One of the cruelest things you can do is introduce a team to a new design language”
She’s right; it’s a bad thing to do. This suggests that there was a select group that went to a secret location, worked in a black box, and out popped a design. This isn’t Apple and you’re not making the next groundbreaking secret project. Don’t “introduce” your team to a design language. Instead of telling them that ’s coming…you’ll get to see it in a few weeks, make them a part of the process. Nobody should be surprised and there should be no big reveal.

If you’ve ever had this happen to you, you know that it can be a big change. But even the little things matter. They matter to us because the ones building the products. I want to tell you a story about a change in Bootstrap that happened a little over a year ago.

↳ This is a story about making changes, pissing people off and maybe a little lack of collaboration. Bootstrap is of course the front end framework that…

Daily updates to Bootstrap. There’s a lot changing all the time
Sometimes there simply tweaks to the code and other times it affects the UI.
Well, this time Mark Otto removed a 1px vertical line from Bootstrap. he pissed off a few people
54 comments
imagine what happens when you modify an element with even more utility? what’s the lesson here?
Lesson is understand what you’re breaking when you make a change
talk to the people consuming the patterns you’re designing and developing

↳ This is an example of developers who are unable to get on the same page. But there’s another classic pair that I’d like to bring together, and that’s the designer and developer.

this is kinda what I want the team to look like. Simpatico. don’t want to perpetuate the notion of being at odds—it’s a trap
also want to acknowledge that it’s an issue that sometimes exists

You’ve probably seen this before. Designer tosses wall, doesn’t talk to developer, and doesn’t consider constraints of solution. Developer builds solution to address constraints. Maybe won’t notice the details of the visual and interaction design. Might use a plugin to make work faster that doesn’t exactly align with the design. Then it’s time for the release to go live. First thing to do is for designers and dev to co-design. work through the process together.

So pattern libraries can help bridge the gap between the design and development.
It gives them a shared understanding of what’s an acceptable experience.
It’s not going to be a panacea, but it gets the two on the same playing field.

I’ve seen this work really well. No longer need high-fidelity design
↳ So that covers designer and developer interaction. But there’s another relationship that doesn’t get enough attention is designer-designer interaction.

Based on my experience, this is an even bigger problem.
30 designers, each responsible for a product or part of a product. And what they were designing was a suite of enterprise products that looked and worked very differently from one another. How did we get there?

It usually happens when a new product is spun up and someone says, “we’re not going to follow what was done because there’s now a better way to do it”. …And a baseline is never set.

Another cause for this fractured experience is because designers adopt a very myopic view.
they’re incentivized to improve only their piece of the puzzle. Their piece is only one phase of the user journey, and they’re not looking outward at full user journey that feels inconsistent and broken. Designers are on the front lines to help fix this, but they must get on the same page.

↳I’ll talk about how to get on the same page in a minute, but first I want to look at a few other players in the mix that can benefit from a pattern library.

Pattern libraries aren’t just for designers and developers. They’re for your product team and others in the organization. They may not reference it often. And by the way, don’t put this on some obscure dev server with an some garbled URL. Don’t require passwords. Brand it. Give it a memorable subdomain on your company server like blueivy.companyname.com.

QA - need to validate the design
Technical Writer - could be someone writing microcopy for the UI or help documentation for users
And then there are others. This is a lot of people. What’s interesting about them is that they represent virtually every phase of a typical user journey. So they’re going to have opinions about how a product’s design serves its users.

↳ We know that it’s hard to get everyone on the same page. If it was easy we wouldn’t need this kind of documentation. So how do we create a singular vision when we can’t agree on a design approach? We collaborate! We set up workshops and deal with our issues.

Not everyone needs to be involved in these activities. I’m not talking about trust falls or spaghetti towers or whatever it is you do with marshmallows. This is something more productive.

To get started, identify a facilitator. Usually your design lead or another sponsor of the pattern library project

↳ The first exercise is a warm-up and helps teams identify what direction to take their design.

Good activity for anyone who interacts with users,
Using product reaction cards helps teams figure out how to present the user experience. When I say UX, i’m not just talking about the UI, but the full UX from the website or a product to call centers and marketing collateral.

In this activity, participants are given a deck of cards with descriptive words on them. Don’t need to come up with your own words

Originally developed by Microsoft to test desirability of a product, there’s a set of 118 words that you can use. For purposes of this exercise, I recommend weeding out the negative words.

↳ Pick 5 out of the 100 or so.

They help us define how we want users perceive—and interact with—a product. They also tell us how to design our product.

Going down the list we see things like Trustworthy and Empathetic. Accommodating and Forgiving. What does that mean? Example is deleting…

↳ Defining product attributes also helps inform the principles for your design

You might scoff at something like this and think that they’re too broad and not relevant

We need design principles because they convey the fundamental and unwavering ideas about a product its design. It will feel weird and out of place to put this in a pattern library, but do it. The principles are for you, but they’re also for the VP of sales who pushes features and cares less about the experience.

So these are a few examples of product attributes and design principles. Check out IBM and Google’s Material for great examples of design principles

↳ The last part of the workshop is to identify all of the elements and templates used in your products

Process
Identify: all existing patterns. Although he didn’t mention is, Brad also has a great post on doing an interface inventory for your products. Google Interface inventory Brad Frost and you’ll find it.
Group: like patterns. Serves two purposes:
identifies redundancy and it also establishes IA for the library,

That’s it. There’s the foundation for the library. But since there’s likely redundancy, we need to pick the best one. We can do that by looking at product attributes and design philosophy, but there’s another too that can help us

↳…because evaluating visual and interaction design can be a subjective practice. Using a formal design critique can make the decisions a lot more objective.

I have a developer friend who says it’s not hard to design, but design is hard to argue about. I agree. We debate about design it because we don’t always know how to talk about it.

Critiques aren’t about criticism. It’s about creating a framework to talk about design constructively. Also prevents discussions from devolving into subjective preferences.

This is how it works:
gather design team
a designer presents their work. designer describes how they arrived at their solution by answering a series of targeted questions.

This is not design by committee. It’s purely constructive feedback

hold design up to these standards. if they fail, start over/iterate

↳ I’ve talked about who the players are and how a few activities can smooth their relationships. Let’s talk about how the library evolves over time. And it starts with process.

for most teams the process should involve a designer who acts as a curator of the pattern library. And they shouldn’t do this alone, this process works best when they’re paired with a developer as well

curating library not a full time job, but requires someone to lead a team toward a shared vision
everyone else - all designers/devs given authority to propose and submit patterns

↳ On to the process itself. I advocate something that’s lightweight.

Most governance models look like this. I think it can be easier and based on simple logic

When designers start work on a new task, they should ask themselves does a design exist to solve my problem?
If answer is yes, then they can move along happily.
If answer is no, then there should be a discussion about whether or not it’s needed by others and should be a pattern. Sometimes it shouldn’t be a pattern and can be a one-off customization
Other times, it’s a completely new pattern. in that case, the designer creating the pattern should draft the documentation and submit it to the library
There’s another scenario, and this is one that I see pretty often, and it’s full of issues. It’s occurs when a pattern exists, but the designer needs it to do something slightly different. Most of the time it’s cheaper in the short term to build it from scratch. And this is where some serious behavior change is involved. Instead of building from scratch, we want the existing pattern to be extended. to build the b/c designer/dev would usually say, we’re just going to build it our own way. (Usually the answer is yes, 90% of it does, but i need this other 10% for something…)
In this situation, a pattern can be used to solve most of a designer’s problem, but they’re breaking the pattern with some tweaks.
But these aren’t breaks, they’re enhancements. They’re making the pattern more modular.

↳ Go back to example of a select list.

In the scenario that I just mentioned, there’s an existing pattern like this select list.

Others may say, “I like it, but I’m building one with a filter. Or a checkbox multi-select.

These are not separate patterns. These are represent modular variations to a single pattern.
Look at something like a select list. It’s something that could be merged with a filter or an enhanced multi select. Or it could combine both.

↳ The lesson here is to accept variations.

Google’s Material has three variations for buttons. They could have easily said, “we have one style, and it’s a rectangle with text inside”. But instead, they recognized that design has context and that one solution doesn’t meet all needs.

So that’s the process in a nutshell:
Crowdsource the production of the pattern library
Identify a curator to help manage it.
And accept variations.

↳ Now that we’re near the end, let’s talk about the beginning.

By the time you think about documenting patterns, it’s usually too late and inconsistency has crept into a product.

So start at the beginning of a project, but I don’t think that you always need a pattern library right away.

But design by using symbols and in Sketch, Photoshop, Illustrator, or whatever tool you use. Share symbols in libraries with Creative Cloud. If you’re not using CC, use Dropbox or a folder on the company network to sync the files.
And work with your front-end developers to create a centralized web style guide.
Generally speaking, when a team grows beyond a few people, it’s a good idea to begin documenting patterns and providing rationale

As the pattern library is developed, don’t worry too much about the information architecture. As the library expands, begin to add more structure.

↳ Before I end this talk, I have a few more thoughts to share.

Agency: talked a lot about pattern libraries from perspective of a product team, but that may not work for everyone
A year and a half ago I transitioned away from in-house design and joined a design agency. Suddenly, I was in a place that designed and developed really customized experiences for every project. That seems nuts, right?

I can’t say that there’s really a place for pattern libraries at an agency. But there can be baseline assets that can be reused.

↳ I also want to briefly share with you some design systems that I think work pretty well

Yahoo Design Pattern Library

Was a point of inspiration for me going back almost 10 years
Good, concise documentation with a solid organization

Material’s documentation is pretty good with describing design details. But it gets a knock against it for not being very interactive—it has videos and static images.

MailChimp gets pretty close to a sweet spot for lightweight documentation. They provide HTML-based examples, code to render the element, and a few thoughts on how the pattern is generally used.

Salesforce is an interesting one because it doesn’t actually provide any rationale, but they build about a dozen reference pages to show how patterns can be grouped together. Really nice

↳Now we have a reference point for pattern libraries. How do we build them?

↳ Alright. Let’s wrap this up.

OK. Today I’ve shown you what goes into a pattern library and how the patterns can be formatted. I’ve discussed the process of creating and evolving patterns. And you saw some examples of patterns and pattern libraries. Before I go, I want to recap a few main points:
The first one is simple…

Use pattern libraries to provide design rationale, increase productivity, communication, and users’ experiences.
Use minimal documentation: create just enough to communicate a full understanding of a pattern
Establish a lightweight process: Create a model that works for you and encourages iteration from others. be nimble and allow for evolution through variations

These last two go hand in hand

When building a pattern library, consider the context. Sometimes it’s more important than consistency, so be accepting of variations. And finally…

Accept inconsistency: nothing is ever done when you’re working in digital, so unless inconsistency is breaking the usability of the product, don’t worry about it. But keep fighting the good fight.

These slides will be on Slideshare later today along with a full list of the resources that I mentioned in this presentation. I’m happy to take questions now and you can always find me in the hallways or tweet at me.

Are there any questions?

Design Pattern Libraries

Brian Peppler

Design Pattern Libraries