What makes a good UX pattern library and why I don’t currently have one
Lately I find that I spent alot of time extolling the virtues of a pattern library. It’s so obvious to me why you’d need one, but I feel the need to list the actual arguments for why you’d be crazy not to invest in one. A primary reason to work with a pattern library is to prioritize time for strategic design – time that could be spent interviewing customers, doing research or evaluating architecture instead of pushing pixels.
Possible reasons for why our current pattern library is not doing its job
Some reasons for why our current pattern library is not doing its job could include pilot error i.e. people are simply not using it. Or it could be that the underlying framework doesn’t lend itself to be easily used. Regardless, I think it’s safe to say that because we currently don’t have a team in place to care for one, there’s no momentum or accountability for keeping our pattern library healthy, robust and social.
If it does boil down to a people problem and not a technology problem here are a few things to consider:
advocacy is missing: the library requires advocates who challenge people if they are deviating away from the library’s governance and are choosing to rebuild things
hygiene issue: people choose to get something done quickly instead of complying with the pattern library
there’s nothing to belong to: you can’t follow something that’s not acknowledged as real. Incentives might need to be put into place for a guild of sorts where people are required to participate as members – where they are trained and rewarded for learning the design language and taking responsibility for how we do things
If the pattern library is failing because of how it’s been built, then another answer could be that developers have no other option but to rebuild components in each area of their code.
Terms and definitions
There are several terms that are bantered around like UI toolkit, UX pattern library or design language system (DLS). Are these terms interchangeable? Or is each on a spectrum starting with the lightest, a toolkit, and progressing to a full blown DLS?
Thanks to my colleague, Scott Bresson, for the following definitions:
UI tool kit: UI elements for designers. Editable source file – in say, Sketch or PS – that designers can pull from and keep up-to-date.
UX pattern library: a functional, coded version of UI elements that designers can reference and coders can use in an app or website.
DLS: an holistic strategic approach to design. Easily consumable, often consumed internally (the company) and externally (public). DLS is the most comprehensive and it most likely includes or informs the creation of the library or toolkit.
What a successful pattern library or DLS does
Between Paul Boag and Clark Wimberly, reasons for implementing a pattern library are:
Consistency: the pattern library governs consistency to avoid a fragmented user experience
Speed due to reuse-ability: a central library developed with all stakeholders collaboratively means you can reuse things and avoid having people recreate things from scratch each time
Maintainability: everyone who participates in the library gains a shared knowledge of how things work, it’s much easier to pick things up and work on someone else’s design or code
Rapid prototyping: with the right team in place you can readily put together coded prototypes for user feedback
Boag also recommends that the library live in a single repository.
There should be a single repository for code that is always kept up to date and that this repository should be in source control – Paul Boag
Further considerations for building a pattern library
component taxonomy such as Brad Frost’s Atomic Design
a responsive grid
color
icons
typography
navigation
motion
components
tone of voice
accessibility
javascript plugins
Next steps
We should determine an aspirational pattern library or DLS for that matter and how you would describe the gap to getting there. Some links to explore next: