Jira

Jira for designer

Things to do

1. Capability to do UX review BEFORE code review. Review first if the right thing was build, THEN if the thing was build right. Developers should be able to send a feature branch link as easily as you can send a Figma link to them - making it two way discussion. In Jira (and definition of done document) this can be two states or just single 'in review' state, and the ticket type defines if the UX review will be done.

2. Do a handoff/questions meeting before starting any design task. Typicaly this is some grooming step in which ticket moves from 'backlog' to 'ready to be started'. Essentially developers need to review and ask all the questions. Sometimes i've called this 'to be specified' state, or 'in design' phase .This phase can be applicable to technical design too - some back-end feature need some architectural though too, so the name you choose for planning / specification can be used for other type of tickets too.

3. In Jira, you can have multiple views/boards for the same project, or you can have several projects in same board. E.g. if you have two projects, and a design system project, you can filter all the design tickets from those three projects into one design team board, but still have design tickets in project boards.

4. Use a label/module 'design' for 'pure' design tasks in those projects. Then you can use that label / module to set up filters to show those tickets only. I would NOT use swimlanes for this - it is far better to organize per value stream. Eg. swimlane for seller experience, another swimlane for buyer experience, third for internal process dev. At all cost, avoid splitting single value-producing ticket into three tickets in three swimlines : feature X design, feature X backend, feature X front-end. That feature should be a single value-creating ticket, with subtasks.

Kanban columns / ticket states

What i typically have is that WORK columns have WIP limit, and backlog columns store work that is ready to be started in next column. The key is to avoid cases where a thing is in one column, but not ready to be moved in next column! Sometimes i've less, sometimes more.

1. Ideas (might do)

2. Next - ready for grooming&design

3. In Design&Grooming

4. Ready for development

5. In development

6. Ready for review - Ready for UX and/or code review

7. In review (being code / ux reviewed). Code or UX reviewers handle this by assinging ticket to persons needed, and sometimes moving back and forth between 5-7.

8. Accepted (Merged to master branch) - ready to be demoed

9. In production / Done

10. (for A/B testing) - WON / LOST columns depending if the feature was a success or not. Did it bring the intended value?