Overview

Welcome to the first article of the 3x3 series - Confluence for Designers, where we’ll be looking at the communication structure for medium and large organisations to achieve the transparency that leads to frictionless and smooth product design delivery.

Colleagues often ask me: 

“Why would we repeat the brand or product name in the structure?“ 

The reason is quite simple. 

While your proposition might be created in isolation to start with, it will soon grow alongside other parts of the business. Once your product or service has a specific name or can be introduced across the company without ambiguity. A unique name or an abbreviation means it will be widely recognised and fundamentally easy to locate in the future. 

Hello section does

The primary purpose of this section is to inform your colleagues about necessary updates related to the essential operation of the team or business. Any product team of any size will usually be part of a department or function. Therefore, a chain of responsibilities and feeling practical information in your hub is not just wise but highly beneficial to anyone who will collaborate with your team in the future.
It allows you to deal with a question like “where is the latest org chart”, “who is responsible for X” and finally, “where is the dialled number for zoom”. 

It also contains onboarding information for new team members, such as setting up email, signature, installing software, dealing with hardware and logging into different parts of the company’s ecosystem.

 
The interactive org is based on the team’s maturity in some cases. Charts help the wider team navigate the responsibility chain. If this information is in the form of PPTX, it’s pretty common not to be up to date or miss correct names and associations with an existing team. This simple fact wastes 28% of onboarding to locate the accurate information and get set up correctly. It also shows the team’s to mature – for this topic, let’s wait a bit as we prepare a specific series about the product team’s design maturity. 

The WoW can be inherited from the more dominant organisational functions, but it is always good to have your version. Here is why; the centralised operation team does not know your challenge's specifications or the workflow your team needs to go through. It’s an advantage for any new designer joining the team to visualise their understanding of how they deliver design work. At once, you’ll understand it, and second, your CPO® will reuse it in his next presentation to stakeholders.    

It eventually becomes a complete library of the product engagement strategy that makes your team’s work stand out. More importantly, this section shows that you understand the bigger picture beyond a designer’s daily responsibilities and slowly start owning it.  

What does the hello section not offer?

While implementing this structure has proven vital for the transparency around the product, there are also some pitfalls along the way: slow business response, clarity of provided information, politics or silos, and possible duplicity of what exists somewhere else.  Let’s look at a few. 

Slow Business Response – this is usually the case where everyone is busy delivering and has no time to do anything else. In this case, it’s your call; do you want to build different alliances and strengthen your relations with others or just deliver the daily task?

The clarity of provided information – shows that business acts from the scarcity model; This is an even more significant opportunity for designers to drive innovation by clarifying everything through the design delivery process and improvement.     

Politics and silos – Careful here; exposing someone's incapability could be your fast route out of the team and soon out of the company. Do not ask your boss what he does not know, and do not make it a problem – no one likes them apart from designers, philosophers and scientists. Make it shine if you are in the bubble (aka silos). It is your territory now, and if it works well, others will copy it and help you scale it.  

Duplicity – the first thing is that everyone will tell you it exists somewhere, but no one knows where. Suppose you find it, great. If it’s good, use it; if not, update it and link it back to your team. Either way, the exposure for designers is limitless. 

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