Design thinking has always had a specific goal: get you to “what good looks like” fast, so you don’t waste money finding out the hard way. Usually, the process goes as follows: define the users, prototype the answer, test it against reality, throw away what’s wrong, repeat. That job hasn’t changed in the age of agentic AI. What’s changed is what you’re prototyping with, and knowing how to use it in the age where everyone can build anything.
Up until now, a prototype was disposable by design. You built the mockup, ran it past a handful of users, learned what worked, and threw the artifact away. And that worked fine, because building the real thing was a different job entirely, done by a different team, on a different timeline, months later.
Agentic AI breaks that separation. The “quick prototype” can now be a real, working agent, built in a fraction of the time a static mockup used to take. Working agents aren’t disposable the way a Figma file is. They’re built on data connections, guardrails, and architecture that remain after the workshop ends. Every round of iteration compounds into something reusable, instead of disappearing into an archive folder.
That changes what design thinking is for. Here are a few tips for recalibrating your design thinking mindset for AI workflows and products:
1. Start with the value, not the feature
Before any design or build work starts, get specific about two things: what decision or behavior are you actually trying to change, and what’s it worth if you get it right. Which decision gets better, for whom, and what does that improvement pay for? Vague goals produce vague AI features. You don’t want chatbots that answer questions nobody was struggling to answer.
2. Design thinking’s real job is forcing that clarity
The workshops, the interviews, the affinity maps—the real point of taking these steps is that it makes you answer, out loud, in front of the user, what’s differentiated here and what has to be excellent before a single screen gets designed. If your team can’t answer that question, you’re not ready to prototype anything, agentic or otherwise.
3. Taste isn’t aesthetics. Taste is judgment.
Taste is usually treated like a design department concern: what typeface should we use? Color? How should things be laid out? But it shouldn’t be, at least not exclusively. Taste is knowing which handful of moments in the experience actually matter enough to deserve obsessive quality, and which ones are fine to leave good enough.
In healthcare, that pivotal moment is when someone is deciding where to seek care, scared and short on information. It’s when a clinician needs guidance mid-decision, with a patient in front of them. These are the times to pull out all the stops and heighten attention to detail. Everything else can settle for “shipped and correct.” Exercising taste is the discipline of knowing when to make that kind of call, and most teams never truly engage with it, they just default to polishing everything a little and nothing enough.
4. Ask what this actually feels like on the other end
As opposed to what it does. The subjective experience—for the member, the patient, the clinician on the receiving end. Once you know that, what does the organization have to do exceptionally well to deliver it: accuracy, trust, speed, empathy, some specific combination of those?
5. Agentic tools change the economics of prototyping
Design thinking has always meant building quickly, testing, and learning. What’s new is that the thing you build in that first fast pass can now be a real agent instead of a clickable mockup, built in less time the mockup used to take. That eliminates the gap that used to sit between “prototype” and “production,” where a lot of good ideas die waiting for an engineering team to get to them.
6. But that prototype now lives inside an architecture
This is the biggest differentiator, and it’s a part that’s easy to miss if you’re only looking at the demo. If the prototype is built right, the next workflow doesn’t start from zero. It extends the same foundation, the same guardrails, and the same data connections the first one used. Build it wrong, and you get a faster way to accumulate one-off demos. Build it right, and every engagement makes the next one cheaper and better.
None of this works without the unglamorous part: working across the organization to determine what good actually looks like across user experience and safety. Testing the work against that bar honestly, not generously. And then doing it again.