From Pages to Patterns: An Exercise for Everyone

Language defines the life of components. A “blue button” will work until the button is no longer blue—and then the name won’t make sense anymore. The pattern will have no reason to exist if blue buttons have fallen out of use. A component with the name “button,” however, will live a longer and more fruitful life, even if its properties change. Why? Because its name describes its function, not how it looks.

As many of us know only too well, naming is difficult—but it’s the key to building a robust system. And it involves leaving some entrenched ways of thinking behind.

Thinking in pages (still)#section2

Even when the final deliverable is a pattern library, clients often still expect to sign off on page designs. As pages make their way through various teams and managers for approval, they are, of course, discussed; before you know it, they turn into Home page, Listing page, Product page, and so on. Everyone is thinking in terms of pages, so it can seem natural for component design and page design to occur in tandem. But building components from page designs is like starting from the outside and working in—and that can get complicated.

At Clearleft, the challenge of simultaneously developing pages and components became particularly evident in some of our recent projects, where instead of delivering completed pattern libraries to our clients, we were asked to collaborate with in-house teams of designers and developers to help them build and maintain their own. In one instance, as an exercise, we spent a few weeks focusing on UX and UI with a team before we asked them to name and code components from the designs. We were working from a product page design with product-related content in each component. The first component we built looked like a card, so everyone called it “product card.” We continued the exercise for different components, with similar results.

Now, it’s great that people came up with unanimous suggestions—but do you see a problem with this naming structure? What if the component moves to another page or gets populated with different content? You could also think of the product card as a “profile card” or a “location card.” It might be reused for a range of different purposes. The name “card” would be simpler and far more versatile.

From pages to patterns#section3

To help others adopt pattern thinking, we came up with an exercise for everyone involved in the pattern library. This isn’t just for developers and designers—anybody who has a decision to make in the creation of the pattern library should join in. The goal is to get everyone thinking about patterns at a granular level, removing any context around each component. It also encourages a shared vocabulary.

All you need are some visual designs of pages or components (these can be anything from a first draft to final designs) and the following:

• a printer
• paper
• scissors
• Post-it notes

Here’s how you do it:

Part one: paper and scissors#section4

• Print the page designs and share them among the team so that everyone has components to cut up.
• In a group or individually, cut up each page into its smallest elements and mix them up so you don’t know which page they came from.
• Group similar elements like buttons, icons, form fields, etc. and remove any duplicates.

Duplicates are multiple instances of the exact same element with the exact same design. You can safely remove them; you only need to note one instance of each element. However, if you end up with several instances that have slight variations among them, you might want to review your designs and streamline them to ensure that you create a consistent and cohesive experience.

Brad Frost uses a technique called an interface inventory to analyze the interface components of a website. Instead of cutting up paper, he uses screenshots and gathers them in a spreadsheet. When he did an inventory of his bank’s website, he found that the button designs were quite inconsistent. Using his technique helped uncover the need for a design review.

Part two: naming components#section5

Generating ideas for component names as a team is a fantastic way to start developing a shared vocabulary.

• Pick a component.
• Everyone take a Post-it note and write down a name for that component.
• Keep the names a secret until everyone has finished. Think about the function the component will carry out and avoid any references to its appearance. Asking why a designer made something look the way it does can help identify its function or purpose. Does the name still make sense if the component is moved to a completely different place from where you might be imagining it?
• Once everyone has thought of a name, reveal each Post-it note. Compare and discuss. Names that appear multiple times are good candidates because they indicate a shared vocabulary forming.
• Repeat this with each component.

In my experience, this part of the exercise has sparked some productive discussions around naming, surfacing class names that bear some relevance for the company and for naming methodologies in CSS. Naming things shouldn’t just be left to developers. Getting everybody involved makes the challenging tasks of naming things a little easier and encourages the team to continue using the same terminology after the exercise is done.

If the project is in its early stages and the designs are likely to change significantly, it may not be necessary to do this part of the exercise. On the other hand, there is a lot of value in getting used to naming components and starting to form a shared vocabulary early—even if that vocabulary evolves throughout the project.

Part 3: code#section6

