Every product roadmap I look at right now has "AI" on it somewhere, and about half the time, nobody in the room can explain what user problem it's actually solving. That's not a criticism of AI — it's a criticism of how it's being added to products: as a feature checkbox instead of a considered response to something users are actually struggling with. Here's the more practical version of that conversation.
The question I ask first isn't "where can we add AI" — it's "where does the current experience genuinely fail people, in a way that pattern-matching or generation could plausibly fix?" Those are very different starting points, and they produce very different features. Piction Health is a good example of AI solving a real, specific problem: primary care physicians aren't trained dermatologists, and visually matching a skin condition against a reference set is exactly the kind of pattern-matching task AI is well-suited for. The AI isn't there because it's trendy — it's there because the alternative (a physician guessing, or referring every borderline case to a specialist) was a genuinely worse outcome.
Compare that to the extremely common pattern of bolting a generic chatbot onto a product's support page because "AI" needs to be somewhere in the pitch deck. If the underlying problem — unclear documentation, a confusing settings page, whatever it is — isn't actually a pattern-matching or generation problem, AI doesn't solve it, it just adds a layer of unpredictability on top of it.
The interesting design problems in AI-integrated products aren't about the AI itself — they're about everything around it. AI is probabilistic. It will sometimes be wrong, sometimes be uncertain, and sometimes fail in ways a deterministic feature never would. The product design job is building an experience that stays trustworthy and usable even when the underlying model is wrong some percentage of the time.
In the Piction Health results screen, this meant never presenting a single, confident-looking answer. Instead, the interface surfaces the three most likely matches, side by side, with a visual comparison mode — explicitly inviting the physician to verify rather than simply trust. That single design decision does more for the credibility of an AI feature than any amount of model accuracy improvement, because it's honest about what the system actually knows versus what a human still needs to confirm.
It's worth being specific about why ranked alternatives work better than a single answer, because it's counterintuitive if you're used to thinking about AI features as needing to look confident to be impressive. A single, definitive-looking output invites a binary reaction — the user either trusts it fully or rejects it fully, and the first time it's visibly wrong, trust collapses for every future interaction too. Ranked alternatives with visible reasoning invite a different relationship: the user stays actively engaged in verifying, which means one wrong ranking doesn't poison their trust in the whole feature — it's just one imperfect suggestion among several, exactly as advertised.
A few honest signals that an AI feature is being added for the pitch deck rather than the user: nobody can describe the failure mode in plain language (“what happens when it's wrong?” gets a shrug). The feature would be removed with zero user complaints if it silently stopped working tomorrow. Or the team is more excited about which model they're using than about what specific moment of user friction it addresses. None of these are automatically disqualifying, but they're worth sitting with before committing engineering time to the feature.
None of this is an argument against ambition. It's an argument for sequencing: get honest about the failure mode first, design the surrounding trust-building experience second, and only then does the specific model or vendor choice actually matter. Teams that reverse this order — pick the flashiest model first, figure out the UX around its failures later, if at all — are the ones whose AI features quietly get disabled by users within a month.
This is the actual substance behind AI integration work as I approach it: not "add a chatbot," but a proper audit of where your product's real friction points are, whether any of them are a genuine match for AI, and — if so — designing the surrounding experience so the AI's imperfection doesn't undermine user trust in the rest of the product. Sometimes the honest answer after that audit is that AI isn't the right tool for the problem you actually have, and that's a useful answer too.
If you're evaluating whether an AI feature belongs in your product — or trying to fix one that's already live and not landing the way you hoped — I'd rather have that honest conversation before more engineering time goes into it. Get in touch and let's talk it through.
Disconnected brand and product design creates a fractured user experience. The case for having both aligned under one design system from the start.
Read post
A step-by-step look at how a rough idea becomes a buildable MVP spec — for founders who have just an idea, or a spec with no design yet.
Read post
Most design systems die quietly in a Figma file nobody opens. Lessons from 30+ product launches on what makes a system get adopted by engineering instead of ignored.
Read post
