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. 

Figure02: Algorithm-driven Content. 

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. 

Figure03: Content location and versioning.

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. 

Figure04: Why does the one location matter?

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. 

Figure05: Content at Scale.

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.

 
Figure06: Confluence Structure.

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

I hope you’ve enjoyed the fifth article from 3x3 – Confluence for Designers. Please contact me at @designatscaletm to discuss this implantation in detail if you have any questions. The next article will focus on the Experience section and all information related to navigation, and mental and behavioural models connecting the Research and Content. See you there. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this very article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories @designatscaletm
For direct messages and questions, please follow: @designatscaletm