Enablement · For designers, UX researchers, service designers

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
What is in it for you

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 happy path is not the design problem. The design problem is the moment it is confidently wrong.
Where you sit

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.

You own this

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

You feed this

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

And this

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 walk away with

What you take back to the team

Everyone leaves with both. The optional results are for teams that already have something running.

1

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.

2

Prototype planIncluded

What to prototype, at what fidelity, with what fake data, and the eight questions to ask the people you test it on.

3

Trust and correction patternsOptional

The concrete patterns for your product: confidence display, source inspection, correction path, and the handoff to a human.

4

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 detail

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.

MomentThe design questionWhat goes wrong without it
The system offers somethingHow 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 itCan 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 wrongIs 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 humanIs the exit obvious, and does context travel with them?The handover loses everything, the person repeats themselves, and the feature becomes a complaint.
How the day runs

One day, spent on a journey you own

Bring a journey your organisation actually owns. Invented ones teach less and nobody defends them.

Morning

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.

Midday

The patterns

Confidence, inspection, correction and handoff, applied to your interface rather than to screenshots of someone else's.

Afternoon

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.

Price

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.

Workshop
€2,000 each, 3 to 4 hours, remote or on-site
1
Written results€1,000 per result
€1,000
€1,000
€1,000
€1,000
Your package
€4,000


Delivered within 5 business days after the last session.

Book a free 30-min Idea Call15-min question slot
Single

AI for designers

€4,0001 workshop + 2 results
Department

Three roles together

€10,0003 workshops + 4 results
See all tracks →
Full

AI transformation

On request3 months, all perspectives
See the programme →
Questions

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, AWS Community Hero, AI and cloud architect in Vienna
Who runs it

Linda Mohamed

AWS Community HeroAWS User Group Vienna organiserLecturer, Hochschule BurgenlandAmazon Bedrock · SageMaker AI · OpenShift AIEN & DE

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.

Projects, open source and talks →

Stay in the loop

Architecture notes, straight to your inbox.

New AI architecture write-ups, use cases added to ai-solutions.wiki, workshop dates and AWS community events in Vienna and online. Choose the topic you care about most.

  • Patterns and trade-offs from real AWS projects
  • Workshop and lab dates before they are announced
  • AWS User Group Vienna and Community Day events

Double opt-in: you confirm by email first. Unsubscribe with one click.

Start here

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]