Mastering DesignOps: What your UX Jira Workflow says About your Organization
So you are running your UX process on Jira or similar agile tracker. How do you organize for maximum productivity, effortless tracking, and minimum confusion? Sit down, pull up a chair, and take 5 minutes out of your busy day to listen to a tale of two companies: Waterfall Co. and Agile, Inc. and decide for yourself.
Waterfall Co. organizes their Jira status as follows:
- UX Review
- Team Approval
- User Testing
Which results in two possible “Done” outcomes:
- Future Release
“New” tickets are created and placed in the Backlog. Then the “Design” phase happens, followed by the “UX Review.” If the project passes that phase, the project lead presents to the team for approval. Once the team approves, it can be shown to customers for feedback during the “User Testing” phase. At which point, the ticket can go back to “Design” or get validated for release (“Done”) or kicked to some future date as “Future Release.”
Is there anything wrong with this? Well, as always, it depends. If your process looks similar to Waterfall Co.’s and it’s working well for you, you can, as the saying goes, stop reading now and grab yourself a beer. But, as you have read this far, I assume that not all is well in your world and that you feel this can be improved. Well, I’ll be happy to tell you how, but given that this is a Masterclass Series, I ask if you could but indulge me in a small quiz below.
This Jira setup is sub-par because (pick all that apply):
A) There is no clear hand-off from one phase to the next
B) Most tickets would likely move through the process (Design->Review->Approve->Test) multiple times
C) The presence of two possible outcomes implies two different processes forced together
D) User Testing happens too late in the process
E) “New” is a lousy status name
F) The process is missing a “Visual Design” step
Take a moment and mark all that apply. Go ahead. I’ll wait.
If you picked items A, B, and C — you win the prize! The process, as written, is not wrong, per se — it’s a decent process. It is, in fact, the heart of RITE (Rapid Iterative Testing and Evaluation). The issue comes from separating a microcosm of a UX process into unnecessary mini-steps, thereby losing sight of the whole point of employing UX to improve project outcomes. The process, as written, will likely have to be repeated 2–3 times before a successful design can emerge. Agile best practices dictate that each Sprint’s process is gone through only once as a matter of routine, and contains a clear transition to the next step. With the process as shown, there isn’t a clear hand-off boundary between these steps, which can cycle through the Design->Review->Approve->Test cycle multiple times per day!
Two possible “Done” outcomes are likewise problematic: we typically want a single ideal “happy path” through the process leading to a single reliable result. (There are exceptions, of course, but there is no need to create exceptions as a matter of routine. ) Having two possible outcomes makes it hard to track the team’s velocity and size the projects appropriately, which will impede your organization’s ability to plan and execute.
“Future Release” projects typically contain more speculative designs aimed at presenting the strategic vision at a conference or analyst presentation. In contrast, “Immediate Release” projects include a thorough definition of the design, aimed at building the functionality into the product. By failing to differentiate these two types of tasks until the last step, Waterfall Co. invites confusion and puts the team at cross-purposes as to the desired successful outcome of the UX effort.
In contrast to Waterfall Co., Agile, Inc. has two types of UX Design tickets which share similar basic process steps but target slightly different outcomes:
1. Tactical UX Ticket (for dev implementation in 1–3 Sprints):
- Use Cases
- Initial Prototype
- RITE (Rapid Iterative Testing and Evaluation)
- Final Team Approval
2. Vision UX Ticket (speculative, for dev implementation in 1–2 Quarters to Never):
- Use Cases
- Initial Prototype
- RITE (Rapid Iterative Testing and Evaluation)
- Final Team Approval
Both types of tickets start their life in the “Backlog” status. Then the team works cross-functionally to help define use cases, led by the Product Manager. It’s important to note that even if use cases are not completely clear (which occurs quite often in practice), the team agrees on their best guess for use cases. This phase is considered complete when the critical use cases are written in agile parlance “as a customer C, I want to do X so that I can get the benefit Y,” after which the UX moves forward to create the “Initial Prototype.” This phase is complete when the initial prototype crate such that the intended user can complete the task specified in the use case. The fidelity of the prototype need not be high: in fact, it’s the best practice that the fidelity reflects the stage of the prototype. For the initial prototype, this means “the lowest possible fidelity to be able to run through the use case.”
After the initial prototype is complete, the ticket moves into the “RITE” phase, where it spends the majority of the time getting polished in the crucible of customer testing, development feedback, ideation, and re-testing. Depending on the timeline and availability of participants, the RITE phase consists of 2–3 iterations, with 2–3 participants each. It’s not uncommon to have multiple quick revisions of the design in a single day based on customer and development team feedback. The cross-functional nature of this effort cannot be overstated: this is where the best of brainstorming, user testing, and development smarts come together to create the best possible solution that can be produced in the allotted time and budget.
Once the users can complete the task without adding any constructive feedback that can be implemented without going over the budget, the ticket moves to the “Final Team Approval.” After the team grants their approval (which should be just a formality at this point if this team has been involved in regular discussion about the results of the testing), the ticket moves into the “Done” state, ready for implementation (or, in the case of Vision ticket, for a conference presentation or analyst discussion).
Occasionally there is another ticket that can be assigned for the additional icons colors, logos, or custom visuals that need to be developed by the Visual Design team. Most of the UX tickets are routine, however, and will just make use of the existing patterns in the organization’s Design System.
Agile, Inc.’s Jira workflow is a better approach because it:
1) Leverages cross-functional design process in a modern enterprise
Most of the design in today’s enterprise is cross-functional: from selecting the use-cases to RITE testing, the Product and Development are closely involved with the Design in what is frequently called the “three-in-a-box” model. Even though UX maintains leadership and control over the design tickets and deliverables, the PM and Dev provide much-needed constraints that make design actionable in an enterprise. From brainstorming ideas to reviewing research findings, everyone on the project team remains involved in the design process on an on-going basis. Agile, Inc.’s process more accurately represents this evolution by focusing on the stage of the ticket as represented by the deliverables, rather than assigning responsibility to one or the other team.
2) Creates a single “happy path” through the design project
Agile, Inc. accurately represents the cross-functional nature of the typical design project, thus removing the need to pass the ticket between frequent cross-functional discussions about the design approaches, dev, and business constraints and results of user testing. This approach facilitates a “single-pass” of the ticket through the process. The design itself can potentially undergo 3–4 significant changes in a single sprint (sometimes changing multiple times a day). In contrast, the ticket status remains relatively “quiet,” which allows the team to focus on the meat of the design problem rather than spending excessive energy on tracking the ticket status. Agile, Inc. assumes that the rapid evolution of the design will be the rule rather than the exception, only transitioning between states when the state of the deliverables clearly signals the transition.
3) Provides clear transition between states
Agile, Inc.’s process makes clear the hand-off between the different Jira ticket states. Do you have use cases written out and agreed to? Great, move on to Prototyping. Do you have a prototype? Fantastic — immediately jump into user testing and improvements (RITE). Have a relatively stable design that satisfies the critical use cases? Go to Final Team Approval. Agile, Inc.’s process makes status transition both easy and obvious.
4) Clearly separates Tactical and Vision prototypes, which serve different purposes.
Finally, Agile, Inc.’s process differentiates between two parallel tracks of design: tactical and vision. Both Vision and Tactical tickets follow the same trajectory. However, the two serve very different purposes, reflected in the ticket type. The Vision track is speculative: it dictates that the team optimizes their deliverables for Strategic applications: conference presentations, analyst reviews, product marketing, merger & acquisition discussions. The team working on the Vision ticket spends less time with Development and Users and more time inventing new and potentially patentable approaches to solving problems in uniquely innovative ways that inspire and provide direction. The audience judges Vision prototypes on slickness and innovation, which means necessarily glossing over some of the more complex and technically challenging aspects of the design.
In contrast, the goal of the Tactical ticket is to help the dev team deliver the functionality as quickly and painlessly as possible, adding immediate value for customers. The design for the Tactical ticket should go as deep as time allows into details of the design: sort orders, contents of filters, data format and its alignment in tables, etc. Tactical tickets are also user-tested more rigorously and tend to leverage the existing patterns and design system components. Splitting the Tactical and Vision ticket types at the very beginning (as Agile, Inc. does) allows the project team to focus on adding maximum value in a way that best suits the initial purpose of the ticket.
Thus Agile, Inc. enjoys the advantages of:
- Cross-functional workflows engineered to handle rapid design evolution
- Single linear journey through the design process
- Clear hand-off between ticket phases
- Accurate expectations of the level of effort and quality of deliverables for both Tactical and Vision tickets.
What Jira workflow does your organization use? What does it say about your company? Let us know what you think in the comments!