JIRA for designers — the basics
When it comes to task or time tracking management tools amongst design professionals, the Jira from Atlassian does not reach its full potential. Let’s face it; it’s not the sexiest tool out there. Yet underneath the quite sophisticated UI is a powerful engine that every designer would ultimately appreciate significantly in the era of constant changes of the remote teams.
“As the tooling is probably the most opinionated topic out there apart from relationships, these series present my own opinion and 20+ years experience of my own (16 of which delivering under the JIRA & Confluence)” — Experience Design Director, Greenwich.
The following articles aim to advocate for better understanding and benefits of using Atlassian’s Jira to track the design deliverables alongside the development team in one place and gain the power of transparency and clarity through the design at scale.
Atlassian History
From the design perspective, Atlassian is a development company that focuses on supporting a broader scale of organisations in software development. Historically, they helped corporations to manage their software development. Until recently, Atlassian strengthened its design function, which improved visual flow and broader integration across small teams and big corporates. Atlassian did exceptionally well by acquiring Slack (which ended up in SalesForce on the end), ThinkTilt and Trello — and many others to become the leading platform that operates in scale.
Landscape
The landscape has changed too. The last 20 years in design operation has evolved so rapidly that no organisation can survive without an effective tool-chain (and operational models) that dictates the responsiveness and flexibility of the product design development (PDD in short). Whether we discuss the startups, small businesses initiatives or corporate integration that run waterfall, Lean, Kanban, Scrum, and the Scrum of scrums, everyone has one purpose in mind — to control overall deliverables.
Unfortunately, the appetite for the control is more significant than an understanding of what the tools can deliver desired outcomes. That leads clearly to an opportunity for the bold statement from a small startup offering sexy tools that solve the challenges around control.
Sexy vs Smart tools
We all tried sexy tools with fantastic features. Youtube is full of tools reviews, and how brilliant are they for our growing team. Yet all these propositions have reached their limits and surfaced the consequences of team and operation at scale.
You name it Asana, Miro, Mural, Forecast, ProductBoard, Monday.com. In most cases, they are integrated with (Google, iCloud, One) or some kind on cloud-drive. Not even mention different email clients and messaging services (Slack, WhatsApp, MS Teams) and many others to follow.
It leads to a communication clutter that no one can untie. That’s why after 60+ trials and errors across the agency and product-based companies that were trying out all the shiny tools, brilliant excel sheets and incredibly complicated design folder structures, I’ve opened up the blue box from Australia and tried the Atlassian package myself. With the one ultimate question in mind:
Can I bring the structure, clarity, transparency and scale to my design work while contributing to my remote development and product team using Atlassian tools (Jira and Confluence)?
To avoid all biases, I went all in. I switched off slack, email, teams (and a dozen different tools inherited from 2000–2008) and focused in a particular direction. Over the last decade; I passed several training sessions, followed the seminars and read the majority of the books that talk about Product Design Delivery and ask:
Where does the design fit?
Historically, the design is a waterfall discipline based on stage and gate delivery where the engineering from the origin is more equipped to be redistributed over delivering the increments. In the last two decades (throughout the research for DaS™), I have carefully observed, interviewed and analysed CPO’s and CSM’s trying to handle the design throughout the delivery.
Simply put, there were only two groups.
Less courage-one eliminated design to a single task without understanding the consequences and requirements of this specific field.
More braver-ones were trying to have the design as a precondition for their HLR’s. Sooner we embraced the BBD over TDD and defined User Journeys from the user perspective; we reached the point of peripheral integration and behaviour integration in product design development.
In 2006 the Human-Computer Interaction — HCI, alongside User-centred Design — UCD, gained their deserved recognition. Somewhere around 2010, we started seeing the user stories written from the customer perspective. And around 2013, we have embraced proper design integration while following Behaviour Driven Development — BDD.
A newly equipped generation of ambitious CPO’s and businesses realised that broader and deeper integration of design with delivery benefits the whole team, if not the entire company. That was where all the service designers came up to the discussion.
Simultaneously, all the above improved the design outcomes. It allowed us to build design systems, design frameworks, and services to help business design and operations in complex environments and cross-functional features. More importantly, it helped us track progress and change in the same domain as the entire development team.
Objectives
Enough of the history — the ambition behind this article is to explain how designers can use JIRA while defining, tracking, delivering, managing, measuring, and finally releasing tangible design outcomes alongside their engineering teammates.
In 2005 Amazon updated its codebase 11.6 sec; by 2015, they get even faster, pushing the code every second — reinventing how they serve their customers in a global landscape. Google runs 500 million tests in one day, all carefully automated, monitored, evaluated and traced to their objectives.
I often ask:
“How many design test you company runs in a year before you move to production code?” — Experience Design Director, Greenwich.
Every project has a team, and the team has certain specifics — for the purpose of the following articles, it will be a team of nine (CPO, CSM, BA, SA, FE, BE, CX, UI, EDIT).
OUTSIDE — The Product Lens:
The team challenges can be described as the following:
- Day to Day Product Delivery Management
- Velocity — Project Tracking
- Time Tracking — (Resource tracking, Billing time)
- Dependencies
- Integration
- Flexibility
- Complexity
- Knowledge base
- All in one place
INSIDE — The Design Lens:
All the above describes the general challenges of the average team, but what is the design lens in these specific scenarios?
- Design system + Design framework
- A navigational and behavioural model
- Information architecture
- Component library
- Copy repository and approval process
- Tone of voice
- Wireframes CX — tracking, updates, approval
- UI design — tracking, updates, approval
- UI specification
- Assets delivery + version management.
- BAU — Business as Usual (supporting functions)
Methods and tools
Big or small teams, they all love Miro board. No one can blame them. It is so visual and shiny and so easy to use. Spending my last two years close to a startup environment allowed me to see how easily inadequate tools can be implemented and have a devastating impact on productivity.
Often I was asked to give a perspective on:
Can we run Design at Scale + Dual-Track Agile with a Miro, Mural board or equivalent online board service — we just love to use it?
Of course, you can — the question here is how much doubt and uncertainty you want to generate for your colleagues and your team. Or how much control you desire over your design delivery while supporting and growing your team.
Better said, the JIRA is an automation machine.
“if this — then that.”
Epics, Stories, Tasks are all interlinked and create a sophisticated ecosystem that helps design to scale.
Historically and quite sadly, design and all design deliverables were driven by none designers. One would argue that if the knowledge does not come from 10,000 hours of practice (or any other fact), the craftsman shouldn’t decide how the discipline shall be executed.
We are living in the era where managers do design, designers write snippets of the code, and our engineers laugh at all of us and dictate the process of how we deliver our daily work — sounds like a lot of fun to me, don’t you think?
The business has their Prince2, MBA’s Stage and gate, most of the designers preaching service design or the double diamond, and we all meet under Agile to be a little less fragile and still work our way up.
Meet the method
Let’s start with the basics. The mindset defined agile, mindset, values and principles — for more info, grab yourself a copy of this article describing the basics.
The critical takeaway and building stones for the Release are Epics, User Stories and Tasks. There are several different ways to group them and arrange them, especially when you design the service or product differently if you design a set of services together. As a designer, you should know:
Release — has been the starting point during which CPO and Design Lead can discuss an amount of work that goes into specific planning. This prevents us from under/overestimating resources and time.
Epic — “is usually described as a large body of work,” in fact, we can look at the epic as a design of specific functionality. For example, Login functionality. Do not misunderstand it for a singular login screen. It is all the design work that goes into login while designing the (Apple, Google, Facebook) UI to login to your brand new APP.
User Story — that leads us to the story that is often described — “as an informal, general explanation of a software feature written from the user perspective.” To break down the log in mentioned above, we need to design several different screens (using components and elements) to fulfil that specific User story.
Task — Within that User story, there are tasks. Historically that’s where all the design tracking happened. Not anymore; let’s see what happens next.
History of design increment
One lousy example: We have designed the app with a button. The complexity of all assigned epics, user stories generated a crossover for our intentions, and three collaborative teams and colleagues generated the workload for fixing the bugs. One of my team members was assigned to fix 76 bugs across 17 tickets and four epics to simply update one specific word. This clearly shows that great intent with a bad chain of command can be counterproductive and absolutely devastating to a poor copywriter.
The challenges around the design increment are still vital to today’s implementation. Design, after all, is a holistic discipline that looks at integration from end to end rather than a singular function perspective.
That’s why we tend to recommend using Kanban for the design delivery–allowing the CPO to track items separately. Equally, it enables the team to work on the increment for more than one day or even one week. This flexibility replaces previously experienced team tensions with flexible and proactive contributions.
Strengthening the unity on the design increment in one place (in this case, JIRA) also allow other team members to visualise their contribution. It inevitably increased collaboration with the development team by more than 20% compared to the supportive or peripheral design team tracking system. In today’s agile world, the design holds its own space and is well recognised as the value generated discipline.
Kanban, Scram or else
It brings us to the question, “how does the designer know what s/he is working on?” I realised that it’s not so much the question of the time or size of the proposition as the mindset that is deployed to monitor and track the task.
Development usually starts from the Time a Resources perspective (grey triangle in the figure above) as the software, programming language and technology is known. The design, on the other hand, looks at the problem statement from a holistic perspective — from an idea to channels and adequate deliverables (red triangle in the figure above). If you recall any of your 1st team meetings, developers usually walk away with 20+ tasks, which can be actioned in the following hour, where designers walked with 100+ questions, where 80% of them were unable to articulate as they lack the context.
To track the process of a Service design and “the NorthStar” stage, I tend to recommend the Kanban. The Kanban is more familiar to the design community, and the adoption curve is pretty smoother.
I’ve equally experimented with an end to end design implementation of Scrum as well. If you are one designer in a big development team, you might want to read the very next article (so stay tuned).
BDD
In the Power of One article, I mentioned the phenomenon of “One Language” and how it can save 30% of your overall communication.
Cucumber it is — while moving from one team to another, I realised the one scrum master used different languages describing the desired behaviour. It’s called Behaviour Driven Development — BDD to one that we called TDD — test-driven development. Ever since I have collaborated with a dozen of BA to define the proposition, we tend to use the BDD. The advantages are the following;
- testing behaviour supports comprehensive proposition and leads to betterment (improvement) of a customer behaviour
- Equally, testing behaviour allows flexibility in development achieved by smaller and precise tests — better outcomes for the end-user
- Finally, it helps strengthen the IP of the product or the company but knowing how and why the user responded in such a specific way.
(for more details, please DM me —I’m writing an article about BDD and PDD 🤭)
Now you are ready
Thank you for reaching this point. We have looked at some history and some past mistakes. We tend to understand the sexy vs intelligent tools. We look at the objectives and how the methods and tools reflect these objectives.
The following articles will cover product design delivery and how to best plan and track — some of the tips and tricks from a broader spectrum of macros. And finally, some learnings from managing the Agile delivery from the design perspective.
Acronyms used in the article
CPO — Certified Product Owner
CSM — Certified Scrum Master
BDD — Behaviour Driven Development
TDD — Test Driven Development
HLR’s — High-Level Requirements.
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, writer, and coach passionate about Design at Scale — an integrated proposition for design professionals in small, medium and large organisations bringing value to the same businesses through transparent and well-integrated product design development.
