Content, design systems need you!
Design systems are the talk of the town and there’s a good reason for that. They keep products consistent, teams scalable and designers sane. This got a few of us thinking, “why the hell aren’t we doing this for content?”
Well it’s mainly down to the fact that life at Deliveroo is hectic. The Content design team is busy, spread thin across multiple projects each. But in the end that was our greatest motivation because design systems are a huge time saver for their users.
The thought of being able to focus on new problems rather than designing content one of us had already designed before was quite the incentive.
There was also blank page syndrome. It was daunting, especially with such little guidance out there on how to do it. But as soon as we started (I’ll go into more detail about this below) any nerves melted away. We set out from the beginning that this would be experimental and iterative.
What follows is a description of what we’ve done so far, what we’re trying to achieve and how we’re thinking about doing it. I haven’t been able to find out how other teams are doing this but maybe it’s in your backlog. If you have some ideas, drop us a comment or two — we’d love to hear about how you’re approaching it.
One quick caveat: we’ve gone down this road because we’re attempting to integrate content into an existing, extensive design system owned by our Design infra team. We’d approach this very differently if starting from scratch as part of one team.
First things first, what is a content design system (CDS)?
Actually, let’s start with what it isn’t.
We’re not talking style guides, vocabulary lists, tone of voice guidelines or any of the above tacked on to a design system.
When we say Content design system we mean a set of scenario-specific components, backed by research and agreed upon by the team, fully integrated into the design system our Product designers and Engineers use right now. Something that allows them to make solid content decisions without us.
Like I said above, we want a set of repeatable content patterns that keeps us consistent and allows us to direct more of our attention to new problems.
What about style guides?
Our style guide at Deliveroo helps us ensure consistency in things like date formats, tells new hires that we don’t use the oxford comma and importantly features any accessibility guidance we come across. (And more, the above was just a flavour)
Sticking to a style is important but it doesn’t speed up the design process, reduce workload or improve consistency of content patterns. The scenario-specific components we want to systemise wouldn’t work in the same format as our style guide Google site.
Plus, the further away from the work, the more unlikely you are to refer to it. The last thing you need is another open tab or, God forbid, a printed document.
We want to reduce the friction in making content decisions, especially for distributed or stretched teams. So we want to follow content design 101 — give your users the right info at the right time in the right place. That means full integration in the tools and software we and our other users (Product designers and Engineers) use: Figma and the component library.
How is a CDS different to a design system?
Whereas a regular design system might provide context like:
- Use this checkbox when you need a subtitle
- Use this checkbox when you need a link
- Use this file input if you can upload multiple files at once
Content needs more context, for example:
- Use this save modal when the user tries to leave an unfinished form
- Use this error message when an input is incomplete
But…
- Use this error message when the input is too long
It’s all about context
Choosing a component to build a page or flow means making a content decision for that page or flow.
When a component has context, you can make the right content decision by default.
As an example, our design system contains a page title component with an optional subtitle. That’s great because it’s flexible. But it doesn’t tell you when to make that content decision of including the subtitle or not. When you add the context and the content choice to the system, the user knows to choose the subtitle when the value of the page isn’t automatically clear to the user. But to not use it if your only goal is to orientate the user after they’ve made a selection from a navigation menu.
In that sense you’d probably stop thinking about these as Title/subtitle and Title/no subtitle and instead like Explanation title and Orientation title.
And that’s what we’re hoping to move towards.
An example from our CDS
To really help drive the point home, here’s an example of what we’re working on. This is quite a concise example as there are only a few contexts where we believe a toggle is the right option based on our agreed content pattern.
Example guidance for toggles: Toggles are only used for states, not choices. Think of them as a design proxy for an on/off switch. If the interaction is more of a choice, like yes or no, consider other UI. The label should be unambiguous and describe the thing you are turning off or on — they should never be action-based. The label copy shouldn’t change based on the state. The subcopy should explain the state that you’re in and what that means if necessary. Possible scenario: Customers want to turn a setting on or off.
✅ Usage and example
Toggle on
Label: [The thing] for example, Notifications
Subcopy: [The result of the on state] for example, You’ll get notifications
Toggle off
Label: [The thing] for example, Notifications
Subcopy: [The result of the off state] for example, No notifications for you
Why?
- The noun label is unambiguous and static to avoid confusion whether the thing is on vs moving the toggle to turn it on
- Describing the state helps the user understand what’s currently happening
❌ What not to do
Toggle on
Label: Allow notifications on
Subcopy: Keep up-to-date, turn on notifications
Toggle off
Label: Allow notifications off
Subcopy: Keep up-to-date, turn on notifications
And why is that bad?
- The verb-led label makes it difficult to understand what you’re turning on/off
- The subcopy tries to influence behaviour and doesn’t describe what’s happening
- The label changes based on state
So what’s the end goal?
I’ve talked a lot about CDS as if it’s a separate entity we’re building. To some extent that’s true, but that’s not the end goal. I see our CDS as our testing environment. It’s messy and we want to try and break everything in there to see how resilient our decisions are. But when content passes, we’ll pop it straight into the design system that’s already in use.
The last thing we want to do is create more documentation.
We want to speed up the design of common patterns and save our brain power.
For example, all of us in the Content design team have designed a server error message. When it’s in the system you can just pluck it out when you need it. The specifics might change, but everyone designing for this scenario will end up with an error message explaining what’s happened, inviting users to try again or giving them the option to discard the action and “Go back”.
We only want to redesign things if research or testing tells us we need to.
An added bonus is that this all really helps solidify the fact that words are a design asset and should be treated as such. Luckily for us, this is well known at Deliveroo but could be massive at organisations with less content design maturity.
What’s our strategy for the CDS?
Like I said above, it’s super early days. We’ve only recently found time to do this. If anything, I‘m hoping if I write all this up and open-source our thinking, we’ll stick to it. With any luck we’ll get some pointers from the wider design system or content community too!
Don’t get me wrong, I strongly believe in the value of this endeavour but it’s tricky. A design system is a full-time product and we can’t dedicate that much time to it yet. But we have a plan, so I’ll share that.
Establish use cases, purpose and acceptance criteria
Getting the whole team on the same page was really important, especially around the purpose of the system and who it was for. We’d spent many meetings in the past going back and forth about whether we needed more guidance for our team or for the disciplines we collaborate with. I wanted to make sure we were crystal about this as a group — so I created a one-pager that acts as a short intro to the system, outlining its goals and users.
We also decided on some acceptance criteria. It’s easy to spend a whole meeting debating just one line of content — so we wanted a framework in place to help with decision making.
For content to be accepted into the system it would have to be:
- accessible
This is a given - repeatable
Is there more than one use-case for this context? - optimal
We don’t add anything that we wouldn’t want to become a standard pattern — no workarounds - possible to localise
Avoid anything we know that makes life difficult for translators
This is our working framework, but we’re open to iterating on this as we go.
Validate early and often
One thing that’s been particularly useful so far is getting early feedback from Product designers (one of the system’s users). It sounds obvious, but unless you have the mindset that a system is a product, getting feedback early and often might not be top on the agenda — for us, it most certainly is.
Collate, debate, integrate
Like with any writing, a blank canvas is the enemy of just getting started. So as a team we just decided to go for it but work at it in steps. We opted to start with modals, so everyone in the team collated the modals they’d used in recent projects — all grouped by scenarios like “saving before quitting”, “cancelling changes” and “deleting entities” (actions often required in our tooling).
We deliberately went for breadth at first — it makes everything less daunting.
It roughly went as follows:
- Add as many modals as possible
- Go through as a team to decide on what we would/wouldn’t change
- Achieve consensus
We made these decisions at weekly team meetings, paying close attention to the acceptance criteria mentioned above. I also time-boxed discussion around each scenario to 10 minutes to keep things moving and ensure we didn’t get bogged down. If we really couldn’t reach a consensus we would park it and move on, attending to it later.
To wrap up
Everything I’ve read up on the subject so far tells me that you can’t treat a design system as a side project.
But we are getting somewhere. Our system now contains content patterns for toggles as well as lots of different modals that crop up in our products. Of course this will probably all change over time as we become more efficient but it was a great way to get started.
Even though we’re all stretched over many different products, just dedicating a portion of our time to it has bore fruit. I hope that’s enough motivation to get you started if you’re in a similar boat to us.
We’ve got a vision and we’ve made a start, so now it’s all about staying committed, disciplined and open to feedback. Content and design systems are steadily gaining traction so I look forward to reading more from others to see how they’re approaching this.
