As an in-house product design lead, Dual Track was my go-to approach for ensuring that the products my teams and I were working on were designed and developed to be user-friendly and deliver as great a user experience as possible.
Now that I'm Director of User Experience and Design at Fruto, I’m helping clients adopt the same methodology to help them overcome the development challenges associated with delivering user-centric digital products.
In this post, we’ll take a look at some of the challenges product teams face in embedding user-centred UX practices into their Agile processes, and the benefits of using a Dual Track Agile UX approach. I’ll also share the Dual Track UX framework we use at Fruto and my advice on how to adopt the methodology in your business.
The challenge of embedding UX in Agile product development
Historically, we know that the Agile methodology was created for software development and engineers. But UX has since revolutionised product development, and we need to look at how UX and product teams need to work together.
In order to create a continuous product development flow and put the product team together, you need to recognise the difference in how disciplines (Design & Development) think about things. You can’t just shoehorn one into the other.
The need for Design Maturity
As an industry, we’ve since learnt that early ways of thinking about product development involve lots of risk and assumptions. But even though many Product teams now use Agile to best manage development, designers can often (still) be limited in their ability to do user research and continue to design in a time frame that both suits their discipline and generates the most de-risked value for the product or service.
"I have an idea, so all I need is some developers"
- the old way of thinking
This means that, although there may be product maturity, there isn’t the necessary UX maturity to ensure that opportunities to combine business goals with user needs aren’t being missed or that design hypotheses aren’t being applied before checking the problem space and testing.
There is the assumption that by using the methodology, Agile has already done its thing (“We’ve optimised how we build software: We break down the requirements into Epics, User stories, and Sprints… and we deliver”).
But while that approach may work for development, it doesn’t work well for product design as a whole.
For designers to understand what will really improve a product, we need to investigate through UX research - talk to the business and the users (in their different situations and contexts), and learn more about which requirements are fixed and which can be changed for better outcomes.
Agile assumes that you already know what to build
In Agile and software development-focused companies, there is often no time for UX design. Discovery phases, wireframes and usability testing are seen as elongating the delivery phase. Though there may be some UI design, this is often thought of as a level of “sheen” or a visual presentation layer rather than the culmination of a user experience design process.
Development sprints don’t tend to work when UX gets involved either, primarily because Design doesn’t work on 2-week timescales, for instance. But sprints don’t mean the Design team isn’t on hand to support, attend some or part of the agile ceremonies, help resolve issues that come up, or be part of the team.
The two main focuses need to be separated so that you can continually be doing both discovery and development/delivery. And that’s where Dual Track Agile comes in…
Agile vs Dual Track Agile: What’s the difference?
Tracks:
Agile: Single track for both discovery and delivery.
Dual-Track Agile: Two parallel tracks - discovery (pre-development) and delivery (implementation)- allowing for simultaneous work to keep things moving quickly, efficient constant delivery.
Focus on Discovery:
Agile: Discovery is integrated into development and often has to fit around it.
Dual-Track Agile: Dedicated focus on research and validation, and design before development.
Iterative Nature:
Agile: Iterative development with frequent releases.
Dual-Track Agile: Both discovery and delivery tracks are iterative, informing each other continuously but often with less risk.
Roles:
Agile: Mixed roles collaborating on discovery and delivery.
Dual-Track Agile: More explicit separation of focus between discovery and delivery teams.
Risk Mitigation:
Agile: Risks addressed throughout development.
Dual-Track Agile: Aims to identify and mitigate risks earlier in the process through dedicated discovery.
Flexibility:
Agile: Known for flexibility and adaptation.
Dual-Track Agile: Adds adaptability by allowing adjustments based on insights gained during discovery before significant development, which can save a lot of effort and money.
A Dual Track Agile UX Framework
Here at Fruto, we use a slightly modified version of the Dual Track framework.
How we see Dual Track at Fruto
In our version, we recognise that some projects are long and broad, whereas others are short and shallow. It’s also fairly common that once designs are delivered, the development phase can take a long time.
Our framework illustrates that there doesn’t need to be a wait time - in fact, you can deliver twice as fast!
Benefits of using Dual Track Agile Methodology
Whichever specific Dual Track framework you choose to use, using a Dual Track Agile approach to product design results in a number of improved outcomes for both business and end users alike.
Get the most out of your teams
One of the main benefits of the Dual Track approach is that it allows you to keep both teams busy working on value-adding work.
As it usually takes developers longer to build than it does to design, there is lots of potential for stop-and-start disruption using a traditional approach. But with Dual Track everyone is in constant motion, as you’re effectively creating a split-focused production line that understands each part of the process has different characteristics.
It also allows you to balance tactical and strategic projects more effectively. For example, you could work on a strategic development phase in tandem with a couple of more tactical design projects.
Plus, you can have research-only projects that get parked or don’t have a development need; they are just informative - saving unnecessary development time and resources. However, you need to keep an eye out; you don’t want Design to get too far ahead, or else things get slow, start to get stale, and priorities may change.
Escape the "Build Trap”
A Dual Track approach can also help fix the problem of “Feature Factories” by breaking the cycle of unnecessary feature development.
Where discovery has been too shallow, and development goes market-led instead, it can often mean that it doesn’t make for a valuable user improvement/feature (and rarely leads to a lasting competitive advantage). Or you end up using user stories of pre-proposed solutions, rather than UX shaping the needs of the project, using user research with actual users to uncover problems.
Another common problem we see is that User Stories often don’t describe the UX, just the user interface (UI). E.g., there may be a list of what needs to be there and the acceptance criteria, but no outline as to what works as an experience or flow - which is particularly problematic with static designs. So, in this case, you rely on the designer being there to describe things in more detail.
Build MVPs people actually want to use
Conversely, Dual Track also allows you to be a bit more experimental, testing what might work for the product before fully committing to building it, and therefore reducing the risk of the investment.
You’d model or build prototypes of physical “things” (such as hospitals) to explore the concept, tweak, and de-risk - so why wouldn’t you do the same with digital?
This allows you to develop MVPs that people want to use, not just something else they can use/do, but don't meet the expectations according to their needs. Instead, through UX design, you can learn what makes an MLP, what has been causally known as a minimum lovable product.
There’s also more flexibility in how robustly you want to do something. It allows you to have dedicated resources working on separate timescales, using teams in parallel rather than in relay.
Plus, there’s the added bonus of some buffer if projects take longer than expected.
Think of it a bit like an airport runway with the Scrum Master, Product Manager and Project Manager playing the shared role of Air Traffic Controller. Although you can only have one plane take off at a time, there are always others taxi-ing in, others pulling off, etc. There is always some flex.
When not to use a Dual Track approach
In most cases, Dual Track Agile will be the better product development methodology. But there are a few instances where we wouldn’t recommend leaving the standard Agile approach behind just yet.
In an internal organisational structure, the Dual Tack approach may not work for you if…
You are very small and don’t know what your product is (in which case we’d recommend you don’t try building too much at all at this stage and instead work out what problem you need to solve well enough to create traction)
Your UX maturity is low, your budget doesn’t allow, and/or your team is too small (as you simply aren’t in a position to get the most out of it)
(In which case, there’s a huge benefit to working with an external UX partner to do this for you.)
Embedding a Dual-Track approach to product development
So now we’ve established that Dual Track Agile might be something that could help you improve the efficiency and effectiveness of your product team, how do you actually go about adopting it in your business?
Most commonly, our clients don’t know how to embed user discovery work into their development cycles, or aren’t fully aware of the benefits of the approach - and everything comes too late.
Product teams understand they need to validate their ideas, but there is often a sense of needing to build something with code in order to test it. But there isn’t, and we can actually do that relatively quickly and cheaply with a user-centred design approach - which a Dual Track approach supports well.
We also find that lots of product teams still think “Waterfall” (with design/development happening one after the other, not concurrently), even if they do work with an Agile development methodology. But as one of the main benefits of Dual Track Agile is that it doesn’t dictate designers working in the same way development teams do, you only really have that problem when you first start.
After that, Development is always picking up and working on well-understood design solutions.
How Fruto can help
If you want to keep your product moving but need some help getting the wider business to understand that your current delivery model may be dysfunctional or inefficient, need help embedding a new approach, or simply need some extra capacity while moving over to Dual Track, we’re here to help.
Operating as an extension of your internal team, our partnership approach and extensive network of UX design professionals means we can provide the resources you need to take care of the UX side of things (research & design), leaving your internal teams free to do the development work. So you can build better, more user-friendly experiences, faster - no matter the size or maturity of your business.
Explore our UX services, browse our case studies or get in touch to find out more.
