Design Thinking in the Age of AI

What Still Works, What Has to Change ?

Design Thinking has shaped how I approach enterprise transformation, from business intelligence and analytics products to more recent AI-enabled experiences. The starting point has always been the same: understand how people actually work, identify the problem behind the request, explore possible solutions, and learn from users before scaling.

That discipline matters even more with AI. Yet in many AI programmes, the conversation moves quickly from a promising technology demonstration to a pilot, while the human problem receives much less attention. We ask where to introduce Generative AI, which workflow needs an agent, or how soon a conversational interface can be launched. These are useful questions, but they are not the right starting point.

There is a second challenge. Some methods that served us well in traditional digital product design need to evolve when the product itself can interpret, generate, recommend, and increasingly act. A dashboard may contain complex information, but its interaction rules are largely predictable. An AI experience depends on the model, the question, the business context, the data it retrieves, and sometimes the tools it chooses to use. It can produce an excellent answer to one question and a plausible but incorrect answer to another.

The opportunity is not to replace Design Thinking, but to extend it from designing interfaces to designing how people collaborate with intelligence. Three familiar assumptions—about empathy, prototyping, and iteration—show where that change is most important.

Start with the decision, not the AI capability

AI has made it faster and cheaper to create interfaces, code, content, and early concepts. But a working demonstration is not the same as a trusted enterprise product. Behind the model are trusted data, KPI definitions, business semantics, context, integration, security, evaluation, governance, and change management. Those foundations take time and investment, and some are highly specific to the decision being supported.

Consider two requests that sound similar: explain why customer sales declined and explain why product availability declined. Both may use the same AI platform, but they require different data relationships, business rules, domain knowledge, and ways of validating an answer. If we frame the wrong problem, the cost is not simply a redesigned screen; it may be a substantial amount of work around the intelligence itself.

This makes problem framing one of the highest-value activities in Design Thinking. Before deciding whether we need a dashboard, an AI assistant, or an autonomous agent, we should understand the person, the decision they need to make, the consequences of getting it wrong, and the outcome that would make the solution valuable. Not every workflow needs an agent, and not every dashboard needs a chatbot.

The starting question is: which human problem or business decision genuinely deserves intelligence?

1. Empathy: from stated preferences to accountability

Empathy remains the foundation of Human-Centered Design. Observing people, understanding their workflows, and identifying frustrations tells us a great deal about existing behaviour. For example, a Key Account Manager preparing for a customer review can describe which reports they use, which figures they recalculate in Excel, and why they trust one source more than another. This is useful evidence because it reflects what they already do.

Now ask that person whether they would trust AI to explain why their business declined and recommend an action. Their answer is no longer an account of current behaviour. It is a prediction about how they might use a system they have not experienced. Enthusiasm in a workshop may not translate into reliance during an important customer meeting. A person may read the recommendation and then open the familiar dashboard to verify the figures—not because AI was necessarily wrong, but because accountability still rests with them.

The reverse is possible too. A sceptical user may gain confidence when an AI system repeatedly identifies a meaningful issue early, explains it clearly, and provides evidence they can verify. Actual use can change attitudes in ways that interviews alone cannot anticipate.

For AI, empathy research therefore needs to go beyond asking what features people want. In discovery and co-design sessions, I would give greater attention to questions such as:

• What decisions is this person accountable for, and what happens when they are wrong?
• Which figures or explanations do they verify today, and what makes a source credible?
• What evidence would help them use an AI recommendation with confidence?
• Which decisions should always remain under human approval?

These questions connect users’ real working conditions with the design of the experience. They also remind us that trust cannot simply be added to a user-interface checklist. It is earned through reliable performance, understandable evidence, and appropriate human control.

The centre of empathy expands from needs and preferences to accountability, trust, and decision rights.

2. Prototyping: test real behaviour, not only the ideal experience

Prototyping lets us learn before committing to a full build. A clickable prototype can be an effective way to evaluate the navigation, information hierarchy, and interactions of a traditional application. With AI, it remains useful for those purposes—but a polished mock-up can conceal the very behaviours that will determine whether the product succeeds.

