Design thinking with AI: from problem framing to an interactive prototype in one day

Generating a prototype in an afternoon used to require an engineering team and weeks of wireframing. Today, anyone with access to modern generative tools can produce a functional web interface in under an hour.

Yet speed at creating software has not produced better ventures. Many teams leave AI hackathons and prompt tutorials holding clean prototypes that nobody wants to use or pay for.

The bottleneck in innovation was never how fast a team could draw screens. It has always been whether the team understands the customer problem deeply enough to build something that solves an urgent, expensive pain.

Design Thinking provides the discipline. AI provides the velocity. Combined properly, teams move through discovery, problem definition and functional prototyping in a single day, with every decision grounded in commercial evidence.

This is the framework we use to structure Design Thinking with AI workshops for enterprise cohorts and innovation teams.

The three failure modes of unguided AI workshops

When organisations run AI training or innovation days, sessions often drift into one of three unproductive patterns:

• The prompt tutorial trap: hours spent on tool interfaces and prompt syntax. Participants learn how the software works, but not how to make commercial decisions with it.
• The premature solution: teams skip customer discovery and jump straight into generating screens. Because building feels productive, they assume demand already exists.
• The throwaway output: prototypes built without constraints or realistic data. When the session ends, nobody knows which commercial assumption the prototype was meant to test.

A rigorous session reverses this. Tools stay closed during the opening stages, and technology is introduced only after the problem statement withstands scrutiny.

Phase 1: Frame the problem before touching a tool

The opening block focuses strictly on commercial reality. Before anyone opens an AI builder, the team must describe the customer problem across three dimensions:

• The specific persona: not "small business owners", but "operations managers at UK haulage firms running ten to twenty vehicles without dispatch software".
• The current workaround: what does this customer do today? If nobody is solving it with a spreadsheet, manual emails or paper records, the pain is rarely urgent enough to support a product.
• The cost of inaction: what does leaving this unsolved cost the buyer each month, in lost revenue, compliance exposure or wasted time?

If a team cannot state the problem, the workaround and the cost in three sentences, an AI builder only speeds up the production of software nobody will buy.

Phase 2: Use AI as an adversarial sounding board

Once a team drafts a problem statement, the natural instinct is to look for validation. In our workshops, AI is used for the opposite purpose: to stress test assumptions before any design begins.

The sceptical budget holder

Participants ask the model to act as a cautious buyer who has rejected similar tools before. The team pitches its proposition and must answer objections about security, onboarding effort and budget justification.

The regulatory and edge-case audit

The model is prompted to identify failure points: data protection hurdles, operational handoffs and moments where real behaviour departs from the ideal workflow.

Bias-free discovery questions

Teams use AI to audit their interview scripts, replacing leading questions such as "Would you find an automated tool useful?" with evidence-seeking ones such as "Talk me through the last time you handled this manually. What took the most time?"

Used this way, AI exposes weak assumptions in minutes rather than after weeks of building.

Phase 3: Prototype around one core hypothesis

When teams finally open prototyping tools, firm boundaries prevent scope bloat. A workshop prototype is not a product. It is an interactive evidence probe.

By limiting scope to one interaction, teams finish with a working artefact they can put in front of real prospects the following week.

A practical one-day structure

• Block 1, commercial reality check: problem framing, customer segment and current workaround.
• Block 2, value proposition and AI stress testing: challenging assumptions and refining interview scripts.
• Block 3, focused prototyping: building a single-interaction prototype around one testable hypothesis.
• Block 4, peer testing: unguided walkthroughs and friction logging.
• Block 5, next steps: an actionable roadmap of the validation moves required before any production build.

Timings flex to the group. Shorter formats can cover framing and stress testing only; longer formats add deeper prototyping and testing.

Frequently asked questions

• How does Design Thinking with AI differ from traditional design thinking?+

  The stages are the same: discover, define, develop and deliver. AI compresses the slowest parts, such as stress testing assumptions, drafting unbiased interview scripts and building an interactive prototype, so a team can move from problem framing to a tested artefact in a single session.
• Do participants need a technical background?+

  No. The format is designed for mixed groups, including non-technical founders, researchers, product managers and operational leaders. The focus is on commercial problem validation, not writing code.
• What does a team walk away with?+

  A clear problem statement, a log of challenged assumptions, a set of discovery questions, an interactive prototype tested by peers, and an actionable roadmap for testing with real customers.

Equip your team or cohort to validate demand before building

Whether you lead an innovation team or manage a cohort of early-stage founders, capability building works best when it is hands-on and tied to real decisions.

Explore the workshop tracks at Malvorah Advance, or request the briefing pack and syllabus to review outcomes and delivery options.