Don't Trust The Process

When I carve a butter knife, I don't begin with research.

I don't produce a specification, develop several concepts, construct a prototype and arrange for someone to evaluate it. I pick up a piece of wood and start carving.

I already have a reasonable understanding of butter knives. I've used plenty of them. I know something about wood, how it behaves and what happens when a sharp tool meets the grain. As I work, the shape begins to emerge. Occasionally the wood has other ideas. Something that seemed sensible a moment ago turns out to be awkward, too thin or simply wrong.

I adjust. Sometimes I reconsider the shape entirely.

None of this feels especially remarkable. I'm making a butter knife.

Another person might approach the same task differently. Someone unfamiliar with carving might study examples, sketch a few possibilities or practise cuts before attempting the knife. Someone planning to manufacture ten thousand of them would probably have more to consider.

All reasonable approaches to essentially the same problem.

Yet we have a peculiar habit of describing design as though it ought to follow a recognisable sequence. Research, ideation, prototyping, testing, implementation. Sometimes there are diamonds. Sometimes circles. Almost always arrows.

We seem remarkably fond of arrows.

The question isn't whether we need to investigate, experiment or evaluate. It's why we've become so attached to prescribing the order in which we do them.

The Comfort Of A Diagram

Design processes serve a useful purpose.

They help us organise complicated work, coordinate people with different skills, estimate costs and explain what we're doing to those who would rather not spend their afternoons watching designers think.

They preserve accumulated knowledge too. A novice doesn't necessarily know which questions to ask, what assumptions to challenge or when an idea is sufficiently developed to evaluate. A process can provide useful scaffolding while that understanding develops.

And processes are convenient. Reconsidering every established practice from first principles would be exhausting. We'd spend our entire lives deciding how to begin.

The problem is that designing isn't especially obedient to diagrams.

Donald Schön was describing reflection-in-action more than forty years ago. Practitioners don't simply apply previously acquired knowledge to a problem. They develop understanding through engagement with the work itself. They act, observe, reconsider and respond. The situation answers back.

My butter knife is a modest example.

Designers have recognised this for decades. Contemporary methodologies generally acknowledge iteration, discovery and the possibility that understanding will change during the work.

Yet we continue to describe, teach and manage design through distinct stages, each producing something that allows us to proceed to the next.

We've made the diagrams more accommodating. We can now move backwards along the arrows, which is reassuring.

But the underlying assumptions often survive. Understanding precedes making. Prototypes precede products. Confidence increases alongside the fidelity of whatever we're producing.

A convenient description of design has gradually acquired the authority of an instruction.

And some of those instructions owe as much to economics as they do to methodology.

What Making Used To Cost

When producing something is expensive, there's an obvious advantage in investigating it through something cheaper.

You sketch before constructing a model. You make a model before committing to production. You attempt to discover expensive mistakes while they're still inexpensive to correct.

It's a sensible arrangement, and one that has shaped how we think about fidelity.

Low-fidelity prototypes are associated with early exploration. Their roughness communicates uncertainty, invites alternatives and makes change feel inexpensive. Higher fidelity tends to follow greater confidence.

These associations have genuine methodological value.

They also have limitations.

Anyone who has tested an unfinished interface will recognise the participant who becomes completely preoccupied with something that doesn't work.

You want to understand whether an interaction makes sense. They want to know why the button is in the wrong place.

The prototype's imperfections become obstacles to imagining the intended experience. We're asking someone to evaluate a proposed solution while simultaneously compensating for the shortcomings of its representation.

A more convincing artefact can remove those distractions. People can experience the proposition rather than reconstruct it in their imagination. They discover problems that neither they nor the designer anticipated.

But polish creates its own difficulties. A finished-looking product suggests that decisions have already been made. People can become reluctant to question something that appears complete, particularly when they assume substantial effort has gone into producing it.

Neither approach guarantees better learning. They reveal different things, and sometimes conceal different things.

Yet fidelity has become closely associated with the maturity of our understanding, partly because increasing fidelity traditionally required increasing investment.

That relationship is changing.

Engineers have been exploiting technology to reduce the cost of experimentation for decades. Wind tunnels, computer simulation and rapid prototyping allow them to investigate possibilities without first constructing the finished object. Cars can undergo virtual crash tests, aircraft can be tested against simulated conditions, and proposed structures can be evaluated before construction. None of this eliminates the need for physical validation. It expands what can be learned before committing to production.

AI is now changing the economics of learning through making in software.

An application that once required weeks or months of development can, in some circumstances, be constructed in days. A convincing, functional product may cost less to produce than the exploratory design work that would traditionally have preceded it.

That doesn't make the application ready for unrestricted deployment. Security, integration, maintenance and organisational consequences still exist. The cost of creating something and the cost of becoming dependent on it are different matters.

But it does change what we can afford to investigate through making.

A working application can become an early research instrument. We can observe actual behaviour, discover unexpected requirements and investigate assumptions through something that functions rather than something that merely represents the eventual experience.

