The model we are introducing—AUX3 (Agile UX with 3 Tracks)—explicitly defines and supports the time and effort needed for the full UX cycle. We provide evidence in this article that AUX3 embraces the complexity of UX while keeping up with the fast-moving train of Agile.
What We Hope to Improve Upon
Back in 2003, Gary Macomber and Thyra Rauch (“Adopting Agility” at USE 2003) described and sketched out the intertwining of UX and Development during an Agile process. Shortly thereafter, Lynn Miller mentioned “interconnected parallel design and development tracks” in her 2005 paper (presented at the Agile Development Conference). In 2007, Desirée Sy identified two tracks—Interaction Designer Track and Developer Track—in her seminal paper “Adapting Usability Investigations for Agile User-Centered Design” published in the UXPA Journal of Usability Studies.
Figure 1. Original diagram of two track efforts created by Lynn Miller (copyright 2007).
Sy’s paper described UXR and interaction design work taking place in the Interaction Designer Track, which is exemplified by Lynn Miller’s diagram in Figure 1. The Sy and Miller model has been exceptionally helpful when utilizing UX within Agile environments, and it has been taught for 12 years. However, over time, we have seen this oversimplify the time and resources struggle between learning about users and creative problem solving.
How We Are Expanding the Approach
In AUX3, we propose organizing UX work into three tracks to expose the three different types of work: Learning (research methods such as ethnography), Problem Solving (wireframes, interaction design, and so on), and Execution (visual design, design language development, and so on).
Figure 2. AUX3 Tracks: Work conducted in the Learning Track informs the Problem Solving Track, and then work moves to the Execution Track. (Credit: Mckenzie Neenan, 2019)
By explicitly separating these activities, teams are able to better discuss what work is needed to solve the right problems for users in a UX and Agile supported framework. First, we define the three tracks and then describe how the work is done. Throughout, we refer to iterations (many teams call these sprints or cycles), and, in this article, we define these periods as being two weeks in duration (although these durations do vary by team).
Learning Track
In the Learning Track, UX research is conducted ahead of the Problem Solving work. This work, as Sy mentioned in her paper, is focused on generative learning. It informs the upcoming Problem Solving Track and includes strategic discovery through ethnography for newer projects, rapid UX research (such as interviews to answer specific questions), validation with prototypes, and/or usability testing on work that is in progress or has been completed. This track may also include activities such as task analysis and journey mapping, and the people working in this track will most likely need to work closely with people involved in the Problem Solving Track. The goal of the Learning Track is to conduct research to inform the team and evaluate progress. This work may be conducted two or more iterations ahead of the Problem Solving Track and informs all future work.
It is worth noting that with larger teams there may be dedicated people working on Learning aspects across multiple squads for more strategic efforts. Furthermore, these dedicated people sit outside this whole process as their work does not fit into a single or even multiple iterations. Their work is more overarching in scope and longer lasting in duration, as it looks ahead to inform business decisions more so than individual design and development efforts. This work could include research on open questions about large topics, a new pattern that needs a lot of time to create, or areas that span multiple products.
Problem Solving Track
Problem Solving is focused on creating pieces to communicate solution ideas to development by using wireframes, prototypes, and other creative activities to define solutions to a problem. This work sometimes overlaps heavily with UXR. Problem Solving efforts need to be conducted no more than one to two iterations ahead of the Execution Track to ensure that the designers do not get too far ahead. When Problem Solving is done too far before execution, it can leave the design and technical teams out of sync. This ultimately leads to a less effective end product.
Execution Track
The UX team needs to partner with the technical team and help them to make immediate implementation decisions. This is done by communicating about the interaction designs (not just passing along final designs) and working to answer questions as they arise. The UX team in this track is focused on using existing design language and style guides to inform the work (in some cases developers can do that portion themselves) and enhancing those patterns as new needs are defined. This work is conducted in sync with the technical team, and ideally the visual and/or UX designer is able to support the team in person or virtually.
In some cases, at this stage, the team may realize that an experience is not able to be supported and additional problem solving is needed. In this type of situation, the UX design resource(s) may need to join the Execution Track for short-term support.
Figure 3. AUX3 Process of moving through iterations step by step with information acquired in the Learning Track informing Problem Solving, and then work moving to the Execution Track. (Credit: Mckenzie Neenan 2019)
Getting it Done, Iteration by Iteration
Since this work is conducted over the course of many iterations, it is important to clearly convey the cadence of the work. The following sections give further details.
Note: In this article, we are skipping the Cycle/Sprint Zero scenario as we find those to be, unfortunately, rare situations where greenfield work is being done.
Iteration 1
Learning Track
- Gather information about users for Iterations 2–5 via user research.
- Plan a usability study to be conducted on a prototype that the Problem Solving Track is creating.
- Integrate the UXR to inform the active work so that designs can continue to grow with that knowledge.
Problem Solving Track
- Lay the groundwork for design efforts.
- Work with the visual designer to update/create the initial design language and style guide, and do any necessary IA work.
- Create a prototype to be tested via a usability study.
Execution Track
- Work with the technical team to implement low UI cost features that need very little UX design effort.
- Partner with a technical team to understand and work through the high cost/time work, such as the underlying architecture.
Iteration 2
Learning Track
- Continue research and set up a usability study for the next iteration (recruitment, and so on).
Problem Solving Track
- Work on interaction design efforts for Iteration 3.
- Finalize prototype for usability testing.
- Work on the next problems to solve based on research that the Learning team provided.
Execution Track
- Implement designs and make the validated interaction design a reality.
Iteration 3
This iteration brings more maturity to the team as they have started to better understand their own cadence and have made relationships across the teams.
Learning Track
- Run a usability study on the prototype the Problem Solving team created.
- Conduct UXR for future iterations, such as a field study to get more detailed information.
Problem Solving Track
- Finalize the design effort for Iteration 4.
- Integrate the research findings across the work.
- Support the usability study to immediately inform current design and work on future problems.
Execution Track
- Continue to work directly with the development team to implement new features and address both technical and design debt as needed.
How Do You Really Fit UXR In?
Fitting this work into an iteration cycle may seem daunting, but there are ways of doing it in smaller pieces. For example, if you conduct interviews with consumers, these would typically take two iterations as described in the following sections.
Consumer Interviews
This example assumes the work will be conducted in two iterations (two weeks each).
Iteration 1: Plan and recruit (assumes some pre-work is in place).
Iteration 2: Conduct interviews, analyze, synthesize, and report.
Usability Evaluations
This example assumes that participants have already been scheduled to support continuous and iterative development.
Iteration 1, Week 1: Plan and design study, create interview guide, review design, and so on.
Iteration 1, Week 2: Conduct study with pre-scheduled participants, analyze, and report.
Deep Interaction Problems
This example assumes the work will be conducted in two iterations (two weeks each).
Iteration 1: Create initial wireframes, iterate, and create clickable prototype.
Iteration 2: Conduct study with pre-scheduled participants, iterate, and create a mature design.
Working between Tracks
Constant communication between these three tracks is essential for the team’s success, such as by participating in team sharing sessions, sharing progress in tracking tools, having shared workspaces, sharing research results, and collaborating closely. Jeff Patton said in a 2017 blog “Dual Track Development is not Duel Track” (in reference to Sy’s paper “Adapting Usability Investigations for Agile User-Centered Design”), “tracks are not competing rather they must work together.”
There cannot simply be a hand-offs approach between the tracks. As with any good UX work, communication is required to make a great experience. That being said, a portion of the Learning Track work may result in discovering a lack of need. A portion of that work may not even result in prototypes. Learning efforts must be picked strategically and be constantly reviewed for priority alignment with teams so as not to waste efforts or work too far ahead. Strategic research priorities should more closely align with product management needs, and tactical research should align more with the design and technical teams’ needs. As the backlog is groomed and work is reprioritized, this affects the work that the Learning Track focuses on and vice versa.
Everyone works together, all at once, and everyone is aware of what the other disciplines are doing. This can be tricky, but constant communication about progress and priority will help the team get better after a few iterations. Work needs to be tracked in a way that is shared between team members and/or by an individual who keeps the team(s) aligned.
The UX team members are part of the scrum team, which helps keep everyone informed and on the same page. As part of this, during each iteration of the Execution Track, UX representatives need to be present (at minimum virtually present) with the technical people. The UX representatives need to ensure that they are a ready resource and that the UX team is aware of what is being built. Feedback should be provided on their work and vice versa on the Problem Solving efforts being conducted. Additionally, UX work should be tracked in a way that is visible and familiar to the technical team.
UX work that has already been created and/or prototypes should be consistently validated with user feedback through usability testing or live metrics. The Problem Solving team is working just a bit ahead, while the Learning team is a few iterations ahead, and everyone is consulting one another. Leaving egos at the door is imperative to success.
Staffing
As might already be obvious, this approach requires a team of people with a broad set of UX skills. It is almost impossible for a solo UX practitioner to be successful with this approach, and even two UX professionals will find this work very challenging. Where resources are slim, we recommend swarming individuals to work on high priority projects where success is most likely.
What Does This Mean?
The projects that will be most successful are ones where the leadership and stakeholders (product manager, team leader, and managers) understand the value of UX, and where the technical teams are open to collaborating across disciplines. It will take multiple iterations to get into a solid cadence with each other, and the teams need to be aware and supportive of this time constraint.
Ideally, teams will consist of three UX professionals: a strong UX researcher (UXR), a strong UX/interaction designer who can support UXR, and an experienced visual designer who will work with technical people and who can also support UX design work. Larger UX teams are beneficial, but need to be cautious about doing too much work ahead and potentially getting out of sync with the constraints the Execution team is working with.
Closing
The adoption of Agile has exploded over the past 20 years, and the dual track model has been an excellent way to expose and illustrate how these processes can work together. In the spirit of Agile and UX iterations and continual improvement, we believe that AUX3 furthers that model. AUX3 embraces the three different types of work needed to solve the right problems for users—Learning, Problem Solving, and Execution—and helps teams to organize around the work.
