The instance hijacks the conversation
June 1st, 2026
Designers tend to see systems rather than instances. There's research on this — design cognition studies describe it as the capacity to move fluidly between abstraction and the concrete, to hold the map and the territory simultaneously without confusing one for the other.
Kees Dorst, in Frame Innovation (MIT Press, 2015), argues that what distinguishes expert designers isn't the ability to generate solutions — it's the ability to reframe problems entirely. To step back from the specific instance in front of you and ask: what kind of problem is this, really? What system is this an expression of? This reframing capacity, Dorst argues, is precisely what makes design thinking valuable beyond the design discipline — and precisely what makes it difficult to communicate to people who haven't developed it. Most problem-solving approaches start with a known problem and look for solutions. Design starts by questioning whether the problem as presented is the right problem at all.
The other day, a product my team developed was being showcased to a group of senior leaders. It's a modular, sophisticated platform — but the room got stuck on the fact that in one of the demo dashboards, EBITDA was bigger than revenue. Which makes no sense, of course. Except it was a demo. With placeholder data. The numbers weren't real. The system was.
This is partly an anchor bias problem. Once a concrete number — even a meaningless one — is on the screen, it colonises perception. Tversky and Kahneman documented this decades ago: people latch onto the first piece of concrete information they encounter and struggle to move past it. The instance hijacks the conversation. The system disappears.
It's like:
— This is a car. It can take you from point A to point B. It's fast, it's fun, I think it will sell.
— But our clients want to go to point C.
— Yes, it can take you anywhere you want.
— No, but I see "point B" on the slide. Our clients don't want point B.
— But our clients want to go to point C.
— Yes, it can take you anywhere you want.
— No, but I see "point B" on the slide. Our clients don't want point B.
I don't think this is a failure of intelligence. It's a failure of abstraction — a muscle that design training builds almost accidentally, through years of working with representations that are always proxies for something else. A logo is not the brand. A wireframe is not the product. A demo dashboard is not the data. The discipline teaches you to look through the instance at the system behind it.
The challenge is that not everyone in the room has had that training.
But here's the other side of it: designers can fall into the opposite trap. I've watched my own team spend precious time building a design system for an RFP — a pitch document, a one-time artefact — when only the instance will ever exist. I've fallen into that trap multiple times myself. The system mindset, taken too far, becomes its own kind of disconnection from reality. Infrastructure for outputs that will never ship. Abstraction as procrastination.
The honest question isn't whether to think in systems or instances. It's knowing which one the moment actually requires. And communicating across the gap to people who are wired differently.