Dual Track Design & Development

4 min readAug 1, 2018

Can designers and developers be best friends in an Agile environment?

Short answer: yes… we think so.

When I first took up my current role, I made sure to spend some time asking the product team for their thoughts on how the design process affects their role. It became apparent that there was a desire for more involvement throughout.

Looking at what others had shared on the subject, I started thinking about how our design team could fit better into the Agile process and avoid throwing completed designs “over the wall” to development with little time for questions. We want to create a more collaborative environment with shared understanding.

To do this we’re going to try a variation of the Dual Track Process that I want to outline in this post.

What is Dual Track?

Dual Track is a process which aims to enable cross-functional teams to design, validate and build collaboratively, with communication throughout. There are two tracks; Discovery and Delivery, but one team working together on both at the same time.

How we’re going to try Dual Track

I’ve split the process into two main phases; Research and Solution.

Let’s take a closer look at each phase…

Research Phase

This is general ongoing research carried out by the design team, but involving the wider team as much as possible. There are also occasions where the business might require a better understanding before things can move to the solution phase.

We’ve created a Kanban board for this phase based on the first half of Optimizely’s Discovery Kanban.

To do
Researching
Synthesising
Sharing Findings

At this point we’ll decide which opportunities, ideas or problems are worth progressing to the solution phase.

Solution Phase

There are two ways that things can end up in the Solution Phase backlog. Either from our general ongoing research, or from informed business requirements.

Sprint 1

Week One — The first week of the sprint we will work together as a team following the GV Design Sprint structure (modifying when required).

Set a goal
Mapping
Looking at how others have solved similar problems
Solution sketches
Prototyping

Week Two — On the second week the design team will organise testing of the teams solution. This includes recruitment, compensation, logistics etc. while the dev’s begin preparing for the first development sprint.

A story mapping session could be beneficial at this point to help determine which user stories to Bin, Thin or Split. This should allow us to define an MVP and what will provide value in subsequent releases.

At the end of the week the team get back together to observe user sessions and takes notes.

Decide whether to continue or not…

By the end of the first sprint you will have created your “best bet” as a team and tested it. After the user sessions the team should then decide whether to continue, make changes, or even stop.

Sprint 2

Week One — Development sprint 1 begins work on the MVP. The team will expand on the first prototype and look at any changes they might have to make as a result of the first user sessions.

Week Two — The design team will organise and conduct a second set of user sessions to focus on any additions or alterations made by the team.

Repeat Sprint 2 process until the team have something they can release and begin learning from.

What next?

We’re going to start small and try it on one project at a time. We hope to try out this process soon, so I’ll try and write a follow up to share what we learn along the way. Fingers crossed it goes well.

Things I might consider:

Alternatives to a full 5 day design sprint for the first week.
Creating “sprint templates” which have variations of the 2 week blocks above that we can chop and change.
Research sprints