Atlassian Documentation for Product Design Teams Part 2
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”
— W. Edwards Deming
Welcome back. In the last article, we discovered the “Power of One” and how it shapes the thinking behind design delivery within an organisation. This article aims to answer the questions around the Confluence structure that empowers product teams. In other words, the continuation of the journey of creating one single ecosystem for product design delivery.
Discovering 3x3
Whilst perfecting the “Power of One” proposition and spreading the word, I’ve come to realise that the structure starts shaping in a very particular way.
I have seen the structures organised around products, or product 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 products hubs that help build websites, apps, features, integration of services.
The DaS™ framework has been challenged by 40+ startups, 30+ SME and 6+ big organisations across two decades, covering projects within media, fitness, healthcare, education, technology, retail, finance, auto-moto and very recently by gaming. With well-documented feedback from product owners, scrum masters, designers, developers and the overall clients themselves, everyone has played a part in shaping this very framework.
We learn that each part of the business prefers its lens on the product. Companies mostly look at the numbers, speed, spending, where 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, that’s the three by three (3x3) framework worked for me ever since. Let me explain how:
- Business — focus on the operation, budgets, vision, 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 — concentrates on the content and experience tied to the final design proposition, including assets management. In other words, how this thing looks, feels and behave.
- 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 their specific way. Equally, redistribution of the content immediately leads to complexity reduction and simplifying the communication around the topics.
The philosophy behind the 3x3 model.
We believe that transparency is the key to success and that every team member is accountable to contribute. We do not build our responsibilities and duties; we thrive with our accountability. We all help define a better future–for us, for the product and for users/clients we all support.
— Jiri Mocicka 2015 SKYQ, UK
The 3x3 allows all team members (even those whose mother tongue might not be English) to contribute without ever feeling guilty of imperfection. Those who understand the holistic picture will fix and improve any issues.
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
*is the name of your proposition, product or service. If the name is too long, please do try to shorten it by abbreviating it or creating an acronym — for example, Design at Scale = DaS™
1.0 — DaS Hello
The hello section usually contains onboarding information, such as setting up email, installing software and logging into different parts of the company’s ecosystem. In some cases, based on the team’s maturity, it’s supported by the interactive organisation charts, accountability matrix and people (contributors) personal hubs. It eventually becomes a complete library of the product engagement strategy that makes the work stand out.
2.0 — DaS Business
The Business section is designed for the business exclusively for product definition and monitoring. ROIs, OKRs, Road Maps, budgets, planning, legal, risk, timelines — you name it. All for the product owners to justify the project feasibility and all necessary aspects of the successful launch.
Undoubtedly, the transparency makes the team more involved in cost-saving activities. In one instance, a young front-end developer over the weekend wrote a testing script/guide for the platform to reduce the QA and refactoring by 7%. When asked why he simply said, “by doing so, I can go home at 5 PM and see my partner instead of being here and rewiring testing scripts reflecting instantly changing business objectives.”
3.0 — DaS Research
The research section includes all customer and competitive landscape analysis. On the completion of this section, we make the most valuable decision for the product. Each department (business, insight, research, customer, design, brand, development etc.) is accountable for its own contribution. As one CEO recently commented,
“No research and no understanding of the market equals no right decision about direction or the product itself”.
4.0 — DaS Content
The content section is the controversial one; why would anyone copy every single document to confluence? They wouldn’t unless they can link them directly to the code.
The content section defines and integrates the content strategy, language guidelines, naming convention, and tone of voice across the product. All supported by versioning, positioning, translations. It is not really about the content, but how we handle it throughout the experience and how best we deliver it to designer and developer.
5.0 — DaS Experience
The design-related sections are the ones where I spent most of the time (apart from setting up the rest) This is where I realised how much repetition is created by not contributing to the same cause. Fortunately, history has told me how to support my colleagues by providing the correct information at the right time.
Starting with a Vision, Blueprint and framework followed by the Feature and Component list, this section is the experience hub. As rightly expected, this section includes the information architecture, sitemap, behavioural and navigational models. Yet, it does not focus on the quantity to document everything; instead, it focuses on clarity. These pages are constantly updated where only the latest states are available. Essentially, it allows the business and engineering to see the progress in real-time. Contribution is encouraged throughout the whole development cycle. Depending on delivery model BDD (or TDD), we include User Testing Scenarios and Design Sprint Knowledgebase.
6.0 — DaS Design
The purpose of the Design Section is to define the Design System and Brand bible. It depends on the CPO to describe how they want to drive this–in other words, what makes more sense.
Model A/ (centralised model) looks at the product as an ecosystem where different touchpoints are redistributed equally across the feature. On the other hand, model B/ (silo model) focuses on touchpoints like Watch, Mobile, Desktop or TV, allowing mental separation for a specific platform, device or audience. Both have their advantages and disadvantages. Ultimately, it’s up to the team to decide what is best for the particular scenarios.
7.0 — DaS Development
The development section focuses primarily on documenting issues in their field. API’s calls, Databases, Security protocols. One of my teams used this pace to mirror their documentation from BitBucket — a superbly innovative and transparent solution on how to document the code for new developers who will eventually join the team.
8.0 — DaS Releases
One would think this section might not even exist. Outside of business and Experience, this is the most critical part of our Confluence structure, where everything collides into physical release.
This section is the newest among the other combining releases–Alpha, Beta, Candidate Release 1.0, 2.0 in separate hubs that are easy to monitor. Each release has a separate page showing the summary from JIRA. The set of macros visualise a team’s performance, burn rate, productivity and overall operational efficiency across the product. This makes it a fantastic place for stakeholders to see the progress and the proposition’s current state.
9.0 — DaS Integrations
The last section summarises all 3rd parties APIs integrated with the product or service. It could be run as a palace for internal integration (data collection, API management, Privacy etc.) or as a place for an external integration (social platforms, marketing, user management etc.).
There is much more to say about the framework and the challenges of implementing specific requirements for small, medium, and big businesses. The following three articles will be looking separately at these three pillars, business, design and development, in great detail.
I hope you enjoyed the second part of this story. I look forward to welcoming you in a week’s time to see how this all continued.
Article Glossary:
*Power of One — a method I was using between 2006–2013 to deliver products and service. It’s defined by One language, One place, One Team, One Product (or service)
**3x3––is a structure that combines the needs of the main three pillars of a product design development process — business, design, development.
***Design at Scale––it’s a framework combining two above and 16 other methods into a powerful and very flexible proposition that allows the small and big team to achieve desired transparency and progress with the development brighter (and inevitably faster).
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 writing about his passion for the Design at Scale — integration and design operations that builds excellent digital products.
