Image for post
Image for post
Me explaining to my colleagues what I mean by a “Content design system”

Content, design systems need you!

Ryan Cordell
Jan 10, 2019 · 9 min read

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.

Image for post
Image for post
Cover page in Figma: got to start somewhere…

First things first, what is a content design system (CDS)?

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.

Image for post
Image for post
Our tools design system in Figma
Image for post
Image for post
A sneak-peek at our component library

How is a CDS different to a design system?

  • 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


  • 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

Image for post
Image for post

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 off
Label: [The thing] for example, Notifications
Subcopy: [The result of the off state] for example, No notifications for you


  • 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 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?

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”.

Image for post
Image for post
Some example backend errors from our CDS

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?

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

Image for post
Image for post

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

Collate, debate, integrate

We deliberately went for breadth at first — it makes everything less daunting.

It roughly went as follows:

  1. Add as many modals as possible
  2. Go through as a team to decide on what we would/wouldn’t change
  3. 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

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.

Deliveroo Design

Stories, tidbits and musings from the content, research and…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store