Every designer has now seen a hundred AI demos. Far fewer have shipped an AI product, watched real people meet it, and paid for the difference between the two. Inpost.ai — my app that reshapes an inbox into smart cards — was that education for me.
The demo trap
An AI feature demos well when the input is chosen and the audience is forgiving. It works when the model's failure modes are designed for. Classifying email into promotions, invoices, newsletters and calendar events is ninety percent straightforward — and the product lives or dies on the remaining ten: the misfiled invoice, the boarding pass detected as a promotion. The design question is never "can the model do it?" It's "what does the person experience when it can't?"
What I practice now
- Design the confidence boundary. Where the model is sure, act; where it isn't, show, don't guess. The interface should wear its uncertainty honestly.
- Validate the promise, not the tech. Twelve interviews and a 28-person prototype survey tested whether people wanted a reshaped inbox — before any model ran.
- Position around the intelligence, not on it. Strategy kept Inpost out of the "smarter mail client" category on purpose; intelligence is the means, life-admin control is the product.
- Instrument the corrections. Every time a user re-files a card, the product learns and the roadmap learns with it.
Why it matters for teams
AI turns a class of design problems into materials problems — you have to know how the material bends, where it snaps, and what it costs. Designers who've only seen the material in demos will specify things it can't do, and miss the things it quietly can. The fix is the old one: build with it, test with real people, keep the receipts.