;

Design Section.

Featured Image

Overview

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

This article will be closing the Design pillar of three – Content [001↘︎], Experience [002↘︎], and Design [003↘︎]. This section has the most significant impact on the design integration within the product team. Here is where the design is correctly translated and paired with business objectives under the umbrella of a well-integrated design system well-documented rationale behind the design implementation.

“The purpose of the design section is to communicate design artefacts in a non-visual way to the wider community of professionals that uses the design outputs to generate the meaningful outcomes for the customer in the broader context of the business.”  – Jiri Mocicka, 2016 – Sky

Does it mean we need to copy our drive or export every iteration into a separate PPTX and then upload it to Confluence so that everyone knows what we are doing? 
Of course not. In the world of automation, scripts and algorithms are designers' best allies. To automate your daily routine, report less than 5% of your productive day (roughly 20 minutes). In comparison to hours spent on Slack to ask the most obvious question, “where is the latest screen?”

Especially when your design software is integrated with the company software ecosystem. Remote drive for daily backups, your screens are integrated with JIRA (or any other project management tools), and your work (Figma Boards) is linked to Confluence (or any other form of Wiki) to keep your colleagues fully informed. Then and only then, you focus five hours a day on creation.   

Figure02: Design Section.

What does the Design Section do? 

Structure:
/ Brand Vision
/ Brand Strategy
/ Design Principles
/ Manifesto
/ Brand Bible
/ Design System
/ Feature List – feature 01, 02, 03 etc
/ Component List – component 01, 02, 03
/ Product
  / Alpha – Release 
  / Beta – Release 
  / CR1.0 – Release
/etc.  

As you can see from the list above, the first item is the Brand Vision – every product or service must have a brand vision. Millions of designers move objects on the screens and ask your customer what they think and do not understand the Brand Vision through the research. Make all the information tangible, descriptive, easy to digest, and qualify. That way, your team grows wiser and makes smart decisions.    

The same comes down to Design Strategy – how is it manifested internally and externally, and how does it affect the team and the product. The more specific you are in your definition better the outputs will be produced (not necessarily more), and desired outcomes will be achieved.
Design Principles align with CX principles – one that represents the desired behaviour (an action) under the emotionally led connection (expression or need). Inherently it focuses on principles defining the experience and overall guidance for the product. Interestingly enough, some proposition does not see it as vital to creating or having one. When asking different team members what the product stands for, I usually get ten different answers–go figure how these teams can even make it to actual release.
Brand Bible – replicates what the static predecessors did. Only in digital, live, constantly evolving form that is completely intertwined with your future product. Several companies have their own bespoke solutions and one that chooses to be fully integrated with other providers. The choice is yours. 

Figure03: Brand Bible is not about colouring in.

Design System – most (none) designers think of the design system as a sketch file that orchestrates the rest of the files. Where in fact, the Design System is a logical response to a complex landscape of requirements and objectives in a visual form that is fully integrated across the business to deliver consistently and well thought through outcomes.
It has never been and design thing only. 

Feature list – looking into the last state of the feature and its functionality. Let’s take the login feature as an example; the logging seems different in different releases. Supports other APIs and security protocols, integrate with different SSOs and evolves in UI. That’s all documented in “words” in the feature list.  

Components List – This is a little easier as it represents the Design System. This part can be automated and changes less frequently than the above feature list. Think how many times you change the default button? The Component list, once created, can be maintained with little effort. 

Figure04: No assets delivery available

The Design Section Does not include.

Simply put, the designers do not like documenting. Therefore anything around documentation is quite a topic for more excellent debates. However, every designer expects other disciples to document so that we all can work simultaneously together – what a naive perspective, don’t you think?

Historically we have had PSD’s, AI’s, FireWorks, even InDesign files, and later Sketch to the least Figma. Outside of Figma, all the design apps carried out the challenges with versioning, and assets management, including measurements, just to name a few. (For those interested in running the documentation with these dinosaurs of the design industry, drop me the DM to discuss it separately – still possible if there is a discipline). 

Three main pitfalls of using the design section for: 

Asset’s delivery – With the arrival of Figma and the capability to share individual pages/views, it is relatively easy to document an entire pattern library in a few weeks. This completely cuts the middle man and the delivery of the assets in scale – while dealing with different language mutations, releases in different markets and content updated at the same time. Equally, delivering assets through any project management tool, including JIRA, is definitely NO.  

