A team I worked with once spent months building a “magic” one-click optimisation flow. Press the button, and a long, carefully orchestrated sequence would run in the background — pulling data, weighing trade-offs, arriving at the single best answer. It was mapped in research, flow-charted end to end, demoed to applause.
Then a user typed one simple condition: but not this weekend.
The whole flow had no place for that. Not because the constraint was exotic — it was the kind of thing a human would mention in passing — but because the system had been built around delivering an answer, not around taking input partway through. There was no seam to insert a condition into. The only options were: accept the magic answer, or start over with nothing.
Nobody had done anything wrong. The research was real, the flow was well engineered. It’s just that “one click, one perfect answer” had quietly ruled out the most ordinary thing a person does when they ask for help: adding a condition.
Linear thinking builds narrow tools
A lot of product thinking — especially among engineers and data scientists I’ve worked with — defaults to something linear: define the case, build exactly for it, move to the next case. It’s satisfying. It’s easy to defend in a review. But it treats “edge case” as something rare and dismissible, when in most AI products the long tail isn’t an edge at all. It’s most of the actual usage.
If you live in a defined world, you will create a defined input and defined output. The real world doesn’t work like that. It’s messy and unpredictable and so needs flexibility and adaptibility.
Flexibility has to live in the architecture, not just the UI
This is where I think the conversation usually happens one layer too shallow. It’s easy to agree, in principle, that interfaces should be flexible. The harder sell is that the flexibility has to be designed into the interface, the model choice, and the backend together — or the UI ends up promising an openness the system underneath can’t actually support.
A chat interface that looks endlessly flexible but sits on top of rigid, hand-coded intent-matching will feel flexible right up until someone phrases something slightly wrong. A backend built around one model’s specific strengths will start dictating what the product is “allowed” to do, long before any designer gets a say. Real flexibility means the interface can accept more than expected, the model layer can generalise past the training examples, and the backend doesn’t hard-fail the moment an assumption breaks — all three, together.
Where precision still wins
None of this is an argument against specialisation. Some tasks are frequent and well-understood enough to deserve a purpose-built path — narrow, fast, optimised. If the majority of usage is one clear task, build for it directly.
The mistake is treating everything that way: bespoke logic for every scenario research happened to surface, with nothing underneath to catch what wasn’t surfaced. The question worth asking earlier in the process isn’t just “what does the user need to do here” — it’s “when this assumption breaks, what happens?” Does the system degrade gracefully, or does it just fail, because everything was built exactly to spec and nothing else exists?
The point
Good tool design has never been about anticipating every use case as that’s pretty much impossible. It’s about building systems, end to end, that still work when you’re wrong about the case. The best products aren’t the ones where the research was perfectly right. They’re the ones that survive when it wasn’t.
