Overview

Welcome to the third 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.

I often hear from businesses colleagues, 

“Why would we need to share all our updates with our team over a confluence?“ 

The reason is quite simple – transparency plays a vital role in building trust in a constantly changing environment. If you do not trust your team to deal with all the necessary information about the business, how can you trust them to build the right product for your target audience?

“In other words, there is a close relationship between those who invest the time, energy and thoughts into a #business2design relationship – so should you.” 

You do not have to go too far. Harvard Business Review is full of compelling articles about businesses succeeding thanks to the design, though very few mention the many designs that succeed thanks to the transparency of the business unit. But what does it mean in practice, and what does it look like?

I suppose in my case; it goes a little deeper than INC, HBR, coDesign or other articles. It started as a mindset of the Bata family and workers who ingrain transparency and, in some respect, so-called “brutal honesty into their weekly working routines”. Suppose a trait of all the families of that era was to survive. Sharing information about progress, ambition, challenges, and approach was vital to everyone's success. Transparency kept everyone to be involved – to care. Everyone is part of the picture – everyone is accountable. 

Let’s fast-forward a century and look at how these traits support digital product design delivery globally.

What does the business section do?

Business sections of the Confluence structure are designed for a specific function. The function of business is to define, manage and oversee the delivery. And that’s where the design integration and automation come in.

It includes the Core and Aspiration Values, Products Strategy, Road Map for delivery, and Roll-out plan. Exclusively it holds a product definition in editable (including the versioning) form. Close monitoring of ROIs, OKRs, Road Maps, budgets, planning, legal, risk and other timelines  —  you name it. All for the product owners to justify the project feasibility and all necessary aspects of the successful launch in easy and shareable form. 

“Undoubtedly, the transparency makes the team more involved in cost-saving activities – in other words, how best we can achieve X.“

To give you a little flavour of how this could help both business and design, let me bring a short story that represents the best of the business section. 

An Italian Product Owner has joined the extensively large product team. Two months later, I joined the team and worked alongside his teammates. Instead of sharing the set of word documents and excel sheets common among these professionals, I was positively surprised to receive the link to Atlassian Confluence. While going through the initial set of organised documents in a very business-oriented way, I spotted an opportunity for collaboration and co-ownership of several verticals that were tied together. 

See the fact of having all text documents in Confluence; you can run some pretty basic scripts start to simplify the overall message over +3mil words. That soon leads to consistency and joined outcomes shared across OKR, KPIs, and the overall rolling strategy for the product. Design is not a “colouring in” function but carries the definition of all core behaviours. 

After a couple of initial sessions about the proposed strategy, how the design can help facilitate transparency upstream to C-Suit and how the automated monitoring can save us time on reporting across three programmes, it led to an agreement to build a small proof of concept. 

We quickly gained control over three products’ design delivery and product strategy with this concept and soon acquired two more to build a robust, scalable platform. The following five months showed that our little ambition saved us 22% of the time on reporting and 16% on translating the information from one stream of information to another (simply copy and paste). That was pretty significant, saving two days from a five-day workweek.

The product owner gained group-wide recognition and responsibility, and the designer moved to the design director role. This only shows when the business opens up and shares its strategy and the challenges; it’s easier to adapt and drive the innovation forward with a necessary adjustment while keeping an eye on one (or many) products. 

It’s important to say here that the elementary knowledge of Atlassian products is essential. Moreover, the impact is not in the design area only. It’s spread over the weekly and monthly reporting, daily stand-ups, team and disciplines rituals and delivers a vital engagement missed in many integrated teams. 

What the business section does not?

If the business section becomes a damp-yard of PPTX, WORD and EXCEL documents is better not to have it. For a straightforward reason and its duplicity of information. If you are already working on One Drive, 365 or Google Drive and your documentation, structure versioning, especially business documentation, is in good shape (and easily accessible, linked together and connected to code), do not change it – if not all the above shows you an opportunity for transformative future.

A simple example here would be the midsize company or studio already documenting their basic finances in the business in Office 365. Copying all documents to Confluence makes no sense. Copying the documents that are relevant to the product team that creates the product or service is essential to their knowledge – especially if the information in PiD constantly evolves at the beginning of the project identification. 

Two most common questions here:
“Can we achieve a collaborative effect while identifying the product in Office” (or any other collaborative platform) – the answer is YES.
“Can we achieve an interactive document that represents the current status of a programme or product” – the answer is NO (unless you spend 3x amount of time linking your word document with Trello, Asana or Jira to get up to date updates)  

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

I hope you’ve enjoyed the third 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 Research section and all information related to understanding and its integration. See you there.