Atlassian Documentation for Product Design Teams Part 1
By: Jiri Mocicka
Tags: Product Design, Transparency, Das, Documentation, Atlassian

Investing hundreds of hours in discussions helped me to model this method. If you were wondering, I’ve just implementing DaS159. After almost eighty (80) failures, successes, advocacy, presentations and liberation of this framework, I have started to call it a Design at Scale.

Figure 07: Design at Scale Confluence Hub

It’s like marmite: you’ll either love it or hate it.

One of the English sayings about Marmite resonates with the second stage of my mission. How do I persuade anyone to use new tools like JIRA or Confluence, especially if they already use other tools already (such as email, Microsoft Doc, Excel, Powerpoint, Slack, Miro and Trello)?

All these tools have their embedded pattern of usage. The challenge comes with the scale where all of them fail and creates unnecessary complexity.

Just a side note: Over the last year 2020, seven (7) implementations of DaS™ was carried out alongside tools like Slack, miro, Zoom, Skype including Office365. Ultimately it was only the Atlassian tools where we make our decisions, move the increment forward and deliver progress across the whole product.

The developers were in; they had already used Bitbucket and Jira, so extending the well-integrated tool with Confluence just makes sense. The challenge comes from the other two: business and design.

The business took it their way. At the very first, they uploaded all their PowerPoint, Excel and Word documents as an attachment to the page called “the latest version”, which essentially ended up as a dump yard for anything related to the project with no real impact on the delivery. More blame for the method to not work for the specific organisation. Although after some discussion (well spotted PowerPoint presentations Figure 10: The pillars of Power of One) and practical workshops reflecting the impact of the one location, we shift their perception from a hard-drive led mindset to the wiki and Google-Doc contribution mindset.

Slow adoption had its benefits. New ways of working brought several scenarios that we have documented and then in parallel amended according to their one requirements. In one project, we standardised 450+ word documents into about 18+ specification hubs linked all together. This had a massive impact on the business in general. There was no duplicity, no hidden agenda, no other plans within the project, no additional cost attached and, more importantly, no wasted time with muddled communications.

The more significant challenge came from the design side.

Do you remember when we produced 1200 pages InDesign decks in AB/C Agency describing the product or service? Then we would ship them over to India, where all our FE and BE engineers spend a month understanding what is going on and what we are looking for. The result? They built a completely different thing.

The following stage was to bring all the designers into the same place. Same as with the business, we have to go through the phases where everyone just dumped their file or png on to a page without ever describing it. Fast forward six months, we have reduced the amount of graphics by half and standardised the proposition with over 100+ features across the team of 40+ designers, researchers and copywriters.

Figure 08: 3x3 illustration

I discovered a forming pattern about structure that works for the majority of scenarios. Whether we’re talking about launching an educational platform for Pearson, building the next generation of viewing with SKY Q, or transforming a UK retail bank, this framework’s tide connection allowed us to empower their teams.

We have made better, more defined decisions and adapt to the change much faster because we have the correct information in our hands.

Transparency

We can all agree that transparency is a driving mechanism of trust. Trust creates the freedom to share, and sharing itself represents the care in the form of ownership. Simple and very practical, especially in big (or the fats-growing) companies that often end up working in silos.

The key to success is for all of us to agree that our focus shouldn’t be all about the product and transparency around product development. Hearing anyone from the team declaring responsibility for a product doesn’t help.

Let’s face it, Managers are not responsible for the product–but simply for the management of the moving parts, communicate vision, finding the budget and empower those who are accountable for their expertise. Designers are not responsible for the product–but merely for simplifying the complex picture, defining the experience and an appropriate brand expression that will represent the product. Finally, Developers are not responsible for the product–they’re masters of translating all ideas work in a particular way.

All of them have accountability to deliver the best increment and help the next person to do the same, just as if they were passing a brick to build a wall. It’s a joint contribution; each and every one of us is accountable to place the current brick as best we can.

The power of one

With this understanding of togetherness, we can start discussing “The Power of One”. If the group of people is empowered by one language, contributing to one location and acting as one team, they can build a significantly more robust product than any other team out there.

It sounds quite idealistic, right?

But let me show you a simple example of a company with 100+ designers, five divisions, six different channels of engagement, maintenance, vision, strategy, six different brands, and 17 passwords that were changing monthly to serve under one roof. This complexity of design can not be managed over email or simple DropBox drives, with few designers in the corner protecting their latest Sketch file they proudly call — Constellation.