A more holistic design workflow: gluing Jira, Figma, and Zeplin together
How to organize an effective design process from planning tasks in Jira, organizing files, to handing over to development
Whether you are making coffee or painting a picture, the order of actions can be determined. In my opinion, it is the presence of a clear process that distinguishes a professional from a beginner: a professional knows exactly what to do (and in what order) to get the desired result, while a beginner is still learning and trying to understand it.
Working in different IT companies, I often heard that designers are not good at organizing their work and in general, do not know how to follow the process. This is partly true because many novice designers argue the necessity of “creative freedom” and work in some sort of “creative chaos”. However, in my opinion, this may be because unlike developers (who most often use Scrum or similar Agile frameworks) designers do not have standard documented work processes.
In this article, I’m describing a model that is based on personal experience and it does not claim to be universal. In addition, in the examples, I use a specific set of tools and methodologies:
- Jira + Scrumban
- Figma
- Zeplin
However, the model can be adapted to other systems, as well.
Processes are designed to accomplish specific tasks
Processes are usually introduced to optimize work, improve performance, or solve problems. The design process doesn’t happen in isolation and you need to cooperate with different people at one stage or another:
- Other designers. Ask for help (or, conversely, help others), and sync solutions (if there is overlap). The most critical is handing off the project to another designer (so that the other person can continue to work on it).
- Managers. Project managers or Design managers.
- Developers. Those who will be implementing the designs.
There may be other stakeholders (researchers, copywriters, analysts, and others). However, the 3 groups (plus the core designer-contributor) outlined above are the main ones.
Each group has its own set of requirements (some requirements may overlap) and they may be different at different stages of the project.
From my experience, all requirements can be roughly grouped into 3 areas:
- Task management
- File management
- Handover to development
Task management
Existing solutions
Usually, when it comes to choosing a solution we start by looking for a suitable application or service. Today, you can find a lot of different offers on the market. I have experience with:
To some extent, Google code (once used by many people as a task manager) and GitHub can be referred to as such systems. Although they can hardly be called full-fledged solutions for project/task management. In general, the choice depends entirely on the team’s preferences or company policy.
More important is the choice of methodology/framework for project management: since most of the existing apps/services are based on one or another methodology/framework, to choose the right tool we need first decide on the methodology.
The most common frameworks today are Kanban and Scrum. In both cases, the project is broken down into small parts and stages.
Kanban is ideal for teams that perform homogeneous processes. For example, production (in a factory, from where this methodology originally came from) and support. This methodological approach can also be successfully applied by experienced software developers who can work in a variable environment. Kanban provides teams with a significant degree of freedom.
However, Kanban can be less effective for cross-team collaboration. It is also not well suited for projects with clear deadlines and high uncertainty in requirements.
Scrum offers a highly structured approach to project management. The system provides greater flexibility and adaptability, allowing you to take on any project, even those that may change over time. In addition, Scrum brings together team members from different departments and facilitates effective cross-functional collaboration based on individual efforts. Scrum is also focused on continuous improvement.
Scrum’s systematic nature is also noted by many as a disadvantage. Scrum requires training and adherence to rules: to implement Scrum effectively, the team must strictly adhere to rules and roles, which can take time and effort. It also involves changing the culture and processes of the team.
There is also a hybrid method — Scrumban. This is a great choice for teams that find Scrum too rigid but Kanban too flexible. Scrumban combines:
- Scrum methodology for planning, prioritizing, and distributing work
- the flexibility and simplicity of Kanban
Scrumban allows you to adhere to Scrum requirements for sprints, or choose Kanban rules to manage the amount of work. Scrumban is suitable for agile teams that are just starting their journey in agile methodologies. Scrumban was created to show an alternative to Scrum, as some teams find that common rules and processes slow them down.
Requirements
Task management can be broken down into 2 additional levels:
- Management of a specific task
- Task flow management
Each product and each team working on it has its specifics. However, in my opinion, we can list several basic requirements:
Managing a specific task
- Know what needs to be done
Groups: managers, designer-contributor
Need to clearly understand what the essence of a particular task is. - Know who is doing what
Groups: managers, designer-contributor
If there is a task, you need to know who is responsible for its execution. For example, a manager needs to know what each team member is doing. To know that everyone is doing something (and what kind of thing). - Know all related tasks, files, etc.
Groups: managers, designer-contributor, other designers
In the simplest case, all the details of the task can be included in the description of the task itself. However, there are often many other assets related to the task that may be stored (and updated) on other resources. To be able to take all the details into account, it is necessary to have access to all the materials relevant to the task. This can be critical when work on a project moves from one designer to another. - Be aware of all related discussions
Groups: managers, designer-contributor, other designers, developers
In today’s day and age, when there are so many communication channels (email, Slack, Google Docs, etc.) all critical decisions must be documented in one place and somehow linked to the task.
Task flow management
- Workload management and avoiding overwork
Groups: managers, designer-contributor
For a manager, it is important to plan the workload. To know that everyone has enough work to do (to avoid downtime), but also to avoid overwork. This is not only a concern for the team, but also for efficiency. For a designer, it is important to avoid overload above all else. I have often encountered that designers are overloaded with work by managers and demand unrealistic deadlines from them. Such situations lead to stress and often result in the designer leaving the team or the company altogether. - Understand what are the priorities
Groups: managers, designer-contributor
What should go first and what should be ready as soon as possible. - Be clear about when a particular task will be done
Groups: Managers
It is important for a manager that all tasks are completed on time. With a large number of tasks and different priorities, it is not always possible to predict exactly when a particular task will be done. However, sometimes a rough forecast is enough. - Understand what is coming next
Groups: managers, designer-contributor
Primarily, this is needed for context and better planning.
The requirements for a project management system may vary depending on the chosen framework. In the proposed model I will consider the combination of Jira + Scrumban, as this combination solves all the needs mentioned above. However, this model can also be adapted to other systems.
How all this works in Jira
At first glance (and probably at second and third glance as well 😅), Jira looks a bit uncomfortable and a bit cluttered. However, it is easy to get used to it when working with it every day. All it takes is a little time and you will need someone who can help with onboarding.
An individual task in Jira is presented as follows (might vary on Jira version and configuration):
The example above shows how Jira displays the basic information about the task. Since Jira is a flexible system, the field set and format may differ slightly in your case.
When new tasks are created, they go into the Backlog. In Jira terminology we create Tickets and they can be of several types:
- Task — something very simple, like changing an icon
- Story — something that can be formulated as a user story
- Epic — combining multiple related tasks and stories.
You can also define your own types.
The Backlog is a list of tasks for the future. Depending on the settings, tasks in it can be sorted by time of addition, priority, or manually.
Work tasks are selected from the Backlog. The way of selecting tasks depends on the chosen methodology. For example, in pure Kanban, the next task in the queue is always selected. When working in product teams, it is recommended to use sprint cycles, as it allows you to achieve better planning and focus, and avoid rework. In this case, the selection of tasks that will go into work (in the next sprint) takes place at a special meeting — planning.
The selected tasks get into a special list — the Sprint. If you want, you can create several sprints at once to plan several cycles in a row.
Planning also allows you to adjust the workload. Both for the whole team and individually for each member.
You can estimate the amount of work in different ways. The most common method is to use Story points.
Story points are units of measurement used in Agile methodologies, to assess the relative effort or complexity of tasks. Typically, a task is assessed by the whole team: during sprint planning, the development team collectively estimates story points for each task. This can be done using different instruments. For example, you can use Planning Poker: each team member provides an estimate based on their understanding of the complexity of the task by using a special “card”.
At some level of abstraction, it is possible to tie the complexity of a task to time. Although it is recommended to avoid this, for beginners it can make understanding of the processes much easier.
Story points are often assigned using the Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13, 21) to represent increasing levels of effort. The Fibonacci sequence is used to emphasize uncertainty and variability when evaluating larger and more complex tasks. After all, the more complex the task, the more difficult it is to estimate exactly how much effort and time it will take. For example, if you are going to estimate the task “make a cup of coffee”, you will most likely be talking about minutes. In the task “to help a friend move things to a new apartment” the estimate will be in hours, and minutes will not be so important.
The actual work is being done on tasks that are in active Sprint.
In Jira, a Sprint is represented as a Kanban board, where tasks are displayed as cards going through the different stages of the production process:
- Todo
- In Progress
- Review
- Done
The set of stages may vary from project to project. The cards move by columns, representing the current status of work on the task. For example, a task starts its journey with the “Todo” column, then moves to “In Progress”, then to “Review” and finally to “Done”.
It all looks pretty clear. However, Kanban uses different practices to make the process effective. The Kanban board covers the first of the 6 basic practices of the Kanban method:
- Visualize the flow of work
- Limit WIP (Work in Progress)
- Manage Flow
- Make Process Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally
The first 2 practices are quite simple.
1. Visualize the flow of work
A high-level view of work items to understand status and progress. A progress board. For very simple projects where continuous iterative work is not required and there are no hard deadlines, a simple Kanban board can be sufficient.
2. Limit WIP (Work in Progress)
By limiting the amount of work per person (task size and number of tasks) and focusing on completion, Kanban allows for an efficient flow of tasks.
Practices 3 and beyond require analytics.
3. Manage Flow
Kanban offers various methods of optimizing the flow of tasks and identifying bottlenecks. It all depends on the project and team.
4. Make Process Policies Explicit
According to the principles of Lean project management, quality should be embedded in the process and not checked later. This requires determining each type of task. Which, often in product development is very difficult.
5. Implement Feedback Loops
One example of implementing feedback loops in practice is the daily Kanban team meetings. These meetings allow you to discuss features, and reports, or raise any issues.
6. Improve collaboratively
Continuous, sustainable improvement requires team collaboration. For example, you can use a throughput report to track how many Kanban cards the team completes in a given period. This data will help you better understand your current capacity and whether to adjust what you commit to.
If 6 practices look too complicated — you can start with the first 2 (1 & 2), and the last 2 (5 & 6). The last 2 (Feedback Loops & Improve collaboratively) will allow you to gradually understand the processes and incorporate the remaining 2 (3 & 4).
File management
Requirements
The way you organize your files depends on the application you are using. Although all design tools in recent years have begun to focus on cloud storage (largely due to the popularization of this format by Figma), each company offers its own approach to file organization. The basic principles in most solutions are more or less the same.
As I have already mentioned above, different teams may have their own specifics. However, as in the case of Task management, we can list some typical requirements:
- Know the status of the work in the file
Groups: managers, designer-contributor, other designers, developers
As with Task Management, when working with files, you need to understand the status of the work in them. - Clean space for all live/actual/production designs
Groups: managers, designer-contributor, other designers, developers
This point is often missed. After all, you can always “see the actual project live”. However, it is often important to know what all possible states look like. It is not always possible to reproduce this on a real product. In addition, such a “snapshot” allows you to better analyze and plan changes. - Dedicated space for Experiments, Archived, etc.
Groups: designer-contributor, other designers
An archive allows you to store all your old ideas. You never know when an old draft might come in handy. The archive of previous designs also allows you to see how the product has changed and what ideas have been abandoned. - Who is working (owner) on the file
Groups: managers, other designers
If there is a file, you need to understand who created it and who is working on it. In the case of a shared library, it is not so important who is the main owner, but when it comes to a working file for a specific project/task you need to know who is responsible for it. To know who to ask for details.
When using project management systems it is necessary to:
- Reflect working process (Scrum, Jira, etc.)
Groups: managers, designer-contributor, other designers, developers
You need to know which Jira ticket (for example) this file belongs to. - Start date
Groups: managers, other designers
This data is mostly needed for analytics and retrospective purposes. For example, if a project was postponed due to a change of priorities. When you come back to it again, it can be useful to know when you worked on it last time.
If designers work in different teams in addition to all the above, it will be necessary to separate or at least visually identify files belonging to different teams or parts of the project.
File covers
Figma was one of the first design applications to combine a graphics package with a file management system. Among other things, Figma has a very convenient feature — you can make individual covers for files.
In the community, you can find a lot of ready examples of covers: templates and components and whole tutorials.
For me personally, what matters in a cover is how it works: on its own and in combination with Task management. The various “fancy visuals” can be a nice addition, but you can easily do without them.
For some years I have been using more or less the same simple cover format:
The logic is simple — for each new task (or story in Jira terminology) a new Figma file is created. And, it is linked to its corresponding Jira ticket:
- A link to the Figma file is added to Jira.
- In Figma, the ID of the Jira ticket is specified on the cover and linked back to Jira.
With this approach, it is possible to find the details of the work in Jira for each file.
The Status label on the cover does a bit more than just reflect the status of the corresponding Jira story. Often happens that when working on a design project, additional stages are necessary: testing or additional research. Or it turns out that for the time being is being postponed. In such situations, of course, you can create a separate file for each stage. However, the type of work can be reflected in the cover via the status.
When the design is approved (by the Manager or Product owner) it is also important to reflect this in the cover.
Then, when all changes are reflected in the end product we copy the screens to the Master/Production file (add new screens or update existing ones).
After all, the working file itself will be sent to the archive.
Since Figma has some sort of folder system, we can use it to organize the files themselves according to their status in addition to the covers in corresponding Figma projects/folders:
- Master / Production
Clean space for all live/actual/production design files - In progress
Dedicated space for work-in-progress files - Archive
Archived or deprioritized files and topics
In addition, it might be useful to have additional folders:
- Resources
Documentations, competitors overview, etc. - Experiments
Experimentations and “out of the blue” projects - FigJam
Discussions, workshops, etc.
Handover
Requirements
Moving to Handover, first of all, as before, I will outline the basic requirements. Again, I come from my personal experience as a developer. Plus years of collaboration with other engineers, designers, and managers.
Core
- Know what is final and can go into implementation
Groups: managers, developers
Often even after a green flag is given, the last, final, final edits are made. It is important not to confuse the developer and make it clear what should go into the code. - See all the screens for a particular task
Groups: managers, developers
Usually, after the project is finalized by design, it is divided into several small tasks for developers. In such a case is necessary to know which layouts belong to each specific task. This is especially important when the design might look different in some of the iterations. - Have always up-to-date screens/links
Groups: managers, developers
For developers (and managers) the starting point of any task is a ticket in Jira (or other project management system). Accordingly, all links to a task should be stored there. The link must always lead to the latest approved version of the layout (or the one that relates to a particular iteration), no matter how often it has been modified. - Know what has changed in the design
Groups: developers
Changes might be cosmetic and hard to see on the layout. Listing everything manually is also not efficient, as you may miss something. So we need to have something that will highlight all the changes. - It should be simple to use
Groups: developers, managers, designer-executive
Each tool requires getting used to. However, it must be easy to use on a day-to-day basis. - Know what components/tokens are used and where
Groups: developers
If you are using a design system, developers need to understand what components/tokens are used and where.
In addition to the basic requirements, there may be some minor ones. Things you can live without, but things that can make your work easier.
- A simple search for screens
Groups: developers, managers, and other designers.
Search for screens by name, task, and status (approved, archived, etc.). - Know what task/feature is related to a screen
Groups: developers, managers, other designers
This is basically about context: why this or that feature was added to the product. - Know who updated the screen last time
Groups: developers, managers, other designers
Know who is responsible for the edits.
Figma
Quite often, on this step, designers simply send a link to a specific layout/file in the hope that this will be enough. With a certain level of trust and good internal organization of Figma files, this can work. However, it often turns into a headache for developers
Recently Figma has made a big update to its product, and in addition to variables, and new prototyping tools, it has introduced a new special mode for Handover — Dev Mode. This is a big shift toward developers.
However, the core focus still stays primarily on designers. And from the developer’s point of view, this is strongly felt in terms of satisfaction.
In my opinion, Handover is primarily about developers: to do everything possible to make it convenient and easy for them to understand what they need to do (and how). Today several solutions on the market specialize in this. One of the leaders is Zeplin.
Work with Zeplin
If you’re interested in the key differences between Figma Dev mode and Zeplin I recommend watching a good video comparison from UX Tools.
Let’s look at how Handover works with Zeplin and what solutions this product offers for the requirements, listed above.
Connection with Zeplin
For a designer, interaction with Zeplin starts with a plugin: select a layout (or several), specify a project, and export. The process is similar when exporting components and styles: in this case, Zeplin exports everything to the Style guide.
For the manager, everything starts in Jira. So we need to link all corresponding layouts to Jira. This is also implemented via a special “Zeplin for Jira” plug-in extension.
With both plugins, the work is very simple, and both of them support search.
The key feature is that Zeplin keeps the same link for the same mock no matter from where the design was updated. If you export a layout from Figma with the same frame name but from different places (a copy of the layout in the same file or even in a different one), the link to it in Jira will not change. No matter how many versions of the layout the designer has if exported to Jira correctly, it will always be the latest version.
This is very important because in Figma each element (screen, text block, or icon) has its unique ID. Accordingly, if you just give the developer a link to the layout in Figma, it will be different for different copies of the layout. I.e. if a designer is used to making changes to the layout in a copy (or in another file in general), it will be necessary to make sure that the developer has the latest link.
You can link to the current version of the layout or a specific version of it. And when we add a link to a Jira ticket, we tag that relationship in Zeplin as well.
This approach saves the developer from the need to search for designs because everything that is needed for each specific task will be listed in Jira and available via a dedicated link.
If we separate the work and keep only the latest designs in Zeplin, we don’t need to think about how to mark the approved ones. Each layout will always have a link back to all the Jira tickets it is associated with. However, if you still need to export not only approved layouts but also drafts to Zeplin, you can use additional tools such as “Approved” tags.
Versions
In case if. some developer needs the previous design of a screen in the developer task (for example, if the recent changes in the design reflect already the next iteration), you can link to a specific version of the layout in the version history:
Each version can have a description.
Variants
If you need to show the developer different variants of the same screen (for different screen sizes, for example) — you can use variants: combine all variants of one screen and accompany them with a convenient menu switch:
Specs
This is the most important part. And Zeplin, from my perspective, offers the best solutions on the market when it comes to viewing design specs:
- The tool automatically generates resources including measurements, assets, and code snippets tailored to the platform's needs.
- It shows which components are used in the layout and where. When you highlight a component on a screen, you can also find out in which other screens it is used.
- You can highlight all changes in the layout.
and much more…
Style guide
This is a special one. There is even a separate place for it in the tool.
This is a place where Zeplin lists all components and styles used in the designs that were uploaded to the tool. You can upload all components and styles right from your Figma design library to the Style guide so then have a clear overview of what is available in one place together with all the mocks. This is very important when using a design system.
Conclusion
In the proposed model, besides Figma (Sketch or other design application) it is required to use 2 additional tools. The main reason is to find the best solution for 3 main blocks in the design process and optimization for the main user:
- Task management — the manager (design manager or PM).
- File management — the designer (main contributor or other designers).
- Handover — the developer.
Some designers try to simplify their lives and do everything in one tool (in Figma, for example). With the arrival of Dev Mode in Figma handover has become much more convenient. However, the task of a design application is first of all to create designs. Other functions are only secondary (or even, tertiary). Therefore, if maximum efficiency (in terms of convenience and functionality) is required, it is still desirable to use for Task management and Handover those tools that have always been designed for this purpose.
This article is in no way intended to be an ultimate guide. Rather, it is a set of practical tips. And I will be glad if you will find these tips helpful.
Thanks for reading! Let’s stay in touch! Connect with me on LinkedIn and follow me on Dribbble and here on Medium for more design-related content.
