Speculative futures

A small but important piece of discovery work that is investigating how new approaches to technology might affect the way we design is wrapping up and I’m trying to get ahead of whatever comes next. This week I was able to spend time with Sarah and Ben writing a few versions of a project brief for the next phase of work, each of which describes what we might do and how we might do it in slightly different ways. Choosing one will depend on what the final outcome of the discovery is.

We’re trying to get things in place well before the next phase so that we can secure resources and socialise the plan ahead of any work starting. The idea is that we will be able to move faster, overall, if we are well prepared for different possible futures. We have a pretty good sense of where the discovery will land, but not all of the specifics. We also don’t know how those results will be received. Taken together, the result is that this process is a little speculative, but we can play with various permutations and combinations to get a sense of how different tunings feel.

In play are the usual topics:

• what is the problem to be solved?
• what should result from us addressing the problem?
• are there any guiding principles to align to?
• what sort of team do we need?
• how much time are we going to allot to exploring the subject?
• in what order should things proceed?
• how will we know when the work is done?

Perhaps most interesting to me is that by adding or removing detail, we can make the problem space tighter or more open. We can also skew how the results of discovery are perceived by placing emphasis in different areas. This feels like one of the harder challenges for this activity: we want to give the team space to explore and find their own answers, but we also want to make sure they are able to remain focussed on solving the right problem and don’t go down blind alleys or waste too much time. Ok, fine, but how to do that without adding in too much bias or pre-conditioning?

Imagining a variety of ways to approach a problem based on different sets of drivers and constraints is a nice exercise. I suppose it is a kind of prototyping, except that instead of designing alternate versions of a component or screen or flow or service, you’re developing different descriptions for how you frame and approach a problem. It is a meta-design activity akin to writing a lesson plan for a university class, which was something I used to really enjoy (and labour over endlessly) when I was teaching many moons ago. You design a prompt that determines the context and starting point for the work, but it is up to the class or team to take it forward as they attempt to produce the intended outcome (more or less).