Is this for you?

• Every screen works a little differently, because each was made at a different time, by a different person.
• AI features are "bolted on", and users don't know when to trust them.
• The project lost its designer, and developers are making decisions on the fly.
• The product is growing, and so is its design debt: inconsistent components, patterns and copy.
• The product has to meet accessibility requirements (in the EU, the European Accessibility Act has applied since June 2025).

What I do

• Interaction model — the rules: how the product responds, confirms, undoes and reports errors.
• UX and UI design of the screens — flows and key screens, from sketches to a build-ready version.
• Design system — components, patterns and rules the team can apply on its own.
• Taking over a project in progress — I put in order what exists, close open decisions and carry it forward.

The AI layer

I build on the 18 guidelines for human–AI interaction from Microsoft Research (HAX). I design how the product:

• says what it can and can't do — before the user is disappointed;
• shows what the AI did and on what basis — sources, data, reasoning;
• communicates uncertainty — when a result is reliable and when it needs checking;
• lets people correct, undo and reject an AI result in one move;
• learns from corrections — and shows the user it takes them into account;
• stays out of the way — AI appears where it helps, not everywhere (NN/g 2026: "the year of AI fatigue").

What you get

• Interaction principles — a short document with the rules the product behaves by.
• AI UX patterns — how the product shows AI results, uncertainty, sources and corrections.
• Flow and screen design — in a design tool, ready to build.
• A design system (as an option) — components, tokens, usage documentation.
• A state specification — empty, loading, error, uncertain AI result.

How it runs

1. Review — the current product, the design, technical constraints.
2. Principles — the interaction model and AI patterns, agreed with the team.
3. Key flows — the most important paths, from sketches to screens.
4. Review with developers — what can be built, and how.
5. Build-ready version — screens, states, components.

Roughly 3–8 weeks, depending on scope [to be confirmed]. Taking over a project in progress: the first two weeks go into putting it in order [to be confirmed].

How we'll know it worked

• New screens are made from the same principles, without asking the designer.
• In tests, users can say what the AI did and how to change it.
• Fewer "so how is this supposed to work?" questions from developers.

What this doesn't cover

I don't write production front-end code. I hand the design and components over to the team that builds, and help with reviews.

Visualizations

Anatomy of an AI result (sample artifact)

Sample artifact: an AI result people can check, fix and trust.

From principles to screens

Every screen follows the same rules.

Related services

• Workflow & roles — when you first need to settle who does what.
• Prototype — when the principles need to be tested in action.
• Diagnosis — when the product works, but people don't trust it.