There are circumstances in which this will produce better evidence than a wireframe. There are others where a conversation or a sketch will tell us everything we need to know.

Technology hasn't established a new correct sequence.

It has expanded our choices.

Meanwhile, The Problem Hasn't Agreed To Wait

There's another cost in the conventional approach that receives less attention.

The cost of waiting.

People don't suspend their needs while we conduct research, investigate possibilities and progress through the appropriate stages.

They adapt.

They create spreadsheets, develop workarounds, establish informal procedures and recruit colleagues into keeping things working. These arrangements accumulate knowledge, habits and dependencies of their own.

By the time our carefully considered solution arrives, the original absence may have become an established way of working.

We're no longer introducing a solution to an unmet need. We're asking people to abandon the solution they've already developed.

Sometimes their improvised approach is better than ours. Sometimes it's fragile, inefficient or dependent on one person who knows which spreadsheet must never be opened on a Friday.

Either way, the delay has had consequences.

We tend to account for the cost of making the wrong thing. We're less consistent about accounting for the cost of not making anything while we investigate.

If learning through making has become cheaper, the balance deserves reconsideration.

Which brings us to an awkward question.

Why do we continue following methods developed under circumstances that may no longer exist?

The Baton

Imagine a practitioner who encounters a problem and develops an effective way of addressing it.

The approach works. Others recognise its value. It gets documented, explained and passed along. Someone adapts it, someone teaches it, and eventually it becomes an established method, perhaps with a diagram, an acronym and a certification programme.

The baton passes from one practitioner to the next.

But the baton isn't the knowledge.

The original practitioner understood the circumstances that made the approach useful. Their successor may understand much of the reasoning. Several handovers later, the method itself may be all that remains.

We know what to do. We are less certain why.

This is how useful practices can become cargo cults.

We reproduce the visible behaviours associated with effective work without necessarily understanding what made those behaviours effective.

We conduct interviews because the methodology requires them. We produce personas because the project is at the persona stage. We organise workshops because workshops are what designers do, preferably involving sticky notes and a wall large enough to accommodate everyone's strategic ambitions.

I think there's one in China.

The activities themselves may be valuable. An interview can reveal something important. A prototype can expose an assumption. A workshop can bring people towards a shared understanding.

But conducting an interview isn't evidence that we've understood anyone. Producing a prototype doesn't establish that we've investigated the right problem. And completing a workshop doesn't mean anyone has agreed on anything beyond the colour of the sticky notes.

Scrum provides a familiar example.

Agile emerged partly as a response to prescriptive development methods, emphasising individuals, collaboration and responding to change. Scrum provides a framework through which teams can put some of those ideas into practice.

Yet it's entirely possible to encounter organisations whose agility is demonstrated primarily through their adherence to ceremonies.

The stand-up happened. The sprint was planned. The retrospective was completed.

Excellent. We are agile.

Goodhart's law introduces another complication. When a measure becomes a target, it ceases to be a useful measure.

We begin by treating particular practices as indicators of effective work. Then we start measuring whether those practices occur. Eventually their completion becomes the objective.

The number of interviews is easily recorded. What the interviews actually taught us is less convenient to measure.

The process becomes evidence of good practice, instead of something whose contribution to good practice needs to be examined.

And familiarity lends authority. A method that has survived for years acquires legitimacy through its continued existence. We inherit not only the instructions, but the assumption that following them is sensible.

Codification is valuable. Without it, every generation of practitioners would have to rediscover what their predecessors had already learned.

But codification can preserve the answer while losing the question.

Which becomes troublesome when the circumstances that once justified the answer have changed.

We now have two problems arriving together.

Technology is altering the economics that helped shape our methods. Meanwhile, those methods may have become detached from the reasoning that would allow us to recognise when they need to change.

Just as we acquire greater freedom to reconsider how we design, we may have lost the habit of questioning why we design the way we do.

A Very Sharp Knife

For a long time, we've been able to demonstrate the appearance of good design by faithfully reproducing its methods.

Now AI offers another possibility. We can reproduce the appearance of good design without bothering with the methods at all.

This might sound like progress.

I'm not entirely convinced.

Consider a familiar sort of internal software project.

A manager wants better visibility of the work being undertaken across a department. The request is straightforward enough. A tracker, some reporting, perhaps a dashboard showing progress and outstanding activities.

Using AI, someone builds a functioning application in a few days. It looks good. The dashboard is attractive, the filters work, and the demonstration goes well.

Everyone is impressed. The manager gets the visibility they asked for.

Unfortunately, the people expected to maintain the information already record much of it elsewhere. What began as a workaround has become the system, and the new application introduces another place to update the same work.

Nobody has investigated how that information is produced, who maintains it, or what happens when the two systems disagree.

People begin entering information because they're asked to. Updates become less frequent as the novelty wears off. Some fields are completed with whatever is necessary to move on.

The dashboard continues looking reassuringly professional.

The information becomes progressively less trustworthy.

