Take a look inside the design system
Has your content anything to do with your design system? I think it does. Content is a crucial part of the user experience (UX) and does its job in components, dialogues and patterns. Exactly: in the components of a design system. Over the past years, design systems have become the ‘single source of truth’ for design and development, based on standards, for a consistent UX.
Strangely enough the term ‘design system’ does not always provoke enthusiasm, outside of the field of front-end-development. Lots of content specialists do not jump for joy when they spot a design system in the wild. While researching for my whitepaper on ‘content and design systems’, I overheard some colleagues saying “It’s some kind of toy box for developers, isn’t it?” or “So you can reuse the date picker or button. Cool.”
I’m a bit surprised by this lack of enthusiasm and would expect more content specialists to warm up to the idea of a design system. If only because the date picker, and the button … contain content. And because you do not want to get stressed up when someone wrote ‘Next’ as a button label, while ‘Continue’ is the preferred term in your organization.
Design system: building blocks and guidelines
What is a design system? It’s the mature form of what we used to call a ‘component library’. A design system is a set of basic principles, processes, patterns and components, for designing and building the user interface of a tool, app or website, with a consistent user experience.
Relation with content
So what to do, as a content specialist, when the term ‘design system’ starts to buzz in your organization? How does your work fit in? Of course that’s dependent of the situation. The relationship of your content and the design system can be implemented in different ways.
A starting point could be found in structuring and writing user-friendly descriptions – a template for comprehensive documentation of all the parts of the design system. The benefits of this content work is readily clear to everyone involved. And it is a clue for further content involvement.
In an early maturity phase of design systems, all kind of guidelines (like style guides, editorial and tone-of-voice guidelines) are added as separate document, for instance in PDF-format. In itself it’s positive if you can find guidelines located somewhere near the components. But how many design system users, in need of the preferred term for a button label, will make the effort of downloading a PDF document and searching through it? While you can always use Slack, Teams, email or WhatsApp to ask the content specialist whether ‘Next’ is the correct term?
Guidelines near at hand
In more mature design systems, the designer or developer doesn’t have to search for the relevant guideline. Every design system part is described in a consistent template (for instance ‘what is it – when to use – parts – particulars – examples’). Just give content considerations a fixed place in the description, to save every user time spent on searching. Give the user the right info on the right time and place – sound familiar?
Even if there is a lot of variation in the texts that will ultimately appear in a component, content considerations can be relevant. Accompany a radio button component with a guideline like ‘Every label text starts with a capital’ of ‘Use a full stop only when the label is a sentence’. In each component that accommodates a time or an amount, you can refer to the relevant notation guidelines (for instance the ISO standards).
Does the system contain components with a fixed, obligatory term? Think of the ‘Next’ and ‘Back’ buttons, or the ‘Login / Register’ dialogue. Forms contain lots of labels and validation texts with a fixed terminology. Wouldn’t it be a real treat when these texts form an integral part of the (downloadable Sketch-) files that designers use to make wireframes or prototypes?
Look for shared interests
That’s why I’d like to nudge content specialists to take some interest in the integration of content and design systems in their organization. Just walk into the room where the front-end developers are performing their sprints. Look for shared interests on both sides.
Where is the gain for you, as a content specialist? For starters you will not have to tell someone for the ‘nth’ time that it should be ‘Continue’ instead of ‘Next’. Moreover, you’ll get the warm feeling that your dear content guidelines will really be utilized. You’ll secure a consistent use of language, terminology and tone-of-voice.
And you won’t have to act as ‘content escort’ all the time during development sprints. Your content work will be more aligned with that of designers and developers. With the obvious, ultimate goal of delivering a better experience for the users of your product or service.
Download my whitepaper on our site.
About the author
Mark Westbeek (@markwestbeek) is a content designer with extensive experience in the design, creation and management of content with which users achieve their goals sooner. Mark also coaches and teaches customers to create this type of content themselves. He prefers to work in Agile contexts and likes to use tools such as customer journeys or user interviews and to identify content challenges early on and to solve them.
Content strategy (19), Design systems (3)