Ultra PatternsAI interface patterns with receiptsULTRA project

Pattern 18 · Dashboard with AI insights, Chat or assistant · Interaction pattern

View

One proposed action, one named button

Seen in a case Built for a real case and observed with its users, or built for a case whose user test is still to come. No controlled comparison yet.

Practice view. What to build, the words on screen and how to measure it. Switch to Research for why it should work, the framework properties and the references.Research view. The research side is shown below the card: why it should work, the properties it targets and the references. Switch to Practice to hide it.

An AI proposal is one card: what it will do, for whom, the draft, and a button that names the act. A second proposal waits as a small next-step row. Nothing happens until the named button is pressed, and the screen confirms what happened.

WhyTwo proposals next to three abstract buttons left people guessing which one Approve applied to, whether both were mandatory, and whether clicking the draft would send it. With one proposal the guessing stopped: everyone read the summary, reviewed the work and approved or edited it. The verb on the button is the report's recommendation and has not been tested yet. One participant who pressed Approve got no confirmation and did not know what had happened; the confirmation is part of the pattern.
WhenAny assistant that proposes actions with consequences outside the screen: sending, assigning, scheduling, filing.
Not whenBulk work where people deliberately approve a batch. Show the batch as a list with one named button for the whole batch and a way to drop items.

The user stays in chargeThe right amount of trustCase: CNEXT Mail2Flow (company approval pending)

Done right, done wrong

Schematic screens, not real products. Click a screen to enlarge it.
Right. One proposed action with the verb on its button; the next step waits in a small row underneath.
Wrong. Two proposals side by side and three abstract buttons; nobody knows what Approve will do.

The receipt

NoteAn observation, not a controlled comparison. The Compared and Honestly rows say what else differed. Read the numbers as directions, not as effects.
CaseE-mail triage for accountants, CNEXT Mail2Flow (Kairos prototype)
ComparedTwo proposals side by side (task 3) vs. One proposal (task 5) · two task scenarios in the same sessions, task 5 after task 3 for everyone; not a controlled comparison
Peoplethe same seven accountants, three juniors and four seniors
Main resultCompleted the task 5 of 7 (task 3) vs 7 of 7 (task 5) better with one proposal
Read asWith two proposals, one participant executed both as if both were required, one read them as two client questions, one took the left one for the original e-mail. With one proposal everyone read the summary, reviewed the work and approved or edited the draft.
SecondaryThe buttons Approve, Consult partner and Mark done were unclear to most; most did not read the help text under them
SecondaryOne participant feared that clicking the draft would send it; another pressed Approve and got no confirmation
Methodsmoderated think-aloud · six task scenarios · eye tracking
HonestlyTask 5 came after task 3 for everyone, so people had learned the screen, and the tasks differed in content. The gap is large and every observer note points the same way, but it is an observation. Direction only. A controlled comparison with the same task content is the next step.
SourceAbdul Khalil (2026), Mail2Flow usability report, Odisee UX Lab, internal · case page opens after company approval · study run 2026-07 · ULTRA case

A receipt is the result of one test, printed on the card: the case, what was compared, how many people took part, the main result, the methods, and what we do not know. The plan written before the analysis is the study card. How a pattern earns its label.

In practice

Task 3 of the Mail2Flow test opened an urgent client request with two AI proposals next to each other: a reply to the client with two meeting slots, and a message asking a colleague to register the client’s questions. Under both sat three buttons, Approve, Consult partner and Mark done, with a line of grey help text. Five of seven got through it. One participant executed both proposals because she thought both were required, one read them as two questions from the client, one took the left proposal for the original e-mail, and one got stuck on the buttons. Most did not read the help text, and one person was afraid that clicking the draft would send it.

Task 5 showed one proposal, a junior’s prepared VAT workbook to review, and all seven completed it: read the summary, look at the work, approve or edit. The report’s recommendation is the pattern. One proposal at a time, or proposals that expand one by one, and one button per proposal that says what it does, Send this reply, Assign to Alex, instead of three abstract buttons at the bottom of the page.

