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 to this question is widely defined without considering different methods or disciplines contributing to the delivery process. Linear processes like “the stage and gate” where deliverables are in large “thrown over the fence”, which we proved do not work for 90% of digital product development. The second method taken from the agency world of storytelling in 1996[00], called double-diamond, allows visualising the delivery process linearly, emphasising diversion and conversion. It worked like magic for a decade or so, where digital designers communicated how complex design propositions are to make them simple.    

This short article aims to answer the above question and offer “a different perspective on delivering design at scale” without losing control over a holistic experience while continuously supporting our engineering team by delivering the increments. 

“If you can't describe what you are doing as a process, you don't know what you're doing.”  —W. Edwards Deming

What if, instead of forced workflow for designers, we develop a fluid space  (let’s call it Hub for now) where we all follow one another. Extending the inherited linear workflow for any unique proposition to a flexible and exponentially led approach allows us to share and see all information.  

Moreover, it allows designers to transition from a sequence led, redistributed and chaotic communication into a robust, transparent and scalable Design Centre of Excellence that offers product teams clarity and facts. Leave behind the communication channels like slack, groups, teams and mail; we can look at the communication as commonly shared knowledge as such and reuse it to our benefit. In other words, the knowledgebase captures all information into one single ecosystem for product design delivery.   

Discovering 3x3

We all have seen the structures organised around products, or products of products, around disciplines or business units. Despite the challenge of all the above, I’ve remained explicitly focused on the information structure of digital product hubs. With well-documented feedback from all disciplines, I’ve crystalised a communication structure around any process.

We learn that each part of the business prefers its perspective or lens on the product. Companies look at the numbers, speed, and spending. On the other hand, the design looks at the consistency, patterns definition, plus functionality or desired behaviour where developers seek a clear BDD (or TDD) definition and resources to reduce refactoring ultimately. 

And that’s where I discovered the three by three (3x3) framework.  

Business — focus on the operation, budgets, vision, and objectives,  including team structure and onboarding. 

• What do we expect from our proposition? 
• Who do we compete with?  
• And how do we address the differences in our product?

Design —concentrate on the content and experience of the final design proposition, including assets management. In other words, how this thing looks, feels and behaves. 

Development —concentrate on sharing information about APIs, databases, and data migrations along the way, tracking the releases and integrating what we have built.

This straightforward framework allows everyone to maintain and digest information in a specific way. Equally, redistribution of the content immediately leads to complexity reduction and simplifies the communication around the topics.

I have separated them into a series of articles to get a detailed overview of the problem and see all the parts in the actual products’ context.

The philosophy behind

We believe that transparency is the key to success and that every team member is here to contribute. We do not build on responsibilities and duties; we thrive with our accountability and contribution. We all help define a better future – for us, the product,  the business proposition and the cause we all proudly follow.

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

The next article will concentrate on where we store the information about the team, meetings, and bits that make the team connected and well-lubricated so that no one can ask where is “X”?