The Time Traveling Designer
This is a follow-on post from a piece called “The Time Travelling Designer and other stories of Agile Design” I wrote on the Made by Many blog back in 2013.
The co-ordination between an iterative process of Agile software engineering and the UX/UI design process is full of tensions. The “Time Traveling Designer” is a useful metaphor for understanding the function of a designer in a cross-discipline product team and avoid the dual-horned pitfalls of the over-iterating and a big-design-up-front mentality.
Back in the late 1990s when I first started working in teams to build digital products, the process (appeared) much simpler. There would be a specification document, a wireframe bible and finally some high-fidelity PSDs to translate into your software of choice. This kind of waterfall software development was flawed but easy to grok. After discovering Agile development, everything changed. As for many developers, it was a revelation.
Agile development acknowledged that in a medium where change is easy, change could be managed in a flexible iterative manner while acknowledging the limitations of up-front decision making and planning in creating software. It was a unifying concept for developers and now is widely accepted as best-practice in some form or other.
At the same time it created a tension when creating human interface-heavy software. If best practice Agile development is about avoiding Big Design Upfront (BDUF), how does that marry with best-practice design which requires thinking about the user experience, the brand, and the visual style in a holistic consistent fashion? Agile development processes, like Scrum, can sometime churn forwards like a production machine, continually iterating but without cohesion.
‘Agile doesn’t have a brain’ — Bill Scott, Paypal
The early versions of how we tried to solve this problem included techniques like the Rough Design Upfront, “one sprint ahead”, also know as design chunking, and Emergent Design. These were an improvement over total BDUF but lacked a balance between just-in-time design and a holistic approach. Also these techniques don’t create the artifacts that can be tested with customers and iterated before they are implemented in production software.
These days we know the best processes for integrating design and development is instead to look at the product management processes in an integrated way without separating these two functions. This combined with high degrees of close collaboration between designers and developers creates the best results.
But in getting a team to this point requires some mental and cultural tools, rather than rigid processes to follow. One of the mental tools I call the “The Time Traveling Designer”:
The job of the Time Traveling Designer is to travel into the future of the product (or one of many possible futures), and then to come back to tell the team in the present what it looks like there.
In practical terms this can mean traveling to a time in the near future to envision how a product looks and works, just before you should build it. But it can also mean envisioning the future of the product as it may be six months or a year from now. Unlike the “one sprint ahead” approach, the designers are not limited as to what point in the future they are designing for. Instead product management works out what is most useful for the team to visualize or to prototype for testing with customers or for the sales department to use in pitches and tasks the designers appropriately.
Alternatively, different design teams can have different planning horizons they are working to. This allows for multiple simultaneous design processes at the same time.
Like all good time traveling stories, there needs to be self-consistent rules of time-travel to prevent any paradoxes occurring:
The Rules of Time Traveling Design
1. You must know, and tell the team, how far in the future you have been.
Are you presenting a vision of the product they are expected to be building tomorrow or is this just a potential direction the product could be heading in?
One of the most disruptive things I see for teams is when different stakeholders talk and visualize their ideas in different time horizons without context. This confuses teams as to what is the priority for right now and what things they should be preparing for versus things they should just think YAGNI.
2. There are different possible versions of the future.
When you are designing features one-sprint-ahead, you are basically saying to a team “This is it, this is what we are building next”. When designing the product of the future there are different versions of how it may end-up and these will be affected by testing/feedback in the present. The future isn’t fixed for anyone.
3. The further into the future you go the fuzzier your vision is.
Things in the near future should be crisp and in high-definition, and therefore possible to build right now. But things in the far future are abstract and in low-definition. The further out you project the more likely that change will happen.
Therefore you need to prototype in lower fidelity forms. This is a strong signal to the team that these future features are going to be up for change (or not happen at all).
4. If visions of the far future are in crisp high-definition then it was probably a dream, NOT time-travel.
Occasionally we need to create high-fidelity “shiny object” prototypes of a product that is not going to be realized for a long time. These prototypes can be very useful for all kinds of reasons, especially in sales, and therefore can’t be avoided. But this is not product design and it’s not useful for a team to work from. They should be admired and be a source if inspiration. Then they should be forgotten as you go work the problem.
5. The further into the future you go the less time you can spend there.
There is always a temptation to spend a long time finessing and thinking through interesting problems you might encounter in the future. But this can be a waste of energy for a feature that may never happen or too much will have changed by the time you have churned through higher priority work. Maybe you are pivoting the whole product.
The product team must keep moving and shipping and therefore a design team needs to balance the amount of time it spends on the immediate, the near-future and the far-off future to keep up momentum.
6. You can’t ignore the far future.
The far future vision can be a guiding light of a team and if you only work five inches in front of your face it will be too easy to miss that vision and iterate into a un-competitive place. You can’t ignore the far future but you need to keep in mind the other rules when you are out there.
7. You cannot go back in time but you can go back to the future.
It is also acceptable to revisit the future of a product multiple times, as it will be a different version of the future every time. But you can’t go and design the past. Retro-actively producing design assets is a total waste of time.
Hopefully this metaphor makes sense for your product design process. As a way of thinking, when added to Lean Startup validation practices and a shipping mentality, it creates a delivery-focused but still holistic-thinking product team.