In a conventional feature, you can largely predict what the software will do. Discovery is about whether users want it and whether it fits the workflow. With an AI-driven feature, that certainty inverts: demand is often obvious, while the behaviour of the thing you are shipping is the unknown. A summariser, a classifier, or an assistant will be right most of the time and confidently wrong some of the time — and the product has to be designed around that distribution, not around the happy path in the demo.

1. The cost of being wrong

Before any prototyping, write down what happens when the model is wrong in this specific workflow. Drafting a reply the user reviews before sending is cheap to get wrong. Auto-categorising invoices that feed a financial report is expensive. This single question determines the whole design: whether output is a suggestion or an action, whether a human confirms, how visible the confidence is, and how easily a mistake can be undone.

Design the recovery path before the generation path. Users forgive a wrong answer; they do not forgive being unable to fix it.

2. Whether the task is actually judgement work

Some workflows look like AI problems but are really missing-data problems or broken-process problems. If your users manually re-type information between two systems, an integration beats a model. If they spend their time chasing approvals, a workflow change beats a model. Reserve AI for tasks that genuinely need language understanding, pattern recognition, or synthesis across messy inputs — the places where rules have already been tried and failed.

3. Quality against a real evaluation set

Discovery should produce an evaluation set before it produces a design: fifty to two hundred real examples with the outcome you would consider correct, including the awkward ones. Prompt changes, model swaps, and retrieval tweaks are then measurable rather than anecdotal. Teams that skip this step end up shipping on vibes and discovering regressions from customer complaints.

  • Collect examples from real user data, not invented ones.
  • Include known-hard cases: ambiguity, missing context, adversarial input.
  • Record the acceptable answer range, not one exact string.
  • Re-run the set on every prompt or model change, before release.

4. Latency and cost as design constraints

A four-second response is fine when the user asked for a document and expects work to happen. It is unacceptable inline in a form field. Model cost behaves similarly: a per-request expense that is trivial for an occasional action becomes a margin problem when it runs on every keystroke. Both belong in discovery, because they change the interaction pattern — streaming, background processing, caching, or a smaller model — rather than being tuned afterwards.

5. How trust is built in the interface

Users decide whether to rely on an AI feature within their first few interactions. Show the sources behind an answer, make edits feel like collaboration rather than correction, and be explicit when the system is uncertain. Silence about uncertainty reads as overconfidence, and one confidently wrong answer with no explanation can end adoption for a whole team.

The teams that ship AI well are rarely the ones with the most sophisticated model. They are the ones who understood the workflow deeply enough to know where imperfect output is genuinely useful — and who built the review, correction and measurement paths that make it safe to be wrong sometimes.