Two cautions. The comparison is an observation, not a controlled one: task 5 came after task 3 for everyone, so people had learned the screen. And the pattern is only complete with a confirmation. One participant pressed Approve, saw nothing change, and did not know whether the reply had gone out.

Words on screen

"Proposed action 1 of 2: reply to Client A with two meeting slots""Send this reply""Sent to Client A. Next: ask Lea to register the client's questions."

Obligations to keep in mind (AI Act, GDPR)

  • Human oversight means the person knows what a button will do before pressing it. (O2, IUI 2026, Table 1)
  • Confirm what happened after the act; an unconfirmed send is a silent action. (O1, CNEXT test, task 5)

Design considerations, not legal advice or a conformity assessment. What O1 to O5 mean.

Build it

Illustrative signatures, not a published library: the names below are suggestions to adapt to your stack. Thresholds are examples to tune on your own data.

States: proposed, editing, confirmed, next-shown

Component: <ProposedAction index={1} of={2} verb="Send this reply" draft={draft} onConfirm={fn} onEdit={fn} />

Prompt snippet: Return proposed actions as a list, most important first. Each has a verb phrase for the button (under five words), a recipient and a draft. Never mark an action as done.

Output schema: { "actions": [{ "verb": "string", "recipient": "string", "draft": "string" }] }

Measure it

Users are sure of their decision · 2 minUsers feel in control · 8 minFaster, fewer errors · from logsPlan your testTen minutes per participant is the usual budget: pick the two or three cards that fit.

Same idea, other names

Research side · why it should work · framework v0.2

Why it should work

Each proposal is a decision the person has to make, and each button is a consequence they have to predict. Two proposals with shared buttons make that mapping ambiguous, so people either act on everything or freeze. One proposal with the act named on its button turns the decision into a single yes or no with a known consequence; the confirmation closes the loop and keeps the person's model of what happened correct.

Properties targeted

Controllability · Confidence · Efficiency · Axes: scope: local, type: action proposal, format: card, interaction: confirm · Vocabulary bridge

Notes

How to measure: task completion per proposal layout with the same task content, order counterbalanced; the sure-of-their-decision items right after the button press; count wrong actions (both proposals executed, the wrong proposal sent) as errors. Seven people give a direction; a round with more than sixteen gives a test.

Relations

  • The guidelines ask systems to convey the consequences of user actions (Amershi et al. 2019, guideline 16, there about the system's future behaviour); a button that names its act applies the same idea to the act itself. Whether it raises confidence is what the next test should measure.
  • Efficiency, performance, reliance and confidence are among the properties for decision-support settings (Donoso-Guzmán et al. 2025, Figure 13); task completion is the plain measure of effectiveness (ISO 9241-11).

Across contexts

ContextUsersStateResult
CNEXT Mail2Flow, Kairos prototypeaccountants, desktopSeen in a case5 of 7 completed with two proposals, 7 of 7 with one; the three abstract buttons were unclear to most
Your contextBring your case

References

  1. Amershi et al. 2019, Guidelines for Human-AI Interaction, CHI, guidelines 9, 16 and 17. https://doi.org/10.1145/3290605.3300233
  2. Sauro and Lewis 2016, Quantifying the User Experience, 2nd edition, Morgan Kaufmann: task completion rate with small-sample confidence intervals.
  3. ISO 9241-11:2018, Ergonomics of human-system interaction, Part 11: Usability, definitions and concepts.
  4. Donoso-Guzmán et al. 2025, A systematic review of user-centred evaluation of explainable AI in healthcare. arXiv 2506.13904

Editors

Practice: Abasin Abdul Khalil (Odisee UX Lab) · Science: to be assigned by KU Leuven Augment · card v1.0 · 2026-09-08