Specifically, how do you relate your wireframe/design that may be broken down into multiple Jira Issues? For example, if it takes 20 Jira issues to complete a design (that's the way your development team prefers to break down work).
At first we created separate tickets for designers and linked them to the developers' tasks.
Now we use Zeplin as the "single source of truth" and put a link in the developers' tasks to the corresponding project / sections / screens. I found that as soon as I put screenshots in the tickets themselves, developers would start to only rely on them and not click through to Zeplin. But now that everyone is set up on Zeplin, it works pretty well.
I can easily see all screens for a specific feature and have a clear workflow for updating them. I used to encounter a lot of outdated screens attached to tickets as designs evolved.
Totally agree with this approach. Jira is a pretty poor tool for communicating designs to developers.
I haven't found any combination of Epics, Tasks, Substasks, links, screenshots, etc. that did half as good a job as spending 20 minutes walking developers through a Zeplin project.
Seconded this approach - exactly what the team here at Tandem do. We also do no ever deliver wireframes to developers - we only deliver fully developed, accurate visual designs.
This has also been my experience, but I've also experienced developers feeling like linked wireframes on the Epic level are buried and don't look / guess. However, that is the point of having Epics linked right in each Issue – linking in one place. We also link our Prod. Reqs confluence pages to the Epics.
I use InVision Inspect for specs, but most of our stuff right now is being prototyped within a framework and my current need is more for wireframes / communicating functionality.
I record videos (starting to do more of this again), go over things with the team, and link to wireframes at the epic level/Prod Reqs.
Obviously, if a task can be done with a wireframe (small design/enhancement) that's a quick and easy link in the task.
Was very interested to hear what others are doing! Thanks for all of the replies.
Probably worth noting that I use the new version of Balsamiq Cloud and I love it's rapid features. I can bang out a lot very fast in low fidelity and get dev working ASAP.
One more thing, I'm looking into the plugin where the wireframe can be kept up to date if we decide to link within each Issue!
You can simply link the dev tasks to the wireframe task. Or connect them by the same Epic. It’s really more about the best workflow for the team.
Thanks for your reply! See my comment above.
We try to have consistent, clear, predictable naming for things so developers will know which element we're talking about.
It works well with Zeplin/InVision Inspect (when we name our layers and groups correctly; we use atomic design/modular design/pseudo-BEM).
Also, the QA team is surprisingly talented at quick image editing and sometimes slices things up even further without us knowing haha
Do you use sub-tasks?
I do not, but am always open to suggestions that could improve our process. Thanks for commenting!
- We use LucidChart to define names and visually represent the pages, containers, components, and fields.
- LucidChart is used to create the database schema, process maps, SWIM diagrams etc (using the same naming convention)
- The same names are used in Sketch, with a separate page just for"Components"
- The team stay synched via Zeplin (inVision is used for presenting)
Work in JIRA references the component/container/code, plus links to the relevant LucidChart documents if needed
When communication moves from JIRA to Slack, either the issue/task is referenced by its tag number, or the item in discussion is referenced as ~"page.container.component"
Initial LucidChart naming file...pages contain containers, containers contain components, components display data etc. If someone's lost, they open this file and search Zeplin/Sketch/Jira/Slack to see where its referenced...creation of this doc could no doubt be automated from Sketch...