On pattern portfolios
Arguably the key deliverable we hand over to our clients is our pattern portfolio, comprised of two main components:
The component library is a collection of all the front-end patterns or snippets we’ve extracted from our designs during the design and build phase. These patterns become the building blocks of the site we’re working on, and typically include common CSS & HTML code blocks like headers, footers, form elements and lists, as well as advanced patterns like faceted search and responsive galleries and more.
Once collated, those patterns are then combined into a number of unifying HTML/CSS/JS page examples. These representative pages help illustrate to both our clients and their technical partners exactly how the newly-created patterns will combine as pages on the new site.
When describing our pattern portfolio to new clients, I tend to use a cooking analogy:
Where our component library represents the ingredients for a dish, the page examples and visual designs represent the recipe. Our pattern portfolio allows any back-end agency to quickly and easily implement our fully-tested, responsive front-end code by taking the ingredients, following the recipe, and baking the new pages into their CMS or platform of choice.
Why do we use pattern portfolios?
Traditionally, agencies deliver every single newly-designed page as a flat HTML/CSS/JS file, handing them over to the technical agency for backend implementation. Each of those HTML pages would then get picked apart, reverse-engineered, and re-baked into the selected CMS or ecommerce platform.
With this approach, not only is there duplication of work, but the client often ends up fronting the bill. It’s death by a thousand cuts, having to track changes across large sites at a per-page level.
Instead, by adopting a modular, pattern-based approach we can focus on the larger design vocabulary of the site, which ensures we deliver more consistent and scalable design. It also helps us avoid getting bogged down with the incrementalism inherent with the traditional route.
What’s more, our clients gain autonomy and freedom by gaining ownership of the patterns and page examples we deliver. They’re given the means to build new pages or services as needed—without having to rely on us or another agency to create or recreate flat HTML pages all over again.
Ultimately, our approach saves time, money and headaches for both the client, and—perhaps crucially—the technical agency doing the implementation. This is something our friends at Digerati (who we worked with on the Wellcome Library redesign) wholeheartedly agreed with:
I like the Pattern Portfolio so much that I’d want to insist that anyone delivering front-end assets to me does so with this or something very similar.
—Tom Crane, Digirati
We don’t do back-end implementation, but we understand the need, importance and potential cost savings in making the handover to a technical agency as easy as possible. If you’re a client who hasn’t yet selected a backend/technical agency for your next project, try to procure one who has a good appreciation of design systems and modular, pattern-based workflows. Avoid the need for reverse-engineering and work duplication, and you’ll save time, budget and sanity!