Comments on Design – Equally, the comments on design moved from inactive to active places. Even though I see some traditionally set up companies still working in Sketch, Figma exporting a PNG and uploading on to an inVision, or miro to gather feedback from the team. This means running two software versions and two different places for comments, which could quickly multiply with Slack and three stakeholders giving additional input in other areas. 

Figure05: Communicating design

The ultimate destination for the product – the last and the most concerning pitfall is to overpower other disciplines and make the design section the most prominent. While this creates tremendous pressure on the design, the other disciplines stop contributing because the design always tent wins. An unhealthy dynamic leads to a derailed team and a lousy products in the customers’ hands. 

In this case, everybody loses as no one really plays the part of building common knowledge with their peers. Design as a visual discipline should support all the others – to create diagrams, charts, reports and so on.  That’s how you make the transition between all other departments and glue them together. 

The design's biggest challenge is that it thinks it is in the centre of the business where in fact, it is in the middle of the process that makes the company the centre of excellence.   

“Don't confuse legibility with communication.“ – David Carson 

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: 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. @designatscaletm is open to discussion about detailed implantation. The next article will focus on the Development section and all information related to coding, deployment and versioning.
See you there.

Tagged: agile · coaching · collaboration · cx · dastm · design · designatscale · designer2designer · framework · madebyhuman · management · mentoring · Method · organisations · process · scale · sme · startup · ux · ways_of_working
EMT

Related.

Featured Image
Over the centuries, we humans have improved our tools to be sharp, resilient, and robust enough to conquer different materials in specific conditions. With digital ventures, we invented software to carry out digital work …
 · 
2023-01-04
 · 
8 min read
Featured Image
Welcome to the fourth article of this series that focuses on designers in the team of one. After touching on Ambitions, Beliefs and Design Philosophy, we are entering the more practical part of the …
 · 
2021-01-25
 · 
5 min read
Featured Image
Hi, I’m Jiri (in short J+). I’m a product designer who has coded since 1992. Before creating a design system, I built a wealth of brand guidelines and marketing packages for small, medium, and …
 · 
2023-01-02
 · 
13 min read
Featured Image
Welcome to the second article of the Design at Scale — Academy, which focuses on a designer in a team of 100. This article will explore how to evaluate a team, department, or business …
 · 
2021-05-21
 · 
5 min read
Featured Image
Welcome back to our Design at Scale – Academy series, focusing on the design practice in a team of one hundred. This article explores how design functions integrate within a business structure from three …
 · 
2021-05-14
 · 
5 min read
Featured Image
Welcome back to our Design at Scale™—Academy series, focusing on design practice in a team of one hundred. This article delves into the intricacies of integrated design teams within agile organisations.  While "HR organisation" …
 · 
2021-06-04
 · 
6 min read
Featured Image
Many designers worldwide ask the same questions repeatedly “how do we deliver our design at scale?”. In other words, how can we adapt to the change where our remits start and finish?   The answer …
 · 
2020-02-01
 · 
4 min read
Featured Image
Welcome to Design at Scale – this article will focus on the mindset and how implementing such a mindset can make a difference in Product Design Delivery. To understand the mindset definition, let’s borrow …
 · 
2020-01-30
 · 
3 min read
Featured Image
Welcome to the Design at Scale Method series. Today’s article has no more minor ambition than to connect, empower and unify all product designers under a simple Manifesto, which easily translates the value of …
 · 
2020-01-26
 · 
3 min read

Newsletter

Subscribe.

Subscription.

A tailored list of meaningful tips and assets that help designers of all levels manage their daily challenges at scale.

100+

Design Articles 

Join more than 5,000 readers who redefine product design delivery through Design at Scale™

INSTAGRAM—We know you love visual stories and bite-size quick suggestions. That is why we created an Instagram channel specifically for your taste. 

X – Daily updates, shared links, and conversations about scaling design propositions in small, medium, and large teams. Join the conversation.

DAS-Social

Your Story
Matters.

Contribute.

We're sorry you haven't found what you were looking for. Let us know your story, and we'll ensure it's broadcasted to the world.

All brands and trademarks presented on the DesignatScale™ 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 approval from 9V™ + GIVE™ + Design at Scale™ and/or relevant companies and agencies.

View