There’s a final step to this exercise for those who feel comfortable with coding. If you’ve started discussing CSS methodologies, this is a great time to try them out. At this point, you can play with as many variations as you like; if you decide that a particular methodology or term doesn’t work for you, you can drop it without investing any code in the actual pattern library.

• Everyone grab a component.
• Code it up in HTML and CSS. Set a time limit and resist the temptation to perfect things. It’s fine to throw away the code if the designs change.
• Compare and discuss your code.
• Repeat.

Repeat, repeat, repeat#section7

This whole exercise can be repeated again to identify larger components. Some of these will contain elements identified in the first round of the exercise. You can check that they make sense and can stand alone within their new context.

One of the great things about this exercise is that it can be valuable at different stages of a project. Perhaps groups with differing skill sets, including people who aren’t developers or designers, want to start thinking in patterns. If that’s the case, just use initial drafts or whatever version you happen to be on. It doesn’t matter if the designs change, because the focus is on a new way of thinking—not on how the patterns look. At this stage, the names chosen in the second part of the exercise are apt to be temporary—but since naming is invariably challenging anyway, why not use this mutability as an opportunity to start building the foundations of your shared vocabulary by trying out various names in the context of the project?

Or perhaps you’re further on in the project and the design is pretty solid, so you want to start grouping and naming patterns. Again, use the latest designs for the exercise. The beauty of paper prototyping is its low cost of change; you can throw it away and repeat it as many times as you like. Natalie Downe used to carry out a similar exercise when she worked at Clearleft. She used pens and paper to prototype components, demonstrating their functionality and size. This enabled her to see how they might work and fit together before investing any time in code.

What happens next?#section8

That’s down to you. It depends on what you hope to gain from the exercise. Personally, I find it useful to put the components and their names onto a large piece of paper and then stick it up on a wall for everyone to see. As designs change, the components can be reprinted, discussed, and replaced. Keeping things visible serves as a reminder of the components, and will provoke discussions as the project progresses. Or if the team can’t work in the same building, you can keep a record online. Dan Mall has talked about using a Google Sheet as a central repository of components so that everyone in the team can access and discuss them asynchronously.

The aim of the exercise I’ve described here is to involve everybody in the pattern library creation team. Alla Kholmatova takes it even further and involves users of the website. She tests paper components with them to get their feedback as early in the process as possible.

Similarly, Heydon Pickering uses paper, pens, Blu-Tack, scissors, and tape to prototype interfaces for users to play around with at Neontribe. This way, he can quickly validate ideas with users without spending time on the fidelity of prototypes. Sometimes he tears up the prototypes and leaves with little more than he started with, but at least he can quickly move on to new ideas.

Developing components#section9

The card example illustrates a common component and it highlights the need for a naming scheme. In this case, the class .card acts as a blueprint of styles for each card component, where variations can be created. This is how the markup for a whole card component might look using BEM syntax:

<div class="card">
    <a class="card__link" href="">
        <h3 class="card__title">Hello</h3>
        <img class="card__hero" src="images/image.png" alt="Card image">
        <p class="card__description">Some text content</p>
    </a>
</div>

A variation—a product, say—can be created by modifying the card component like so:

<div class="card card--product">
    <a class="card__link" href="">
        <h3 class="card__title">Hello</h3>
        <img class="card__hero" src="images/image.png" alt="Card image">
        <p class="card__description">Some text content</p>
    </a>
</div>

Some significant changes in web development, notably modular approaches to CSS and naming conventions, have occurred in recent years. Naming conventions are a major part of what methodologies like SMACSS, BEM, and OOCSS provide. All of these help address the same challenge: naming things clearly and consistently.

Resist the temptation to dive straight into code. There’s a lot to be gained from getting away from our screens and focusing first on thinking, language, and approach. It might seem like a lot of trouble and time, but it can reduce the chances of discovering that you need to course-correct later on.

The key benefits of this exercise are that it creates the same starting point for everyone, and encourages a shared language and pattern thinking across the team—all of which help lay the foundations of an effective pattern library. I’ve started using this exercise to kick off every pattern library project I work on; I only wish I had discovered it sooner. After all, who doesn’t love messing around with paper and scissors?