Atlassian Documentation for Product Design Teams Part 1
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”
— Antoine de Saint-Exupéry
I wrote an article and realised that I created a whole study about the subject. After consulting with trusted colleagues, I have split this giant piece into five different parts. Each one of them focuses on a different part of the same subject.
“How the product teams can speed up their product delivery by focusing on a creation and maintenance of single source of truth while fine-tuning the design operations”
The first article is a gentle introduction to how this design guy ended up working closely with Atlassian products and the impact that this 17-year journey had on design delivery across digital products and services. More importantly, through short stories, we’ll look at a better and more flexible documentation process while building the digital product.
Where it all began
Before we dive into specifics, let’s start at the beginning. Almost two decades ago, I joined Silicon Graphics (SGI) as a designer. It was where I first met JIRA, better said someone assigned me a ticket, and I didn’t know what to do with it.
“Why didn’t he just send an email and tell me what he wants?”
Later in the week, I met Josh, an ex-pat from Chicago living in Central Europe, helping SGI clients maintain all hardware integration across EMEA.
A manifesto that doesn’t include design?
Josh and I sat down, and he told me all about the Agile manifesto and how it all started. He came across as quite passionate; more importantly, he always answered all my well-targeted questions, starting with “in JIRA or Confluence”.
To my surprise, the design was just a subtask that has no real impact on working software —” Working software over comprehensive documentation”. Coming from a technically oriented family; I understood that even design could be a sub-product or task of a bigger picture. No big deal, I thought.
There was something else about Josh’s passion. It was an undivided interest in all the parts that work seamlessly together as a living organism. I wondered how design could be central to it and how design thinking could drive the change within this information ecosystem. I questioned how we could reduce the complexity by answering fundamental questions around flexibility and scale.
Resistance
Unfortunately, my waterfall (creative) brain could not cope with the uncertainty of one single task (an increment). Yet, the idea of an increment sounds like a building block–from abstract to concrete. Doing a load of technical drawings with my old man, I saw this as an opportunity to get to the bottom of things.
Changing our mindset and the way in which we all engage as a team was the first. Whilst speaking to a dozen developers throughout my 20-year career, I always looked to improve working together.
Moving forward, I kept my design consultations in wireframes. That allowed me to respond quickly and without having to bother with design details. When the topic of look and feel came into play, I always had 2–3 versions in my sleeves to call on. This enhanced the entire proposition and made developers more involved. The first success came with presenting a well-organised structure that everyone in the team could understand. Right at that moment, I saw an opportunity to unite everyone under the same umbrella. Unfortunately, the ambition was too bold for that time–it was only 2006.
Pre-Slack, pre-messenger, pre-miro, pre-Asana and pre-WhatsApp, I have started organising documents on Confluence. There were so many of them– the narratives connected to one experience. Having all the information neatly organised in one place increased the transparency and connectivity within any team. Not only that, Confluence has enabled the majority of discussions to happen in one place, which in the end saved us 27% of our time.
Now, I thought it was just a case of spreading the news. There was one simple problem that every junior face–a clash with the authorities. No one understood me, and no one could grasp the power of it. Everyone expects it to magically appear on the serer and inform everyone else in the team. Even after reading several books about Agile, Lean and Waterfall, I came across several different ways to make the project impeccable. Still, I was missing the way how to convince people. Everyone considered me to be a designer who was messing around with Product Owners stuff, the Atlassian and forgetting to concentrate on his job–being the guy who colours the thing.
Over time, the feedback I collected start having a significant impact on the structure. I had to change my approach completely. I looked at different points and objectives, plus how different people could operate within the same framework. It was not really about personal MBA, Stage and Gate, Dual Track Agile, Lean UX or any other method available out there. It was about empowering people through positive contribution and transparency within the same space.
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.
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.
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.
Language
To manage the complexity, we have to first define a language through which we communicate. I won’t talk about multicultural teams (perhaps topic for the next time), yet the language combines Business, Design and Development. The language that represents the idea from the initial concept to final delivery. The language, terminology, abbreviations, acronyms and perhaps a little bit of jargon that make your work faster–is brilliant. Naming conventions were one of the most overlooked parts of the businesses, yet it has up to 25–45% impact on the speed and the quality of product delivery.
One place
With the time we all spend in email and countless meetings, we can instead invest in a “well-written definition”. That’s right; Product definition where we all describe our aspiration, challenges, opportunities and expectation from the business or customer. The fact that our thoughts are expressed in one place (Confluence, for example) reduces the number of emails, documents and presentations as all task-based communication goes to JIRA.
The beauty of it is that everyone contributes to one course, and the progress of demands and dependencies are tracked under one roof. It is pretty essential for all the releases’ business, resourcing, and timing (perhaps for another article about tracking and design efficiency in Agile World).
One Team
80% of our managers have grown on email, and there is no or very little change to convert them up. Let me walk you through an example that shows how one team can deliver quite a different change within one organisation.
The first team has reduced their emails by 60% just by moving all tasks to JIRA, which impact productivity and speed. It also reduced engagement via Skype, WhatsApp, Slack, Zoom, Trello and Asana. Reducing the toolchain, people simply meet, discuss, record and agree (Figure 06: Stage and Gate — do you remember my comment from above?). There was no need for more accounts, APIs, passwords or more communication. No single wasted email or Slack message on “where is the latest document” — instead, only a focused and well-defined proposition.
One Product
That was the first significant proof of seeing a pretty well-balanced work environment with a very professional approach to the past, present and the future. And that’s where it all began. All the readings, theories and “I told you so’s” were right in front of me. I wondered: “is there any way to re-create this environment for all the product teams out there?” This is a simple framework (or method, if you will) that allows the start-up, SME or big business to grab its parts and assemble its version of a product hub where all disciplines meet, discuss and define the next generation of their venture.
A small example; Every sports team (hockey, climbing, cycling) has its internal jargon, training in a specific field, building the team spirit and aiming to win against the competition. Similarly, we can look at the product team, define their language, meet in one location working on team spirit and deliver one product.
— Jiri Mocicka 2014 SKYQ, UK
I hope you enjoyed the first part of this story. I’ll look forward to welcoming you in a week to see how this all continued.
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.
