Scaling content design

⤢

Content design sits at the intersection of every craft, and the seven guidelines live where they overlap

Challenge

Over two years, Questrade's content design team grew from four designers to ten, across four lines of business and five platforms. The old UX writing style guide didn't keep up. Guidance was scattered, governance was unclear, and the result was inconsistent content, slower delivery, and a fragmented experience for customers.

Allspark was maturing from a component library into a full enterprise design system, with no clear answer for how content design fit in. Two gaps showed up at once:

The core question: how do you turn a fast-growing group of writers into a content design discipline that scales, with both a system to follow and a team that can run it?

Guiding principles

The discovery insights set four principles that steered every decision after:

My approach

I worked two fronts and connected them: the system content design produces, and the team that builds and runs it. Neither holds up without the other.

Part one — the system

A vision: content's role in the system

With UX leadership, I set the north-star vision: seven guidelines spanning writing, terminology, components, design patterns, design principles, brand, and product principles. For each, I defined what it is, who leads it, and who uses it, so ownership was clear before any writing began.

⤢

The seven guidelines, and which ones live inside Allspark

What a content design system actually is

The hardest part was conceptual. A content design system is not a doc off to the side. It is content's guidelines woven into the design system itself, the way Polaris and Material do.

⤢

What a design system is: components, patterns, and governance

⤢

Fully integrated: content woven into UX, UI, and engineering

Securing buy-in across the org

A system no one believed in would die in a doc. So I took the case to each group with a stake in content, UX leadership, engineering, product, and marketing, tailoring the pitch to what each would get from it, and grounding it in how Polaris, Material, and Deliveroo treat content as part of the system. Buy-in was the real unlock.

⤢

The case I took to each team to build buy-in

Patterns, not just components

I drew the line between components and design patterns, because content reaches past the screen. A price-change reminder is one pattern that surfaces in-platform as a banner and out-of-platform as an email. Defining patterns alongside components kept content consistent across every channel.

⤢

Design patterns span channels: one reminder, in-platform and out

From MVP scope to templates the team could run

With UX leadership, I scoped the MVP to the three highest-impact guidelines: writing guidelines, the terminology glossary, and component guidelines. Then I built a template and a how-to for each, and mentored a senior content designer to lead the writing guidelines end to end, so ownership lived with the team.

⤢

The documentation template for each guideline

⤢

The how-to for building and maintaining it

⤢

Prioritizing solutions by impact and effort, into a backlog the team owns

We turned the fourteen themes into a hundred-plus solutions, then prioritized down to thirty-nine the team could own, from clearer roles to building content design QA into the delivery process.

The real shift wasn't the backlog. Working through their own problems as a system taught the team to think in systems, and all ten reported a stronger grasp of how their work connected.

To hold that alignment through delivery, I set up the infrastructure to sustain it: bi-weekly cross-team syncs, dedicated Slack channels, and one Confluence home, so content, UX, engineering, and marketing stayed on the same page.

Where the two meet

This is what made the system stick. Once the team could see their own craft as a system, they could follow the guidelines and governance I had defined, and build and maintain them alongside the Allspark designers and engineers, instead of treating them as one more doc to ignore.

The system gave the team a standard. The workshops gave them the mindset to run it. A content design practice only scales when you build both.

Outcome

We launched the Allspark MVP ahead of schedule, with all three guidelines integrated into the design system. Content design had a defined discipline, one source of truth, and a team aligned to run it.

⤢

Writing guidelines

⤢

Terminology glossary

⤢

Component guidelines

For the business, that meant faster delivery and more consistent quality, and it fed the wider Allspark transformation, which shipped components 60% faster with half the error tickets.

Reflections and learnings

Defining a discipline is different from writing guidelines. The lasting work was not the docs; it was giving content design a role, a system, and a team that understood both. That is the part that outlives any one project.

A system needs a team that can run it. The workshops taught me that alignment and mindset are as much a deliverable as the guidelines, so I now build the team's systems thinking alongside the system itself.

Leadership shows up in empowerment. Mentoring designers to lead the work, and handing the team thirty-nine fixes they owned, did more for the practice than anything I could have shipped alone. With no dedicated product manager, I held the strategy and the execution at once, which sharpened how I lead complex, cross-functional work.