Content design patterns — revisited
Earlier this week I revisited an old post of mine (from Jan 2016!) about content design patterns. By ‘content design patterns’, I mean words, phrases, sentences or sentence structures that get reused across multiple use cases, likely by multiple teams.
I noted in that original post that not many people were talking about this concept back then, and I’m so thrilled to see that “content patterns” are now a hot topic.
Just to quickly root us, here are some examples of content patterns:
- Sentence structure and specificity of error messages: “You must enter a <field name>”
- “Sorry we got this wrong” (this one needs very clear and practical usage notes!)
Framing
My framing from 2016 still resonates. The idea behind content patterns — especially when working in large, distributed teams — is that common user needs or components require consistent content solutions as much as common components. And content design work ought to be as reusable and scaleable as code, because consistency is a win-win for users as much as companies and efficiency.
What I’ve learned
With a few more years of experience under my belt on this topic, I’d add a few new things for anyone building out content patterns:
- Get clear on decision making. Designing patterns by consensus needn’t be a default. Designing based on evidence — with teams disagreeing and committing — makes for the better solution. While you may want to install some kind of process, be wary of anything that adds too much operational overhead and makes this kind of work off-putting.
- Use this work as a catalyst for breaking down organisational silos. This work is very powerful in breaking organisations out of their silos. Patterns often scale teams, and can help introduce people to coworkers they don’t know. They help create cultures of sharing, and build operational efficiency.
- Be clear that these patterns aren’t fixed. They ought to be framed as flexible. The flexibility patterns afford is that they’re not designed to be lifted as-is — instead, they’re best read as a starting point. This is a point that can’t be laboured enough. It’s unlikely that whoever first documented a pattern would anticipate all future use cases either.
- Good governance is a must. It’s very important to have people signed up to keep sections up to date, and have this be recognised as part of someone’s job. Otherwise they won’t get updated in line with relevant research.
- Working in the open brings huge rewards. It’s important to talk about this work with all members of multi-disciplinary teams, not only for visibility but also for reasons of accountability. Visibility levels up conversations—it can help content designers identify gaps, ambiguities and all around make things better.
- Bake into existing workflows, otherwise patterns will be easy to ignore. It’s all very well having a library or repository, but unless it’s embedded across people’s existing workflows I’ve found it’s unlikely to take off. At best, this can trigger to a beautiful collaboration with engineers (to bake patterns into code), product designers (handing off from design systems where relevant) and UX researchers (to see if patterns are fit for purpose).
Further reading
I’ve been keeping track on this topic as it’s close to my heart. Here are some good reads:
- GOV.UK on service patterns (very much related)
- Content in design systems talk (DSCC Toronto)
- Shopify examples
- Clearleft
- Healthcare.gov
