INSIGHTS How to connect Zeplin with Jira

If you are working with Jira and Zeplin, you should read this!

At ABOUT YOU we work with Jira through almost all departments. But as a graphic-working team we need other tools to have a better connection between our UX, UI team and the development teams. We chose Zeplin for working closely with stakeholders, designers, UX conceptioners and frontend developers together. Zeplin combines some features which are optimizing our work process, presentations, feedback rounds and is exporting code snippets and assets. Using the comment feature on the layout for example is way better, then explaining in Jira which button has to change how or which whitespace we need to decrease.

But: the sorting of layouts in zeplin is a mess. Yes, they gave us the feature “sections” a couple of months ago to combine screens in one area — what makes everything a little bit better. But if you have a very complex ecommerce product this won’t help you at all. We have an output of over 80 changing and new layouts a day. And we need a possibility to distinguish between pages and their features. And we have to care about different breakpoints as well.

There is also a complexity in choosing the right communication channel. As I mentioned before: The comments in zeplin should be the desired channel for feedback in layouts. But what about the status? Informations like deadlines, blockers, priority: These infos should still belong to the the Jira board to ensure the transparency in a jira-working company.

And how should you link Jira tickets to Zeplin files and the other way around? We can’t link to sections only to files which is often confusing. To put 25 links in one ticket doesn’t make sense at all.

Tried so hard …

In the first step we tried to clean up the whole overview with using sections for pages and maintain the layouts with tags. We used tags for the ticket numbers of Zeplin and to differentiate the breakpoints. For the first 20 tickets it was actually a good idea. But then… ehm… see for yourself:

Also there have been a lot misunderstandings when a design is ready. So we used a final tag for every screen that was final. … Until we corrected the first final screen and everybody was confused. (Yeah, ok… we should have known…)

Second Approach: Collecting the Needs

After we left a big mess in our tool, we sticked our heads together again and started from scratch. Every designer, project manager and UX conceptioner was making his own notes which we clustered together and discussed as a team.

We found out that:

• We have to stop using tags
• We should stop to upload everything in Jira and Zeplin and should have one single point of truth instead
• We need some kind of link to the files from Jira to Zeplin and back
• We should separate somehow the sections into smaller sections so that we can differentiate pages and features
• We should only use Zeplin for layout-referred discussions and Jira for status-related comments
• We want to present everything in Zeplin (because giving feedback and viewing previous versions is easier)

Finding Solutions

We created a ‘Cluster Tile’ that separates our layouts in a section. For example: A section would be a collection of layouts of a whole page (like a category page) and a Cluster Tile would be just a feature of this page (like the category tree).

This tile has the same name like the ticket number is black — so we can easily find a new subsection and displays the summary of the ticket as a big white headline. This tile is also mentioned as a hyperlink in the ticket, so it’s easy to find the ticket of the section. This allows us to keep Jira and Zeplin connected by having a kind of good overview in Zeplin.

1. Ticket comes into the board
2. We create the “Cluster Tile” named like the ticket and link it in the ticket
3. We make sure that the tile is in the right place and the right section
4. We start designing
5. We export everything we design in Zeplin and put these layouts right after the cluster tile
6. We present everything in Zeplin by going through the tickets sorted by status and priority and open the linked Zeplin files.
7. We collect all the feedback as Zeplin comments
8. If the job is done, we check all links again, adapt the breakpoints (we use tags in zeplin only for differentiate the breakpoints) and upload the final version into the ticket (so this is complete as well)

It’s our best approach so far to work with these tools until the Zeplin guys are giving us the folder feature and we are sure that this will help us out in this time. Hope that helps somebody out there, too.