;

Content Section

Featured Image

Overview

Welcome to the fourth article of the 3x3 series - Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design delivery.

The content section is controversial; 

“Why would anyone copy every single document to confluence? They wouldn’t unless they can link them directly to the live  code or have a rigorous regulatory process.”

And that’s what we have built – literally.
If you are a business with no written content and the only copy you are dealing with is an “OK” button, skip this article altogether and make yourself a nice cup of coffee. However, if you are a business that has to review many documents across different seasons, versions and stakeholders to update your product, you are in the right place.  
Outside the definition of the content strategy, language guidelines, naming convention, and tone of voice across the product, we focused on day-to-day copy tasks that need to be done. Confluence versioning, positioning, rights management and sign off process helped us enormously. 

Wordsmans (including females and males) are probably a less acknowledged part of the team. Yet without them, our product and service have little to no character. Their work creates the difference between the success and failure of whatever we designers do. Of course, we all can define and write the UX copy for a “Buy” button. Still, very few designers or developers can de-touch their experience and create a compelling story that supports the design and function and resonate with a broader audience. 

What does the content section do?

That’s why we have the Content Section in Confluence to help us utilise all knowledge about the story behind the product or service. Yes, you can write a copy directly in code, and some design software using the plugins allows that.  What happens with season updates, reviews, overall sign off process for different language mutations or several studies when it comes to legal documents for public view. 

We all have different challenges. For a brief moment, imagine five different business units that are loosely linked together yet inherently, from the customer perspective, act like one. Try to capture where your copy (story) will repeat, be elusive, misleading or contradicting if you have 20.000+ pages of content across 500+ domains. 

On top of that, each (page) document, regulation, T&C, help or just simple payment mechanics must be reviewed by the legal, risk and governing representative acknowledging the validity of such information. 

With confluence and simple “Include macro”, we have distilled all documents of all the propositions mentioned above with over 20k live pages of products and services into one comprehensive proposition. 

Complete reduction of Microsoft Word documents scattered all over the business followed the automated revision of repetition of the paragraphs on different sites. A simple example will be the footer that has 42 different links to T&C – after our automated exercise, there was just one link to one T&C.  

Review and automated sign-off from 2-20 members of risk, legal, insurance and BAU (business as usual) speed up the transparency amongst departments that equally provide the live copy to our developers integrated through a simple JSON file. 

I have the privilege to work with the finest copywriters in both customers facing and legal/risk departments, which has significantly impacted my appreciation and humble understanding of the profound impact of well-written English. It equally supports the ambition of automation that reaches the development sooner than the code is released live without formal approval. 

Detailed versions and structuring can be found in Design at Scale™ workshops. 

What the Content section does not?

The first it’s not a dump yard of World documents mentioned above. The problem with uploading the document to confluence means they are partially searchable, yet they are not part of the versioning. 

Uploading one document over another – is the practice of some less experienced copy teams. This will only mean that you’ll have the information in one place but no interactive, and there will be no chain of quantitative information about the document (page) unless you download and open the document. 

This increases the complexity of naming convention – forever challenging for every team, especially if you inherit the structure after someone else.

Word vs Confluence page – Word as an attachment to the confluence page can not be integrated into the code. Whereas the confluence page can be easily translated to the source code – .jason

Changes in Word can not be tracked in Jira, making it hard to manage and work a schedule. If the Confluence page is signed off, we can link the page to Jira and schedule for deployment.  

For more information, please join the Design at Scale™ Courses that explain the function, impact, and common pitfalls that can be avoided while implementing the DaS™ in your business.

 

Structure

Let’s look at the Confluence structure in detail:

Business

1.0 — BRAND* Hello
2.0 — BRAND* Business
3.0 — BRAND* Research

Design

4.0 — BRAND* Content
5.0 — BRAND* Experience
6.0 — BRAND* Design

Development

7.0 — BRAND* Development
8.0 — BRAND* Releases
9.0 — BRAND* Integrations

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Product Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to define teams of 01, 10, and 100, and 1% supported by Grid Magazine and Supply section, where we bring more insights weekly on how to become a design leader in your Agentic Organisation

Author's Name

AVATAR

inResearch

32

inWriting

65

Released

240
EMT

Related.

Featured Image
A little over a year ago, we delivered a basic tokenised design system for a client’s retail operation. Last week, he rang me up …
March 19, 2026
 · 
4 min read
Featured Image
Empathy as Infrastructure: The Internal User Experience of Scaled Systems The ultimate metric of any enterprise system is a deceptively simple question: Does it …
February 16, 2026
 · 
4 min read
Featured Image
The code that stands still does not reflect your agentic systems. Over the past five years, more than a thousand agentic systems have found …
February 10, 2026
 · 
7 min read
Featured Image
Unbiased Scale: Driving Corporate Alignment Through Systemic Decision-Making In a large enterprise environment, product design decisions frequently devolve into a battle of subjective opinions. …
February 9, 2026
 · 
3 min read
Featured Image
AI Design Tools Have Arrived — But Is Your Practice Ready? AI design tools are now capable of transforming a solitary prompt into a …
February 3, 2026
 · 
7 min read
Featured Image
Building the Retainer That Scales — Part Two: From Argument to Architecture Article One set out the case: the agency retainer, contrary to rumour, …
March 24, 2026
 · 
6 min read
Featured Image
The Retainer Is Not Dead — What Should You Do Instead? The agency retainer was one of the most elegant commercial inventions of the …
March 17, 2026
 · 
6 min read
Featured Image
In our digitally mediated age, user interface design is no longer a mere decorative advantage of commerce. It has become the very engine room …
January 20, 2026
 · 
5 min read
Featured Image
If Ford built the rhythm of production. Toyota taught us to improve it. And Baťa gave it purpose. Then along came digital and transformed …
March 19, 2025
 · 
4 min read

GRID Magazine

Explore OUR 
Articles

Every week we bring set of stories reflecting on communication, operation and technology.

Newsletter

Subscribe.

We share our 20 years of experience in creating, managing and scaling products and services that allow individuals to shape organisations through design.

Design at Scale™

LINE_MAGENTA_050_301

Categories

LINE_MAGENTA_050_301

Data

LINE_MAGENTA_050_301

Share

Internal

Collaborate

Resources

IBM PlexSan
Regular
Charcoal

Design at Scale™ is defined by three models, which form the Method. Each model operates in a different part of the business and collects and informs parties on design and engineering decisions that have a direct impact on the delivery.

All brands and trademarks presented on the Design at Scale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners. Do not copy or publish any of the projects shown here without written approval from Design at Scale™ (alternatively GIVE™, 9V™) and/or relevant companies and agencies.

SOC_Twitter
SON_LinkedIn
SON_Instagram
SOC_-Medium
View