F1
People rarely have their policy number ready.
Constraint. Let people start without a policy number. Use details they can recall.
UX.md/playground
Read the article (opens in a new tab)UX-context design
UX.md gives an AI model various kinds of context, such as: research findings, a user model describing the people using the product, a world model describing their circumstances, and a glossary. I tested their effect by generating sixteen versions of a car insurance claim page.
Each version used Claude Opus 5, the same prompt, and the same visual identity. Only the combination of UX.md sections changed. Use the switches to compare the results.
Build a single page where a customer can report a car accident to us.
It should collect everything we need to open the claim, and it should look like it belongs to our product. Keep it to one page.
Every version also used the visual identity of Keystone Mutual, a fictional insurer.
Select a version: 1 includes a section, 0 leaves it out
Results
The model received no example form and was not told which context sections were missing. This lets us compare its own choices with those it attributed to UX.md.
None of the sixteen pages requires an account, and thirteen make the policy number optional. The model made some of these choices without instructions in UX.md.
All eight versions with the research findings put photos first, as instructed. All eight without them put photos near the end. None of the versions without the world model displays a timestamp; that section explicitly required one.
The differences are specific: the research findings changed the order of questions, while the world model prompted details about saving and submission times. Other choices, such as allowing people to report without an account, appeared across all sixteen versions.
Each version has a reasoning log written by the AI during generation. The logs explain which decisions the model attributed to the context and which came from its own judgment. These are static mockups: save messages and timestamps show the proposed design, not working features.
The context
Below are summaries of the four UX.md sections and the shared visual identity. The full source files are in context/. Each version's exact UX.md is in context/iterations/.
Constraint. Let people start without a policy number. Use details they can recall.
Constraint. Ask for photos first. Put the written description last and make it optional.
Constraint. Explain what happens next before asking for information.
Constraint. Save automatically. Show what is saved and how to resume.
Constraint. Allow "I don't know" for every factual question. Explain that answers can be corrected later.
Constraint. Guide people through each step. Avoid shortcuts and controls that require prior experience.
Constraint. Explain each insurance term wherever it appears.
Constraint. Let people file without registering. Omit settings and features intended for frequent use.
Constraint. Use large text and controls. Avoid time limits, dragging, and actions that require hovering.
Constraint. Design for phones: one column, high contrast, and controls people can use with one hand.
Constraint. Show one decision per screen. Preserve unfinished answers and make it easy to resume after an interruption.
Constraint. Let people continue without documents. Make those details optional or ask for them later.
Constraint. Save answers on the device and sync when connected. Show when answers have not been sent.
Constraint. Show the report's date and time. Allow corrections after submission and explain how to make them.
| Say | Do not say |
|---|---|
| report | First Notice of Loss, FNOL, claim submission |
| crash | loss event, incident, occurrence |
| the other driver | third party, adverse party, claimant |
| your car | insured vehicle, covered auto, unit |
| what you pay | deductible, unless defined on the spot |
| the person handling your claim | adjuster, claims representative |
| we got it | submission received, acknowledgement |
The rule. Use familiar words. Explain any policy term you need to include.
The shared file specifies Inter type, body text of at least 16px, one primary action per screen, red for errors, visible keyboard focus, tap targets of at least 44px, and US English. It defines the visual style and controls for all sixteen forms.