Designing a pattern library that’s flexible enough to grow without needing a bazillion tweaks along the way
Y’know those sites, where the content is man-handled into an inflexible template, so it resembles the kind of suitcase that’s packed when you wake up still drunk and your flight leaves in an hour? Like there’s no contextual help element so there’s a fricking 6000 word manual inserted after every input field, yeah those. Don’t make more of those please.
Every user interface must be designed around user needs and be able to meet business goals. (Otherwise, as my mum would say: all you’re making is a mess!)
There are four stages of the design process: Discover, Design, Develop and Deliver. They don’t happen in silos and discovery needs to stay constant throughout — keep validating and testing your assumptions!
When creating a pattern library content-driven architecture is a bullet proof method to construct elements that can be combined into components to create pattern libraries that are scalable and flexible enough to accommodate content needs in future.
The design should fit the content like a glove. Diving straight into design without taking this approach puts a lot of pressure on designers to anticipate the diverse content requirements — which of course, is impossible for them to do without being privy to the prior user research and content mapping. Designing in this way can then restrict the way design is used in future — this leads to content being squashed inappropriately in elements not designed to fit them.
Working example: form design — if the requirement is to design form elements, with a visual-design first approach, it’s easy to miss things like the legend, that users might need guidance on what format to enter the input, that for a password field, there are many ways to indicate to the user how to meet the security requirements, which ones are most easily understood by users? we can’t know this without some experience research and testing first.
To design a UI pattern library of groups of elements (components) and templates — we first need to know what the component and templates are for.
You can’t design a machine part– if you don’t know what it’s going to be used for, now and in future.
Find your focus
Take a component that you know you’ll likely need, e.g. form elements or, take a chunk of content and extrapolate the content type to as high a level as possible.
Example 1: A knowledge base article > User contributed articles in knowledge base
Example 2: Alerts, error messages > Messaging framework
Dismantle and analyse it
Take your samples — extract wide and varied samples of the existing content. If you have no existing content — try to source similar content to what you’re trying to achieve.
Hold to these fundamental principles:
1. All content answers a need, otherwise it shouldn’t exist — and be ruthless about this.
2. Do not assume that any current solution is the right one.
It may be a business need or a user need that you’re designing for but it must still be a need that is met by content.
Break it down into what those needs are
I find the best way to do this is with user stories — this forces you, as a designer, to keep laser focus on the user need.
The format of a user story is: As a … I want to … so that I can …
As a …
(end user, business, client etc.)
I want/need to …
(what’s their immediate task)
so that I can …
(what’s their end goal).
Example 1: As a business I need to record time entry of employees so that I can complete resource and spend reporting.
Example 2: As a user I want to send a personal message to the person I’m recognising so that they know what they did to deserve the recognition.
File the existing UI to the circular filing cabinet
Now that you have the user stories, put the existing solution away and don’t look at it again — unless you want to come out of the design process with a copy what you already have.
The existing UI solutions are now just toxic waste to your design process. You don’t want the old design thinking contaminating your thinking about the user needs. If you come to the same conclusion about what the solution should be and look like, then fine — but at the least, you’ve challenged assisting assumptions and now you can be sure that what you come up with is the right solution, not just a copy of what you had before.
Organise your analysis so it can form the basis of the solution
Map the user stories against the user journey / journeys
Organise your user needs along a rough user journey.
I like to start with something high level and generic like this:
- first point of contact with the interface
- during usage
- end of usage
- after usage.
If you want to keep it simple it could just be beginning, middle, and end.
Once you’ve started this exercise, it will quickly become apparent where you need more stages in the journey.
Example: You might see that at the before starting a journey, a user needs to see if anything is required that they might not have to hand e.g. their mobile for 2-factor authentication. They might want to know how long it’ll take before they commit to starting it. They might want to see if they can save their progress and continue at another time. Or it might encourage them to start if they can see that it is only a very quick task.
Sometimes it can help to tag the stories into themes so you can see what themes you need to bake into the design
Example: if a lot of user needs are concerned with understanding that their information is secure — then you know you need to focus on communicating that it is.
These user journeys with the user stories against them, work like your design requirements with the user firmly at the centre of your design process.
Now you can start designing the atomised elements e.g. links or titles in a way that fits with the different scenarios with a consistent pattern designed e.g. a link that works in a paragraph of text, a heading that is also a link, a link that downloads a PDF, a link that takes the user to an external site, in-page navigation links …
And work these up to larger components like cards, forms, articles etc.
As the larger experiences are constructed, it’s likely that the atomised elements will need to be revisited as new scenarios emerge e.g. a link that opens a modal.
When a scenario arises where the element does not quite work in a specific use case — that element needs to be revisited with attention to how it can be adapted but without creating unnecessary design debt.
Here’s an example with the link element — a fundamental element that needs to be flexible enough to work across many experiences.
That’s all, thanks for reading.
I’d love to hear your thoughts, feedback, questions or comments