Why do all technology design projects start looking like one thing and end up looking like another? We experience this as a kind of scope creep. It happens all the time.

A few years ago I asked a conference room full of around 120 developers this very simple question. An overwhelming majority agreed.
‍
That is, as a technology development team, we may think we know what we are building, but when we really get down to it, the hidden challenges always emerge. Any of these can take our specifications, designs, code bases, technical architectures or even propositions in a new direction. If only the brief was better! If only the user research was better. If only life wasn’t so complicated!

But even if the brief is good and the research is comprehensive, these emergent requirements still keep coming. Why is this? It is inevitable: the scope creeps. We have to face it. In-house development teams, working in a predominantly agile development culture, can get disorientated by this. It’s like we are mice on the wheel of continuous delivery.

It can be a quick road to overwork, unprofitability, tedious push backs and arguing over contractual change requests. Or it can be embraced as a loss-leading opportunity to overdeliver and bend over backwards in the hope of future work. But, of course, this never solves the problem, it just moves it somewhere else. All scopes naturally creep because design never ends.

As design work is started it progresses from the abstract to the concrete. It moves from vision to sketches to wireframes to prototypes. It becomes more tangible. We see it it or feel it more readily. We may see things we have missed, taken for granted or made assumptions about - either in the scope of the whole thing, in the interaction patterns or the user interface design.
‍

From ‘As-is’ to ‘Could-be’

Typically, we take our research understanding of the tasks we understand and form some sort of definition of the user needs, their activities and valued outcomes. This is the ‘as-is’. Then, we design artefacts that are feasible solutions for meeting these user needs. This is what ‘could-be’.

In the UK, the Government Digital Service, standardised these two steps in their Service Manual, encapsulating the pre-design phase as aDiscovery which can be successfully completed with a definition of user need. Once achieved, teams following the manual move onto the second stage, Alpha. Here, according to the manual, prototypes (paper sketches of UIs, or even code) must be used to test different approaches.

Diagram 1: The step from Discovery to Alpha (GDS).

The International Usability and UX Qualification Board (UXQB) offer a more flexible framework. This is an iterative process of understanding the context of use with ‘as-is scenarios’, then specifying the user requirements with user needs, then producing design solutions to satisfy user requirements. Storyboards and ‘use scenarios’ can sit alongside wireframes and prototypes as ways of delivering designs that ‘could-be’, prior to evaluation.

However, in today’s dominant methodological culture of high velocity, continuous delivery, there is little practical restraint in the use of high fidelity prototyping tools. It is all too rare to see‘ use scenarios’ being seriously considered as design solutions sufficient for evaluation. Agile has come to mean one thing for designers: climbingMt Fidelity. Notably, in the academic sector, where agile is less dominant and researchers have the luxury of more time, scenarios appear to betaken more seriously.

From ‘Could-be’ to ‘Should-be’

Any research understanding we have of our users' needs are in the context of the ‘world-before-design’. However, the design lands in the ‘world after-design' and while we may do a great job of meeting our user’s needs, these are the needs of the ‘world-before-design’. What needs do our users have now they, and our design, are in the ‘world-after-design’?

Future Use Scenarios are a way to get to grips with this phenomena. John M. Carroll and Mary Beth Rosson encapsulated it best in their landmark academic paper 'Getting around the task-artifact cycle: how to make claims and design by scenario’ (1992). (I am going to use the English spelling of artefact from now on.) In a nutshell, we understand tasks, to make artefacts, which changes the tasks possible, which change the artefacts.

Diagram 2: Taking the first steps on the Task-artefact cycle.

Practically, how do we negotiate a cyclical phenomena so wide-ranging and obvious?

We can start by asking our users to consider our use scenario, their use of our proposed design artefact and its consequences. What would it belike? Separately, as ‘design thinkers’ we could ask ourselves what effect would our proposed design have on its users in the ‘world-after-design’?

We have an opportunity to probe deeper into these effects and motivations with our research participants. If meeting the user needs we have identified would be…, then what we can consider what should-be?

Diagram 3: From ‘as-is’ to ‘should be’.

How do we do this? We must take enough time to think, rest, wait a bit, review the transcripts of what our participants said and allow ourselves to reformulate the problem not just as a solution, but to see it as part of a wider problem-space. To think what other behaviours would be changed (or indeed emerge) as a result of our design solution. To think what other user needs come into play and are these worthy of further investigation?

In this way, we can iterate our understanding of the context of use from the ‘world-before-design’ to the ‘world-after-design’. To go beyond meeting user needs and dig deeper into the emergent behaviours that could arise when our when ‘the design is in use’. In short, we can evaluate our use scenarios into future use scenarios.

As responsible researchers and designers, we must start to recognise that design changes context. Once we do this, we can encourage the goalposts to move around until we are happy about their best position. Instead of focussing our energies on stopping the goalposts moving, it will serve us well to address some of the wider challenges Carroll himself identified: Where do scenarios come from? And how do we store them?

‍

Author: Dave Ellender

Article illustration: Helen Couper