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 operation can improve the 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 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 constantly refer to one location, creating 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 of view but from the broadcasting of 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 gaining back the control necessary for documenting our progress but still keeping ownership of what has been designed, what has been delivered and what impact it makes on the organisation.
Now, we can link our case study findings and research presentation to Jira by using the Figma link while still tinkering with the final bits that need 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 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 in the way that our engineering team see multiple tickets linked together communicates the impact on the delivery.
Replying to a scheduled task in a specific environment is not an opinion or assumption; it's a direction – it’s a reflection of a professional diagnosis and integration to fulfil specific objectives having an impact on the organisation.
Everything that happens in Jira from the design perspective has an impact on the team, on the business, on the development of the organisation and inevitably, on 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 communicate different things about the project.
How long it’s gonna take, what resources we need and how well we will use them in order 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 about the spending because we will understand how much time we have spent on a specific feature and how long it takes for us to deliver it. We can communicate to our development team what changes we are making in design to improve or reduce the functionalities to minimise the time and maximise the impact on a 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?
That all can be achieved by using Jira and Confluence as a source of truth.
Happy scaling through design!
Hey, I’m Jiri Mocicka.
London-based Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to find your feed in teams of 01, 10, and 100, supported by Grid Magazine and Supply section, where we weekly bring more insights on how to become a design leader in your organisation.