Dual Track Design for Agile
A short guide for the dual reality of the startup designer
Parallel Dimensions
This might sound a little odd, but…
The UX designer lives in two parallel time dimensions! 👽
Let me explain. The rapid pace of the Agile methodology alongside the need to plan ahead, positioning the UX designer in a conflict. On the one hand, the UX designer has to stay on track for real-time delivery such as rapid artifact’s hand off, quick decision making, ad-hoc consulting, etc. And on the other hand, should conduct future discovery for the roadmap ahead with activities such as research, UX conceptual planning, problem stating and anything that can set the framing going forward.
So how exactly does this dual existence actually happens in practice?
One answer is Dual Track Design.
Intro
Recently I joined a startup as the Head of Product Design which led me to the need of sharpening up my UX practices toolbox going forward. This is not the first time I’m challenged with the complexity of incorporating a cross-organization design culture into an established company, I had my first shot when leading the design domain in Clicksoftware a few years ago. Nonetheless, It’s felt like I need some freshening up to do with regards to Agile design best practice. Hence this post.
Before jumping straight into the technical aspect of conducting a ‘Hands-on’ Dual Track Design for Agile, let’s talk about the ‘Why’.
So why implement an Agile design-oriented strategy into an Agile environment in the first place? The answer lays in the Agile reality.
Agile
The UX process is not agile at its core. Traditionally, UX design evolved from industrial design domains that were based on a very linear (Waterfall like) method. If to simplify the traditional process, we faced a very sequential and lengthy process: Problem stating → Research → Concept → Evaluation → Implementation (→ repeat). But during early 2000, some silicon valley veterans claim (and seems to be rightfully) that the Agile method makes much more sense when tackling digital problems and is here to stay, therefore, UX design had to adjust.
If we want to adjust we need to be familiar with Agile practice in the startup environment. But before we do, it's important to note that Agile is actually not a method or a set of processes, as a matter of fact, it's a set of principles, values and beliefs (manifesto) that guide teams on how to develop software in agility.
Around those beliefs, a bunch of methods and best practices have been developed to supports the Agile spirit. In order to be respectful of the reader's time, I’ll just list the most basic of terms (that will be used in this post) and encourage the curious reader to further dive into more elaborate materials elsewhere in the World Wide Web 🤓
Sprint- A period of time (between 2 to 4 weeks) during which specific work has to be completed and made ready for review.
Scrum- An Agile methodology encourages time-boxed cycles, team self-organization, and high team accountability. Scrum is the most popular form of Agile.
MVP- A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
Code vs. Design
The aforementioned terms are mostly development-oriented technical tools that serve the Agile way for developers to dissect their work into small parts in order to reach the desired end-result (MVP). However, a designer mindset works differently, in the sense of needing to solve problems holistically in their entirety, and not as a list of shrimp size challenges.
Therefore, in order to ensure a clear problem definition, research-driven decisions, comprehensive idea exploration, highly tested ideas and well-crafted design (or, just do a good design job…), hands-on Dual Track Design for Agile has to take place.
Dual Track Design
The Dual Track methodology originally stems from the development realm and served as a tool to bridge the gap between discovery and delivery. Its main purpose is to methodically handle the two simultaneous efforts that should be happening throughout the product building life cycle, the Delivery and the Discovery.
The process purpose is to ensure that the development sprints (S.0, S.1. etc.) keep being fed with fully defined and agreeable UX/UI artifacts throughout the Sprint lane (DFS.1, DFS.2, etc) which in their tern directed and backed-up by the high-level heavy lifting research work taking place on the Discovery Increments (DI) phases.
The dual-track offers somewhat of a constant mini ‘Waterfall’ cycles that if done right can ensure an ongoing constant discovery and execution.
Let’s dive into the bits and bytes of every part of the cycle.
Discovery
This phase is abstract by nature and includes mainly exploitative activities. The main purpose of this phase is to frame the problem that needs to be solved. Naturally, the Discovery phase happens prior to the execution (as soon as possible) and if done right, reduces the amount of wasted work taken place during both the high fidelity design period (delivery) and the software’s development (sprints) phases.
There’s no structured template of how to handle this phase. The activities that take action here include both qualitative and quantitative research methods. Among other tools, there are User Interviews, Analytics Overview, User Journey Mapping, Design Sprints, Surveys and Questionnaires, User Flow exploration, and more.
The discovery phase outcome should range from a high-level understanding of the problem down to more strategic plans toward the proper solution. Whatever the achievement will be like, it's important to avoid high fidelity deliveries in order to reduce wasted work that eventually could be thrown away once the roadmap will shift course adjacent to the execution (Delivery) phase.
Delivery
This phase is pretty hectic due to the short time period allocated to it. The main purpose of this phase is to deliver craft as fast and accurately as possible. The shorten the sprint is the stressful it becomes. But it does not have to be “too frantic” if the previous (Discovery) phase has been done right.
This is a super structured process that might differ per organization but produce the same outcome. Usually, at the start, a dialogue between the PM and the UX designer will take place in which a prioritized list of features will be presented (sometimes even the scrum team leader will join as well). Then, toward the middle of the sprint, the dialogue will expand to more participants as the plan will be more conceptually clear and probably visually materialized (UI designer if needed, technical writer, expended dev team members, and other subject matter experts). Finally, the entire group will join all together to finalize the content upon hand-off.
The Delivery phase outcome is a well crafted, highly detailed and mutually agreeable craft to be implemented by the scrum team immediately afterward. If the Discovery phase went well then the Delivery phase should run beter. Nevertheless, as reality dictate, things will change, vision will reshape and real-time changes will be imperative.
Which lead us to the Spikes.
Spikes & Insights
Planes made to be broken and nothing is “set in stone”. Even the most comprehensive and deep upfront preparation work could be altered all at once. Although less likely and shouldn’t be the constant reality, course shifting is imperative in an ever-changing hectic environment such as a startup.
One more part of the Dual Track method that is used mainly for calibration purposes, is the Spike. This is the place in which quick response to real-time change should take place. Usually, it’ll happen during the sprint itself and require fast thinking and creative problem-solving.
The reason for those changes is diverse and stems from the need to deliver high-quality and desirable deliverables. Sometimes due to customer urgent requests, sometimes due to certain technology gaps, sometimes due to lack of capacity. Whatever the reason will be based on, Agile is the name of the game here and we bound to play by its rules.
One more aspect of the Dual Track method, and what makes it different than a short Waterfall cycle, is the ongoing data generated immediately after code gets to be deployed. Analytics gives us an amazing quantitative assumptions validation tool that feeding the discovery phase with better, more accurate and deterministic data.
Conclusion and Thoughts
Processes are made to produce better results. If the results aren’t satisfying, it’s either that the process has been done poorly, or the process is wrong and led to poor results. The bottom line is that methods and processes should be taken as a framework, conceptual guidelines that shed more light on how to incorporate UX best practices into a high pace, constantly changing Agile environment.
I personally found the Dual Track Design method to be a great map to base UX process in a new and uncharted startup environment. Having a clear approach toward the way to incorporate design in an Agile-led, highly technological company is imperative. While good UX is known to be the secret sauce in today’s highly competitive reality, it’s up to us designers to guide our peers and colleagues towards the way this magic getting done right. And the process is a significant part of it.
