Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed Design planning(↘︎Link) and how the basic structure of design operations can improve organisational outcomes and impact the ROI(↘︎Link). This article will look at the practical implementation of our previous Product Design Planning(↘︎Link). Before we dive into the details and changes between protecting and broadcasting, please visit my previous article on this topic so that you get the full context behind broadcasting(↘︎Link).

The only thing — trust. 

Millions of designers around the world are focusing on perfecting their Figma skills. Thousands of tutorials fly through YouTube, Instagram, and LinkedIn, fooling the design community into thinking that being a better resource to the existing or newly established design team is the only way to serve the organisation.

All designers forget one of the most profound aspects of all. Mastering a tool is not the same as mastering a practical application with an impact on the business. Let alone strengthening cross-functional relationships of the design function within the organisation. 

We will not help anyone if our designs are buried in Figma in random folders, files, and undefined layers based on assumptions fed by imaginary KPIs. 

Trust is built on transparency, persistence, and continuing, which leads to the overall belief of design function capabilities within the organisation.

Transparency 

In the previous article(↘︎Link), I mentioned that having ambition(↘︎Link) is not everything. In order to achieve change within the complex development environment, you need knowledge, let alone a knowledge-based space that you can refer to as a common ground for all your subsequent decisions. Promoting and broadcasting such a knowledge base creates a standardised stream of updates that consistently point to one location, building trust across the whole organisation.
It would be like carrying wood in the woods; let’s think of it as a Bible or Quran. This is not from a religious reference point but from the perspective of broadcasting information. Everybody in the organisation goes to the same source of truth and finds the relevant guidance for a very specific situation, such as mental models, information architecture, content models, and so on. 

Speak Data 

I cannot emphasise that enough, but all great knowledge bases started from gathering existing data from the organisation. We then organise them in logic clusters that reflect the organisation structure, allowing all members of the team to find the specific lens on topics like content model, content strategy, content structure, information architecture, mental model, behavioural model, and so on. It’s not rocket science.
It only takes a couple of days (or months) to organise the data and a few weeks to broadcast them. Usually, in less than 90 days, you can own the entire design experience in your organisation by letting anyone access your knowledge base so that it’s fully transparent and well-integrated. For more details, please reach out to Design at Scale™ — Academy(↘︎Link), where we discuss these topics in detail. 

Figma Slides & Jira

This note is more of a practical kind. Over the decades, we have tried to accommodate all the presentations reflecting our product development in Confluence(↘︎Link). Having said that, Confluence has become a dump yard of everyone’s PowerPoint without a naming convention, and it has been increasingly difficult to actually find what you are looking for. 

Confluence has become a dump yard of everyone’s PowerPoint without a naming convention.

With the arrival of Figma slides, we are regaining the control necessary to document our progress while still maintaining ownership of what has been designed, what has been delivered, and the impact it has on the organisation. 

Now, we can link our case study findings and research presentation to Jira using the Figma link while we continue tinkering with the final bits to be presented the following day. Not to mention that the trail of record is still kept only within two environments – creation = Figma and distribution = Atlassian.

One-click away 

This has been such a remarkable improvement in the way we work with our product colleagues. Instead of going back and forth and communicating over a variety of channels about where the presentation is, we can now have the defined task source and presentation – one click away. Hustle-free collaboration with all comments and final adjustments clearly marked in one place. Therefore, our colleagues in the product and engineering teams can use this presentation for any purpose or by any means necessary. 

Having clearly defined roles and tasks in Jira helps us avoid unnecessary comments and miscommunication. The different communication tools reflect more opinion rather than direction. Empowering our colleagues to focus on what matters – to deliver instead of what might be good – is yet another shiny calendar or management tool that is run by AI 😉

Impact

This brings us to the overall impact.
If we document our research in Confluence, we can link to a specific task. That way, our team will see the effort (Story points) and be directly linked to the impact(↘︎Link) that it could make.
Adding the customer experience documentation(↘︎Link) allows us to communicate dependencies on the behaviour and potential changes of solution architecture.
Structuring the user interface and branding delivery so that our engineering team can see multiple tickets linked together communicates the impact on delivery.

Replying to a scheduled task in a specific environment is not an opinion or assumption; it's a direction – a reflection of a professional diagnosis and integration to fulfil specific objectives that impact the organisation. 

Everything that happens in Jira, from a design perspective, has an impact on the team, the business, the organisation's development, and, inevitably, the customer.

Source of Truth

In the same way, we have defined 3x3 knowledgebase in confluence(↘︎Link) the same way we define task environment in Jira(↘︎Link). Look at it as two sides of the same coin – once referring to a source and the other broadcast. 

One is the source of truth, whereas the other is the source of status or priority.   Both convey different aspects of the project. 

How long it’s gonna take, what resources we need, and how well we will use them to deliver specific objectives. Once our work is done, we can monitor our workload and ask for a new designer. We can inform our finance team about spending because we will understand how much time we have spent on a specific feature and how long it takes us to deliver it. We can communicate to our development team the design changes we are making to improve or reduce functionality, to minimise time and maximise impact on the customer. We can clearly reduce the product team communication to only what matters. Do you remember the Agile Manifesto – Individuals and interactions over processes and tools, and working software over comprehensive documentation? 

All of that can be achieved by using Jira and Confluence as the source of truth.