Chapter 1: The Importance of Transparency in Design

Welcome to the second installment of the 3x3 series, where we delve into the communication framework essential for medium to large organizations striving for transparency in design delivery.

A common question from business colleagues is, "Why should we share all our updates through Confluence?" The answer is straightforward: in an ever-evolving environment, transparency is crucial for fostering trust. If you hesitate to provide your team with all the necessary business information, how can you expect them to create the right products for your target market?

This relationship between investment in business and design is vital. Numerous Harvard Business Review articles highlight businesses that thrive due to effective design, yet few acknowledge how transparency within business units contributes to this success. But what does this mean in practical terms, and how does it manifest?

In my experience, this goes beyond what you might find in publications like INC or HBR. It reflects a mindset rooted in the Bata family's culture, where transparency and "brutal honesty" became part of their weekly routines. For families of that era, sharing insights on progress, goals, challenges, and methodologies was essential for collective success. This culture of transparency ensured that everyone was engaged and accountable.

Let’s fast-forward to the present and examine how these values support global digital product design delivery.

Chapter 2: Defining the Role of the Business Section

The Business section within a Confluence structure serves a distinct purpose: it is designed to define, manage, and oversee project delivery. This is where design integration and automation come into play.

This section encompasses Core and Aspirational Values, Product Strategy, Delivery Roadmap, and Roll-out plans. It is crucial for maintaining editable product definitions, including version control. It allows for close monitoring of ROIs, OKRs, budgets, legal considerations, risks, and timelines—all essential for product owners to validate project feasibility and ensure a successful launch in a clear and shareable format.

"Transparency inherently encourages the team to participate in cost-saving initiatives—essentially optimizing how we achieve our goals."

To illustrate how this benefits both business and design, consider a brief anecdote. An Italian Product Owner joined a large product team, and two months later, I became part of the team. Instead of receiving a collection of Word and Excel documents, I was pleasantly surprised to gain access to Atlassian Confluence. As I navigated through the well-organized documents, I identified opportunities for collaboration across interconnected verticals.

By utilizing Confluence, we could streamline communication, ultimately leading to consistency in our outcomes as reflected in OKRs and KPIs. Design transcends mere aesthetics; it embodies the definition of core behaviors.

After a few initial strategy sessions—focusing on how design could facilitate transparency to the C-Suite and how automated monitoring could save time on reporting across multiple programs—we reached an agreement to develop a small proof of concept.

This initiative allowed us to manage the design delivery and product strategy for three products efficiently, eventually expanding to two additional products to create a robust platform. Over the next five months, our efforts resulted in a 22% reduction in reporting time and a 16% decrease in the time spent translating information between streams—effectively saving two days in a five-day workweek.

The product owner received recognition across the group, and the designer advanced to a director role. This underscores how openness in business strategy and challenges fosters adaptability and drives innovation while maintaining focus on one or multiple products.

It’s essential to note that a foundational understanding of Atlassian products is vital. The effects of this transparency extend beyond design; they permeate weekly and monthly reporting, daily stand-ups, and team rituals, enhancing engagement often overlooked in integrated teams.

Chapter 3: What to Avoid in the Business Section

If the Business section devolves into a repository of PowerPoint, Word, and Excel documents, it may be better not to have it at all due to the risk of duplicating information. If your team already utilizes platforms like OneDrive, Office 365, or Google Drive effectively, with well-organized documentation and versioning, there is no need to switch. However, if these systems expose opportunities for transformative improvements, it may warrant consideration.

For instance, if a midsized company or studio is already managing its basic finances through Office 365, transferring all documents to Confluence is unnecessary. Instead, it’s crucial to share only those documents relevant to the product team engaged in creating a product or service, especially if project identification information evolves early in the process.

Two common inquiries arise here:

"Can we achieve collaborative effects while defining the product in Office (or any other platform)?" — Yes, you can.

"Can we create an interactive document that reflects the current status of a program or product?" — No, unless you invest three times the effort to link Word documents with tools like Trello, Asana, or Jira for real-time updates.

For additional insights, consider joining the Design at Scale™ Courses, which explain the function, impact, and common pitfalls to avoid when implementing the DaS™ framework in your organization.

Structure Overview

Let’s examine the detailed structure within Confluence:

1.0 — BRAND* Hello

2.0 — BRAND* Business

3.0 — BRAND* Research

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

Thank you for engaging with the third article in the 3x3 series on Confluence for Designers. Should you have any questions regarding the implementation, feel free to reach out to me at @designatscaletm. The next article will explore the Research section and its significance in understanding integration. Until next time!

Special thanks to all contributors, students, and design directors for their valuable insights that shaped this article.

Jiri Mocicka is a London-based Designer, Design Coach, and writer who is passionate about Design at Scale—a flexible methodology that empowers design professionals to integrate the value of design within their organizations through transparency and effective product design development.

Design at Scale™ Method: Offering articles, an online academy, and designer resources. For visual stories and direct questions, connect with us at @designatscaletm. Thank you for reading!