The hard part is what happens when the AI is confidently wrong
AI changes the interesting part of a journey. The happy path designs itself; what needs design is the moment the system is confident and incorrect, the moment a person has to decide whether to trust it, and the moment they want to undo it. This session is about those, and about turning what you learn into evidence the business case can use.
- €2,000 per workshop
- One day
- Up to 12 people
- English or German
Your prototype is the cheapest evidence in the building
In most organisations the business case is written first and design is asked to decorate it. With AI that order actively destroys value, because the thing everyone is guessing at — will people accept this, and what happens when it is wrong — is exactly what a prototype answers in a week.
So this track treats design output as evidence, not decoration. A clickable journey with realistic failure modes, tested on eight people, beats a confident slide about adoption rates every time, and it costs less than the meeting about the slide.
It also covers the specific patterns AI needs and normal interfaces do not: showing confidence without implying precision, making the source of an answer inspectable, designing the correction path so it is faster than doing it manually, and making it obvious when a person is talking to a system rather than a colleague[4].
The column you own, and what your evidence feeds
The model is the same in every track. What changes is which column you own and what you are expected to hand over.
The user
“Who is this for, and what does their day look like afterwards?”
- The journey as it should be
- The three ways AI gets it wrong here
- Trust, inspection and correction
- The exit to a human
In the room: You, product owners, research, service and support
The business
“What is it worth, what is in the way, and who signs?”
- Adoption evidence instead of adoption assumptions
- What the failure modes cost
- The measure of success, grounded in testing
- What to stop doing
In the room: Finance, sponsor, leadership
The technology
“Can it be built, run and defended?”
- What the interface implies about latency
- What has to be inspectable, and therefore stored
- The correction path as a data flow
- What the handoff needs to carry
In the room: Engineering, platform, data
What you take back to the team
Everyone leaves with both. The optional results are for teams that already have something running.
Journey with failure modesIncluded
The journey as it should be, plus the three ways AI gets it wrong in that journey and what the person does next in each.
Prototype planIncluded
What to prototype, at what fidelity, with what fake data, and the eight questions to ask the people you test it on.
Trust and correction patternsOptional
The concrete patterns for your product: confidence display, source inspection, correction path, and the handoff to a human.
Evidence pack for the business caseOptional
What you learned, in the form the value case needs to receive it, so it lands as a finding rather than an opinion.
The four moments that actually need design
Everything else in an AI feature is a normal interface problem. These four are not, and they are where adoption is won or lost.
| Moment | The design question | What goes wrong without it |
|---|---|---|
| The system offers something | How certain does this look, and is that honest? | A confident tone on a weak answer. People trust it once, get burned, and stop trusting it entirely. |
| The person checks it | Can they see where it came from, in one action? | No inspection path, so checking costs more than doing it manually and nobody checks. |
| The system is wrong | Is correcting it faster than starting over? | The correction path is slower than the manual path, so the feature is abandoned quietly. |
| The person needs a human | Is the exit obvious, and does context travel with them? | The handover loses everything, the person repeats themselves, and the feature becomes a complaint. |
One day, spent on a journey you own
Bring a journey your organisation actually owns. Invented ones teach less and nobody defends them.
The journey
The journey as it should be, then the three failure modes, then what the person does next in each. This is most of the value.
The patterns
Confidence, inspection, correction and handoff, applied to your interface rather than to screenshots of someone else's.
The evidence
What to prototype, how to test it cheaply, and how to write up what you find so the business case can use it.
One workshop, the results you choose
Same model as every other workshop: €2,000 for the session, €1,000 per written result. Net, plus VAT.
AI for designers workshop
Pre-session intake, the live workshop with up to 12 people, written results within 5 business days.
€2,000 each, 3 to 4 hours, remote or on-site
Delivered within 5 business days after the last session.
AI for designers
What people ask before booking.
Do I need to know how models work?
No. You need to know how they fail, which is different and more useful. That is the morning.
Is this about designing chat interfaces?
Mostly not. Chat is one shape and usually the wrong one. The session is about AI inside an existing journey, which is where most of the value is.
Do we build prototypes in the session?
We plan them and sketch them. Building them is the week after, and the plan is what makes that week productive.
Can product owners attend?
Yes. The product and design tracks are the pair that most benefits from being run together.
What if we do not have a designer?
Then this session is for whoever is making these decisions implicitly, which is usually a product owner or an engineer.

Linda Mohamed
I design and build AI and cloud systems on AWS and hybrid platforms, and I teach how they work. I have organised the AWS User Group Vienna for more than seven years, co-organise AWS Community Day DACH, teach AI architectures at Hochschule Burgenland, speak at conferences in Europe and the US, and maintain ai-solutions.wiki. Based in Vienna. Remote or on-site, in English or German.
Where the facts come from.
Prices, service names and limits change. The linked official pages are the reference; figures on this page were checked in September 2026.
- ISO/IEC 42001:2023, AI management systems
- ISO/IEC 27001, information security management
- ISO 9001, quality management
- Regulation (EU) 2024/1689, the EU AI Act
- NIST AI Risk Management Framework
- CNCF TAG App Delivery: Platforms White Paper
- CNCF TAG App Delivery: Platform Engineering Maturity Model
- DORA: DevOps Research and Assessment
- AWS Well-Architected Framework
- Amazon Bedrock AgentCore: observability
- AWS: AI services overview
- ai-solutions.wiki: from AI proof of concept to production
- ai-solutions.wiki: build vs buy for AI
- ai-solutions.wiki: total cost of ownership for AI
- Training Magazine: 2025 Training Industry Report
Start with one conversation.
30 minutes to look at your idea, your data and the right starting point. Or book 15 minutes if you only have a question.
- Which journey to bring
- Whether to run it with product owners together
- What is worth prototyping first
- How to turn the findings into a business case
Vienna, Austria · remote across Europe · [email protected]