Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed Broadcasting Design(↘︎Link) and how having a centralised source of truth. In order to establish such a foundation, we need to go back to Figma and organise our work into segments. Obviously, by connecting these two environments, we achieve the desired flexibility to not only broadcast our ideas but also to create a valuable proposition.

Why segments
In one of our previous Figma series, I wrote about the structure behind the Figma space(↘︎Link). The segments allow us to link a specific part of the experience to any other place—in our case, Jira and Confluence.
Why is this important?
If your team does not use the advanced Figma versioning, you’ll end up with several versions of one piece of design in one stage. That inevitably causes the obvious confusion to business and development:
– What version of the design am I looking at?
– Which one of these is final?
– Which designs have been signed off?
– Who designed them?
– Who can explain them?
– Who signs them off?
– Who takes the responsibility for the delivery?
– Who will advise my engineering team or me?

Infinite mess
Often, engineers come back to me and ask why we need to see all the versions(↘︎Link). It is not necessarily the fault of design, but often, there is a lack of decision-making in our organisation. Suppose our product colleagues have unclear objectives or acceptance criteria. It is often the opinion or design by a committee that drives the process of creation. That is why we designers are sometimes forced to present more than one final version for development.
On the other hand, some developer prefer to debate the functionality and make their work obviously a bit easier. Conversely, if you have like-for-like development (which is still the case in some organisations), you might end up building something that is not desirable.
At Design at Scale™ – Academy, we teach designers to get the duck in the rows, so to speak and a/ have a clear description of what needs to be built </> and b/ what is here to be debated or archived. That is why the segments are a well-established practice that helps dozens of product teams around the world to distinguish between exploration, brand version and final user journey delivery.

Smaller searchable chunks
If your Figma has 2.3GB with hundreds of versions on one infinite board, it is quite likely that finding specific features will be pretty challenging. That is why we are aligning all our projects into a searchable stage structure, followed by the clearly named segments(↘︎Link). Ideally, we‘ll have the smales in the most dedicated file to a feature and its version instead of one big file.
The advantages are obvious: Searchability
– across Folders
– across Files
– across Stages
– across Segments
– across Layers

Direct links
You might see where we are going with this mental model. If you have one big file, you’ll end up linking the very same file to UXR, CX, UI, Assets and so on. If, however, you have several files neatly organised in the structure that reflects the structure in Figma, Confluence, and Jira – your direct links will represent the direct answer to your specific questions. Let alone it will clearly communicate the status, priority, and associated members of the team, documentation, design and, more importantly, the design artefact in detail(↘︎Link) without further moving, looking, searching, calling, slacking or begging your colleagues on holiday where can you find the latest version.
You can imagine how harmonious this could be. Let’s picture the following scenario for a moment. A startup of 10 people collaborating on a single product or service. To agree on an initial scope, we have PiD on Confluence (+links to segments of research). Then, we do the research and link the FigmaJam and the specific Segment from research that has an impact on Proposition Shaping. Then, we have the tasks in one place (in this case, Jira) and link them to a Figma Files or specific segment that represents the definitions. That way, everything talks together, and it’s not buried in Figma, Slack or Teams.
The beauty of this is the automation that can easily happen because you start from an organised data point.

Design / Task / Documentation
The sequence of the tasks for designers is quite obvious. At Design at Scale™ – Academy, we teach the context and what it means to deliver the product(↘︎Link). You might have some product colleagues advocating that this might not be the role of design function or individual designer. However, we often see that if it’s not done by the designer, it's not done at all.
“If it’s not done by the designer, it's not done at all.”
That is why we believe that the ownership falls on our design colleagues to understand, define, describe, document and broadcast the product changes across the product team. You might be in a team where we have a dominant product or engineering presence. Perhaps your CPO(↘︎Link) designing everything in PowerPoint(↘︎Link) or an engineering colleague has rigour in knowing your customer’s needs or perhaps using a specific framework(↘︎Link).
Either way, segments help you establish a balance between all parties and communicate what is necessary and when it needs to be done. For more information, please do reach out to the Design at Scale™ – Academy(↘︎Link).
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.