Imagine a prototype in which the user asks, “Why did my business decline last week?” and receives a perfectly structured explanation. It demonstrates the intended experience. It does not show what happens when the question contains internal shorthand, when two data sources disagree, when the system omits an important driver, or when it gives a fluent answer supported by the wrong evidence. Those variations are not peripheral to the experience; they are central to its reliability.

For an AI product, the range of behaviour is part of the product. That means moving earlier to real models, representative data, realistic questions, and genuine business context—even if the first interface is rough. A working prototype can reveal failure patterns that an elegant concept presentation cannot.

Wizard-of-Oz testing, where a person produces responses behind a simulated AI interface, still helps teams assess whether a conversational concept is useful. But we need to be clear about its limits. A knowledgeable human may understand ambiguous requests and avoid mistakes that the actual system will make. Such testing can validate the concept and interaction, but it cannot by itself establish trust in production AI behaviour.

We also need to prototype failure deliberately. In a probabilistic system, the question is not only how frequently it gets the answer right, but what happens when it does not. Can the user trace a figure to its source, see the relevant assumptions, identify contradictory evidence, correct the question, or reverse an action? Can the system say that the available information is insufficient rather than presenting a confident explanation?

This is why accuracy, detectability, and recoverability should be designed together. Evaluation should cover not only correct answers, but also relevance to the decision, consistency across realistic questions, and the experience of checking or challenging an answer. A credible AI experience is one that helps people recognise its limits as well as use its strengths.

3. Iteration: design for an evolving relationship with AI

Traditional product development iterates toward an experience stable enough to launch and scale. AI requires a longer view because the system can change even when the interface does not. A model update, new data source, revised KPI definition, or change in retrieval logic may alter the answer users receive. Evaluation therefore needs to continue as the product evolves.

The user changes as well. Early in adoption, people may verify almost every significant AI response. As they see the system perform reliably, they develop a sense of where it helps and where they still need to check. Over time, a different risk can emerge: they accept a fluent answer because the system has been right before, without looking closely at the evidence for this particular response.

That is why the goal should not be maximum trust. It should be appropriate trust—confidence that reflects what the system can actually do in a given situation. A new user may need clear sources, assumptions, and supporting numbers. An experienced user may need a faster path to action without losing access to that evidence. Where the stakes are high or the result is uncertain, the product should make verification visible rather than encouraging automatic acceptance.

Illustrative trust lifecycle: confidence should remain calibrated to evidence, not familiarity.

This lifecycle is illustrative, not inevitable. Users may move back and forth as they encounter new tasks, model changes, or errors. The design challenge is to help them calibrate trust continuously, rather than assume that adoption or satisfaction proves the system is reliable.

Continuous evaluation should bring product, business, data, and AI engineering teams together. It needs to look beyond model performance alone and assess response quality, user feedback, recurring failure patterns, and changes in how people use the intelligence over time. The product may have launched, but the design work has not finished.

What becomes more valuable: divergence and direct observation

AI gives us more ways to address the same problem. A user who once needed another dashboard might now benefit more from a concise narrative, a proactive alert, a conversation, a prediction, an embedded recommendation, or a workflow assistant. These are not interchangeable formats. Each asks for a different level of attention and trust, and each changes the user’s role in the process.

This makes divergent thinking particularly valuable. We should explore several forms of experience before selecting a solution. Generative AI can help produce alternatives and challenge a team’s initial assumptions, but it does not remove the need for direct observation and co-design. Often the most valuable insight comes from seeing the spreadsheet someone maintains outside the official system, understanding why they ignore an alert, or watching the steps they take before committing to a decision.

In my experience, strong product design comes from bringing these perspectives together: real user observation, business knowledge, technical possibilities, and the ability to test alternatives with the people who will live with the result.

Two responsibilities AI brings into the design process

Design the economics of attention

