The logic of conjecture

In grad school, we used to talk about “thinking through making”, by which we meant that design ideas couldn’t be fully developed before you started making something. The act of designing was itself a way to think, a way to create knowledge, which would be embodied by the thing you had made. Ideas were discussed as seeds of an investigation to come, but weren’t treated with any degree of preciousness. Different tutors had different relationships to pure concepts; one flat out refused to talk about unmade ideas and had a rule against “air crits”. And I get it – when you’re a student having grand ideas for the first time, they all seem important. The novice does not yet know that design concepts that exist solely as words are not yet fully thought.

I didn’t know it at the time, but industrial designer Nigel Cross had worked out a theory of all this as early as 1982, in a text titled “Designerly Ways of Knowing”. The article was the third in a series on design studies published by the Open University, aiming to “establish the theoretical bases for treating design as a coherent discipline of study.” Drawing on theorists like Herbert Simon and Horst Rittel, Cross posited that design is a third form of knowledge, separate from the sciences and the humanities, with its own epistemology. In Cross’s formulation, the sciences concern themselves with how things are, and the humanities concern themselves with how things are understood and expressed. Design, however, concerns itself with how things ought to be. Design works on problems that are, by their nature, ill-defined and without a single correct solution. Design outputs must always be concrete and closed – you have to make a decision and ship something, after all – and yet the process that produces them is stubbornly non-verbal. You cannot fully describe your way to a design. The reasoning resists language.

That last point matters more than it might seem. Design outputs cannot be separated from how they were made without losing something essential. (This is both why “design thinking” is absolute bullshit and why the current crop of AI design tools are a dead end.) I can’t solve most design problems by sitting in a chair and thinking really hard, or at least, I won’t be able to solve them well. Some elements of the design simply cannot be thought until their details have been worked through. There is something in the resistance and grain of materials – pixels, code, infrastructure – that generates an understanding you couldn’t have arrived at any other way.

The logic Cross is describing is abductive reasoning – neither deductive (if A then B) nor inductive (from enough observations, I conclude A), but conjectural. You form a plausible guess based on what you know and then you test it by making something. This is why we speak so much about testing our assumptions. This is where hypothesis-driven design comes from, even if the framing makes it seem all very scientific, which is to say, deductive. The insight comes from the collision between your conjecture, the thing you’ve made, and the world at large.

Unfortunately design is not a deterministic process. No amount of double diamond diagrams are going to change what is essentially a conjectural method and make it behave in a strict if/then fashion. Even with a robust design system and an extensive body of prior research, teams still end up in messy debates. Some of that is what happens when you operate with imperfect knowledge, but some of it is the process being worked through. In those discussions, the team thinks its way toward a better formed idea.

This is why the first thing pretty much every consultancy team does when starting a project is rewrite the brief. The problem needs to be made workable, more amenable to being solved. It is a form of discovery that draws out the client’s tacit knowledge and uses it to choose a trajectory. Think of it as subtly adjusting one’s aim. The rewriting of the brief is an act of design, often the first one. In the public sector, this can be difficult because often the brief is the policy, and the policy is typically not up for debate. The designer wants to shape the problem, but policy has already decided what the problem is.

Cross was writing primarily about industrial design and architecture – hard things with mass, stuff that can fall on you, objects with literal edges. The question of how a designerly way of knowing operates across software and perpetually mutable services is something he only begins to address. Agile development partly fills the gap. The real point of agile – and it is beyond obvious to restate this in 2026, but here we are – is iteration based on an observation of how things work in the real world. That is it. Everything else is a set of tricks designed to make that easier. The approach has nothing to do with “moving at pace”, “doing more with less”, or any other such middle-management nonsense. The sum total of what should be done cannot be known in advance, so you make small probes that help you learn, adapting the approach and product or service as you go.

From here, the question becomes how to apply this at the scale of a whole system, full of diffuse and abstract problems that take years to be worked through. I’ll come back to this next week.