Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed how behaviour-driven development(↘︎Link) helps designers define user stories better and how we can help our engineering colleagues reduce refactoring and concentrate on quality code development. This article will continue expanding on how Atlassian Jira(↘︎Link) can help us manage the workload between the design and engineering teams.

Time

Undoubtedly, time is the greatest commodity of all. However, it is often wasted on inefficiencies and small things like handoffs and handovers between the different teams. It has been documented and well-researched that organisations with over a thousand employees waste about 40% of the production time in handovers and file allocation instead of creating and refining existing code for design. Production lines at Ford(↘︎Link), Toyota(↘︎Link), Skoda(↘︎Link) car manufacturers, and Bata’s shoe companies have mastered the efficiency of the production line. However, our newly established digital teams focus on the perfection of one IC – individual contributor rather than the ecosystem itself.

Why people don’t care? 

Most of the time, it's a lack of knowledge rather than ignorance. No one really knows who used the file before or after, or when we delivered it. Pick this scenario when we create the design of a page or template reflecting on a specific functionality. Let’s say, in the best scenario, you are presenting to stakeholders and not only throwing over the fence as the majority of agencies do. Once it is delivered to a production line, it’s sliced and diced into the user stories and epics that separate the overall vision to a delivered interaction with the coexistence of the field, scroll, image and a bit of transition. This way, our engineering colleagues go back and forth and take the pieces of our work and literally replicate them in a code without any strategy(↘︎Link), transparency(↘︎Link) or intended behaviour change in mind. We have 100+ opinions about how it fits a specific product owner and their team rather than thinking about optimising the trajectory of a shared customer vision that is beneficial to the business.

Transparency (in Jira)

Transparency in the business is one of the greatest advantages of any product team in your organisation. You can have the greatest Figma(↘︎Link) operator in the world, yet if you do not have the interaction, your entire ambition(↘︎Link) crumbles on how the Scrum Master(↘︎Link) translates your design to your engineering colleague. To my surprise, everyone talks about automation and AI, yet the delivery line is still full of emails and JPGs that fly back and forth between account representatives, clients and product design teams.
I suppose it’s still an old-fashioned way.

Let me introduce the new way forward. Our designs are separate in the feature Figma files and link to Jira with supporting documentation reflecting on HLRs(↘︎Link) and UACs(↘︎Link). This is why when the engineering colleague receives the ticket, they have complete documentation at the end of their fingertips.
Regardless of how many people need to approve it and sign off, the engineering lead knows exactly what is in the play and how to play it.

As previously described in the BDD article(↘︎Link), the story defines the output and measurable outcome. Jira ticket, therefore, summarises the following:

– Definition of the user story
– Acceptance criteria
– Link to a Figma file
– Link to a conference page
– Link to a design system page  with a corresponding design component
– Time allocated  for the task
– Testing environment

Accountability 

This brings us back to the designer and her/his accountability. The delivery is often rushed for fear of having more options to decide from instead of delivering a quality proposition(↘︎Link). Therefore, actual requirements are often missed (or misled) or simply not delivered. That way, we do not communicate the basics like UACs(↘︎Link), FR(↘︎Link) and NFRs(↘︎Link) to our engineering colleagues in written form.

The creation of the design is cheap! 

– Name of an investor 

It is the designer’s accountability and experience that need to be documented and tested in order to understand the hypotheses and the impact on the customer.
Hold on – designer’s responsibility, you say?
Yes, not because you are a talented, creative and well-educated individual the world knows. But because you are accountable for being the most knowledgeable person in the team about the experience and how this behaviour is executed in product design delivery. To put it simply, there are two sides to the coin – that is, the product team. One slide is the Product Owner facing up to stakeholders and the CX Lead or Director facing down to production and delivery. Opinions aside, you are partners – like a brother and sister, literally. 

Belonging

The best operating teams usually work very close together. Defining the preposition from the green sheet of paper to a final delivery. Regardless of whether your team is in one office or distributed across multiple continents belonging to the team, having a voice is one of the most fundamental parts of a handover. It's not because of a proposition but, more importantly, because of the relationship between the different functions, including the chain–business, design and development. Helping designers to belong in the definition of the strategy allows business to strengthen their original strategy and tie all physical designs to a business outcome. On the other hand, tying closely to design and development allows you to minimise the refactoring that often delays delivery by at least 40%. As mentioned above, you are driving the delivery, and therefore, you need to belong in all (discussions) decisions that are necessary for the handover.  

Design Repo (Figma)

The majority of the design team has now chosen Figma as a design repository. Unfortunately, we are still seeing development teams that are incapable of locating, translating and developing the propositions just out of the simple Figma file. It would be fairly naive to believe that without a proper introduction, the design repository is understood. Especially if the length of the project is beyond one year and the agency or the design delivery house hires and fires freelancers who often change the way they organise the file and how they communicate the change to the engineering team. 

In many respects, having a separate repository that unifies the two sides of the same coin of product design development allows flexibility in design creation and creates a standardised way of consuming design files in a defined way.

In one of our latest integrations, we have shared a full structure with our engineering team on GitHub and deployed the image icons as vgs and so on into the repository directly from Figma.

Jira & Figma

Jira plugin for Figam and Figma plugin for Jira makes the life of handover easier. Personally, I only use Jira-comments in Figma. That way, I keep the one source of truth. Later, we can have the allocation meeting reflecting the number of tasks, their complexity, priority and dependencies in the space that is designed to make these product-related decisions. Finally, if any new designer arrives in our design field, they will know that we are commenting in Jira, as there are no Figma comments. That way, we minimise the noise and restore clarity across all our interlinked projects. 

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.