Proactive intelligence is a powerful idea: instead of making people search for insights, the system identifies what they should know. But a system that monitors hundreds of customers, thousands of stores, and many KPIs can produce far more signals than anyone can act on. If every change becomes an alert, even useful information is likely to be ignored.

The design question shifts from what the system can detect to what deserves this person’s attention now. The answer depends on the user’s responsibilities, the materiality of the issue, the reliability of the signal, the time available to act, and the practical number of interventions they can make. It also depends on learning from dismissals and feedback rather than repeatedly surfacing the same noise.

This is the economics of attention: AI can generate signals at scale, but human attention and capacity to act remain limited. A well-designed experience may deliberately surface fewer insights because those are the ones most likely to improve an outcome.

Design the boundary of autonomy

As AI progresses from answering questions to recommending and taking action, design must address who is making the decision. A useful way to examine this is the progression Inform → Explain → Recommend → Act. Moving from one step to the next changes what the system is responsible for and what the human needs to review.

Autonomy boundaries should reflect the consequence and reversibility of each decision.

The right boundary is specific to the decision. Prioritising stores for a field visit and changing commercial investment carry different consequences, even if both can be initiated by an agent. Teams should consider the cost of an error, whether an action can be reversed, what evidence is required, and who has authority to approve it. Higher-impact actions may need explicit confirmation and a clear audit trail; lower-risk tasks may permit more automation.

Autonomy is not simply a technical capability. It is a product and Human-Centered Design choice. People should understand when the system is informing them, when it is recommending, and when an action is about to be taken on their behalf.

Design no longer stops at the screen

Perhaps the biggest change is that the experience is now shaped by decisions made well beyond the interface. Consider a user asking why a customer’s performance declined. Commercial planning suggests a promotion ended earlier than expected, while supply data shows constrained shipments. A system that selects one explanation without acknowledging the other may sound decisive but lead the user in the wrong direction. A better experience presents the evidence, makes the conflict clear, and helps the user decide what to investigate next.

That outcome depends on choices about business semantics, data authority, context, retrieval, memory, tool use, governance, and evaluation. Some are architecture and engineering decisions; all have consequences for the human experience. Designers need to work with business experts, product leaders, data and AI engineers, and governance teams to ensure those choices reflect the user’s goals and responsibilities.

It also changes how we define success. Usage and satisfaction still matter, but a trusted enterprise AI product should be assessed against the problem it was designed to solve: whether people receive accurate and relevant guidance, can verify it when needed, reach decisions faster, take appropriate action, and achieve measurable outcomes where attribution is possible. An impressive answer is not automatically a useful decision experience.

What still works, and what needs to evolve

Design Thinking practice	What remains essential	What changes with AI
Problem framing	Start with a real human problem.	Identify the decision, accountability, and value before choosing an AI capability.
Empathy	Observe people and understand their work.	Study trust, verification, consequence, and decision rights—not stated preferences alone.
Prototyping	Learn before scaling.	Test real model behaviour, realistic questions, and failure paths alongside the interface.
Iteration	Use feedback to improve.	Evaluate continuously as both the system and users’ trust evolve.
Divergence	Explore alternatives before converging.	Choose deliberately among dashboards, narratives, alerts, assistants, and agents.

The canvas has expanded, but the principle remains

Design Thinking has not become obsolete in the age of AI. Its core practices—empathy, problem framing, experimentation, and continuous learning—remain essential. What changes is the object of design. We are moving beyond defining how people interact with software toward shaping how people collaborate with systems that interpret, recommend, and sometimes act.

Human-Centered Design must therefore extend to context, evidence, trust, attention, failure, and autonomy. That does not mean designers own every technical decision. It means the entire product team needs to design those capabilities around the human experience and the decisions the product is meant to improve.

Start with the human, not the technology. The purpose of AI is not simply to make systems more intelligent; it is to help people work with greater clarity, make better-informed decisions, and achieve better outcomes. That is still Design Thinking. Its canvas is simply much bigger.

In the next article, I will take this perspective into a CPG example: how Human-Centered Design can help move Business Intelligence beyond dashboards toward Decision Intelligence.