This is an illustrative failure, but not an exotic one. The application can fulfil the request without adequately addressing the underlying need.

The problem isn't that AI built it. The same mistake could have taken a conventional development team six months to produce.

The difference is that we can now arrive at a convincing result before anyone has had much opportunity to question the proposition.

And the convincing result can make questioning it less likely.

An experienced practitioner might bypass a formal research activity because they already understand the problem, possess sufficient evidence or recognise that the necessary knowledge can be acquired more effectively through making.

An inexperienced practitioner might bypass the same activity because they don't understand why anyone would bother.

Both may produce something functional. Both may appear equally confident.

The apparent success reinforces the decision to omit practices whose purpose may never have been understood.

And the people evaluating the work can make the same mistake. They see a convincing artefact and assume that the decisions behind it have been equally well considered.

The practitioner may not recognise the limits of their competence, while the observer may no longer recognise the absence of that competence.

It's rather like putting a very sharp knife into someone's hands.

A sharp knife makes cutting easier. An experienced carver understands the grain, anticipates how the blade will behave and recognises when to change direction.

A novice can use the same knife and produce an impressively clean cut.

Unfortunately, it might be in entirely the wrong place.

We don't develop competence by denying novices access to tools. Nor should we insist that everyone master an inherited methodology before they're permitted to make something useful.

But the tool doesn't confer the judgement required to use it.

And a clean cut doesn't establish that the judgement was sound.

There's a peculiar reversal here.

We've spent decades mistaking adherence to process for evidence of good design. Now we risk mistaking a convincing result for evidence that the process was unnecessary.

The pendulum has swung from trusting the method to trusting the result.

Neither necessarily requires us to examine the judgement behind it.

Just Enough Process

At a previous workplace, we had an approach we called just enough process.

The name might suggest an exercise in reducing bureaucracy, trimming unnecessary stages or finding some agreeable compromise between too much process and too little.

It wasn't.

Just enough had nothing to do with quantity.

We drew on the best available methods and practices, selecting and combining them according to the particular project, the people involved and what we needed to understand.

Some projects required extensive investigation. Others began with enough accumulated knowledge to start making. Some demanded formal validation while allowing freedom in how solutions were explored.

The approach could also change as the work developed. A new discovery might demand a practice we hadn't anticipated. Something planned at the outset might become unnecessary.

The objective wasn't to use the smallest possible process.

It was to use appropriate practices.

This distinction matters because discussions about process often assume we're adjusting a quantity. Too much process is cumbersome. Too little is reckless. Somewhere between the extremes lies a sensible compromise.

But the dimensions aren't equivalent.

A project involving public safety may demand extensive formal testing while benefiting from exploratory methods during design. A small creative project may involve little formal governance but demand disciplined experimentation.

Neither occupies a meaningful position on a scale from more process to less.

The pendulum doesn't need to stop in the middle. It needs to stop pretending there's a middle.

None of which makes designing easier.

Following a process requires competence in performing its activities. Selecting appropriate practices requires understanding what those activities are intended to achieve, when they're useful and what might happen if they're omitted.

For people still developing that understanding, process has real value. It can provide scaffolding, preserve safeguards and prompt questions that might otherwise go unasked. The established sequence might even be the best approach for a particular project.

What matters is recognising that it remains a choice.

The alternative to prescribed process isn't improvisation without discipline. It's a repertoire of practices, supported by professional judgement, applied according to the circumstances.

Which seems obvious enough.

Although I can easily imagine someone developing a framework for determining precisely how much process is just enough, complete with maturity levels, assessment criteria and a certification programme.

We would have invented another process to protect ourselves from processes.

There are probably worse business models.

Don't Trust The Process

There's a difference between trusting a process of enquiry and trusting an inherited sequence of activities.

The first asks us to remain open to discovery, recognise uncertainty and allow our understanding to change through the work.

The second can become a ritual whose authority rests largely on the fact that it's what we've been taught to do.

Sometimes they coincide. Sometimes they don't.

Processes preserve accumulated knowledge. They make complicated work manageable, help people collaborate and provide structure where experience is limited.

But they aren't universal instructions for designing.

They emerged from particular circumstances, shaped by particular constraints and developed by practitioners attempting to solve particular problems.

Those circumstances change.

Technology is expanding what we can learn through making, weakening some of the economic assumptions that helped shape our established methods. AI makes that change newly apparent in software, but the underlying development extends far beyond it.

We have more choices available to us.

Yet we can squander that freedom in two different ways. We can continue following inherited processes without understanding why they exist, or abandon them without understanding what they were intended to achieve.

In one case, we reproduce the ritual. In the other, the result.

Both can look remarkably convincing.

Neither necessarily demonstrates that good design has taken place.

Design is a situated practice. Different projects, different practitioners, different approaches. The methods we choose should reflect what we know, what we need to discover, the technologies available and the consequences of getting something wrong.

Sometimes that means following an established process. Sometimes it means questioning every part of it.

And sometimes it means picking up a piece of wood and starting to carve.