Pattern thinking

Many organisations are turning to pattern libraries to solve the problems faced with developing and maintaining large websites. I love collaborating with clients and teams to help build their first pattern libraries. It's great to see clients so excited by them, but it's only half way towards solving the problem.

Even when the final deliverable is a pattern library, teams often still want to deliver page designs. Sometimes stakeholders find it easier to visualise pages over patterns. It's how most of us are used to working. Yet, as pages make their way to different teams for sign off, people talk about tweaking the home page or the product page and before you know it, everyone is thinking in pages. Working with page and component designs simultaneously brings its own set of challenges.

These challenges have become particularly evident in some of our recent projects at Clearleft. Instead of delivering completed pattern libraries, we have collaborated with teams to help them build 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.

A component with the name "Product card" can only be used in a product-related context. But, what if the component moves to another page or gets populated with different content? It could be reused for a range of different purposes. The name "card" would be simpler and far more versatile. A component's name defines its life: it's reusability and whether it can withstand changes to its appearance, so it's important to get it right. One of our biggest challenges is naming things.

The way I see it, the challenge isn't getting buy-in from clients; it's helping them adjust how they think about their websites. It's helping them remove page and content associations from individual components of their website, and build a shared vocabulary. I'm not just talking about designers and developers; the whole team needs to share the same language.

Change isn't always easy. Once upon a time, websites were built in tables, then they moved onto CSS. Websites used to be fixed-width, now they are responsive. A mobile-first approach is different to a desktop-first approach. As our ways of working change, we find different techniques and tools to help us. To change a way of working, we need to change the way we think about it.

I recently wrote about an exercise which helped the teams I worked with adopt pattern thinking. I'd like to hear about other ways to achieve this too.