---
title: "Design and conversion: what the interface decides, and what it does not prove"
description: "Apply UXUI01–24 to conversion: acceptance criteria, observable checks and evidence required for abandonment, uplift, comprehension and trust."
canonical: "https://www.edikka.com/en/insights/ux-ui-design/design-that-converts"
author: "Bertrand Morel"
publisher: "Edikka"
version: "1.0"
published: "2026-09-04"
last_reviewed: "2026-09-04"
next_review: "2026-12-04"
license: "CC BY 4.0"
---

# Design and conversion: what the interface decides, and what it does not prove

<!-- reader-navigation:start -->
**Sections of the full article**

- [A design that converts makes a decision easier. It does not prove that the decision happened.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-short-answer)
- [Separate interface quality, usability evidence and causal business evidence.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-boundary)
- [Four familiar sentences must remain hypotheses until they are observed.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-evidence-claims)
- [From observation to decision: four records, in this order.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-method)
- [UXUI01–24 applied to conversion: acceptance, observation and evidence.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#uxui-conversion-application)
- [Three changes can be verified publicly without inventing an uplift.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-replays)
- [When traffic is scarce, improve certainty before chasing significance.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-low-traffic)
- [This page owns the interface decisions; related pages own the next questions.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-boundaries)
- [Download, replay and challenge the conversion application.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-resources)
- [Sources define evidence boundaries, not Edikka results.](https://www.edikka.com/en/insights/ux-ui-design/design-that-converts#design-conversion-sources)
<!-- reader-navigation:end -->

Apply UXUI01–24 to conversion: acceptance criteria, observable checks and evidence required for abandonment, uplift, comprehension and trust.

Short answer

## A design that converts makes a decision easier. It does not prove that the decision happened.

A useful interface connects a real intent to a comprehensible action, exposes the evidence needed to decide and supports recovery when something fails. Those properties can be inspected and tested. **Conversion uplift is a separate claim**: it requires a defined population, event, denominator, time window and comparison.

This page therefore introduces no new checklist. It applies the existing [Edikka UX/UI Responsibility Matrix](/en/insights/ux-ui-design/ux-vs-ui-differences) to conversion. The same identifiers, `UXUI01` to `UXUI24`, now show what conversion changes in acceptance and evidence.

Conversion does not create a new family of UX/UI decisions. It changes their acceptance criteria and raises the evidence requirement.

Decision boundary

## Separate interface quality, usability evidence and causal business evidence.

*What each level permits the team to conclude*

| Level | Question | Valid evidence | Allowed conclusion |
| --- | --- | --- | --- |
| Interface property | Is the action named, reachable, operable and correctly represented? | Rendered interface, DOM, keyboard, responsive and state tests. | The specified property is present or absent. |
| Outcome of use | Can the intended people understand and complete the task? | Contextual task test, usability benchmark, interviews or support evidence. | What happened for the tested people, tasks and conditions. |
| Business effect | Did the change cause a metric to move? | Controlled experiment or justified quasi-experiment with reliable instrumentation. | An effect proportionate to the design, sample, period and guardrails. |

An inspection can close a missing-label defect. A task test can show that participants recovered from an error. Neither result alone permits “conversion increased”.

Evidence gate · UXUI21–24

## Four familiar sentences must remain hypotheses until they are observed.

The last four rows of the canonical matrix are the centre of this application. They stop an interface description from quietly becoming a behavioural or commercial promise.

Abandonment

### `UXUI21` — The person abandons because of design, lack of trust or the form.

**Why it stays open:** An exit, error or break can be located when it is measured.

**Evidence needed:** Journey data, technical incidents, interviews or tests, and a hypothesis log.

Conversion change

### `UXUI22` — The new design increased or decreased conversion.

**Why it stays open:** Time variation and raw volumes can be described; causality cannot be read from a before/after comparison alone.

**Evidence needed:** Randomised experiment or justified quasi-experiment, controlled instrumentation, data-quality checks and raw results.

Comprehension

### `UXUI23` — The message is clear, obvious or immediately understood.

**Why it stays open:** Accuracy, grammar and coherence can be inspected; comprehension must be observed.

**Evidence needed:** Comprehension or task test, anonymised quotes, results by scenario and sample limitations.

Trust

### `UXUI24` — These logos, testimonials, colours or finishes create trust.

**Why it stays open:** Presence, accuracy, provenance and accessibility of evidence signals can be inspected.

**Evidence needed:** Comparative protocol, responses linked to seen elements, coding, limitations and any observed behaviour.

Decision protocol

## From observation to decision: four records, in this order.

Observe

### Describe the state without explaining it

Record page, viewport, device, task, date, visible state, DOM or event and raw volumes. “The button says X” is observable. “People trust X” is not.

Accept

### Write the threshold before evaluating

Name what must be true for the interface property or task to pass, including exceptions, accessibility and recovery.

Hypothesise

### Keep competing causes visible

Traffic, offer, price, technical incidents, comprehension, trust and measurement can produce similar funnel signals.

Prove

### Choose the lightest method that can support the claim

Use inspection for properties, task observation for outcomes of use and a controlled comparison for causal uplift. Keep “unresolved” when the evidence is insufficient.

Open application view · v1.0

## UXUI01–24 applied to conversion: acceptance, observation and evidence.

Every disclosure keeps the canonical identifier and ownership from the UX/UI matrix. The additional fields describe only what changes when the decision is used in a conversion context. The HTML, JSON, XLSX and Markdown editions are generated from the same 24 rows.

UX-led · 4 decisions

### UX-led

Task flow, structure or recovery governs the decision.

#### Ordering steps in a complex form

**ID :** `UXUI01` · **Accountable:** UX / interaction design — Product, content, engineering

**Conversion context:** Order the steps of an enquiry, sign-up or payment flow.

**Acceptance for this use:** Each step moves towards a named outcome and requests only information needed at that point.

**Publicly observable:** Sequence, grouping, branches and field count can be inspected.

**Claim not allowed:** A shorter form converts better.

**Evidence needed:** Task testing for progression; funnel measurement or a controlled experiment for business effect.

**Dated replay:** 2026-09-04 — check that a diagnosis request separates context, need and contact details without asking for data before it is useful.

#### Structuring navigation and information architecture

**ID :** `UXUI02` · **Accountable:** UX / information architecture — Content, SEO, product

**Conversion context:** Connect intent, offer, evidence and action in the information architecture.

**Acceptance for this use:** Every critical goal has an explicit path and a label that remains coherent across pages.

**Publicly observable:** Destinations, depth, labels and contextual links can be inspected.

**Claim not allowed:** Simplified navigation generates more leads.

**Evidence needed:** Tree or findability testing for discovery; journey data for impact on enquiries.

**Dated replay:** 2026-09-04 — connect Design that converts to the UX/UI matrix, CRO and the audit without duplicating their scope.

#### Designing recovery after interruption

**ID :** `UXUI03` · **Accountable:** UX / interaction design — Product, content, engineering

**Conversion context:** Let people resume an interrupted action without losing valid data.

**Acceptance for this use:** Re-entry point, retained state and consequences of each option are visible before recommitment.

**Publicly observable:** Persistence, return, draft and recovery messages can be retested.

**Claim not allowed:** Autosave reduces abandonment.

**Evidence needed:** An interruption scenario for recovery; measured comparison for abandonment.

**Dated replay:** 2026-09-04 — interrupt an entry, reload the page, then verify exactly what is retained and announced.

#### Defining rules for a conditional journey

**ID :** `UXUI04` · **Accountable:** UX / interaction design — Product, domain experts, engineering

**Conversion context:** Qualify an enquiry without exposing unnecessary branches or creating dead ends.

**Acceptance for this use:** Every condition has an entry, exit and explicit handling of incomplete cases.

**Publicly observable:** Branches and edge cases can be replayed from a decision table.

**Claim not allowed:** The conditional journey improves lead quality.

**Evidence needed:** Branch tests for logic; comparable sales statuses for lead quality.

**Dated replay:** 2026-09-04 — replay project, budget and timing answers, including unplanned combinations.

UI-led · 6 decisions

### UI-led

Behaviour is established; the decision primarily concerns the visual and perceptual system.

#### Building the typographic scale

**ID :** `UXUI05` · **Accountable:** UI / visual design — Content, accessibility, engineering

**Conversion context:** Make promise, evidence, limitation and action distinguishable on first scan.

**Acceptance for this use:** Semantic hierarchy has a stable, readable and responsive typographic expression.

**Publicly observable:** Tokens, sizes, weight, line height, zoom and reflow can be tested.

**Claim not allowed:** Larger typography increases conversion.

**Evidence needed:** Inspection and WCAG tests for technical readability; user testing or experimentation for behavioural effect.

**Dated replay:** 2026-09-04 — verify that the H1, four evidence claims and download keep their perceptual order at 200% zoom.

#### Defining interface colours

**ID :** `UXUI06` · **Accountable:** UI / visual design — Brand, accessibility, engineering

**Conversion context:** Distinguish primary action, secondary action, error, success and information.

**Acceptance for this use:** Every colour keeps a stable role, applicable contrast and a signal that does not rely on colour alone.

**Publicly observable:** Tokens, contrast and state redundancy can be inspected.

**Claim not allowed:** A button of a particular colour converts better.

**Evidence needed:** Contrast measurement for conformance; controlled experimentation to attribute an effect to colour.

**Dated replay:** 2026-09-04 — check that download, contact, error and success remain distinguishable in greyscale.

#### Setting spacing rhythm and density

**ID :** `UXUI07` · **Accountable:** UI / visual design — UX, accessibility, engineering

**Conversion context:** Group proposition, evidence and action without creating misleading proximity.

**Acceptance for this use:** The same relationship uses the same spacing and reflow does not separate a control from its context.

**Publicly observable:** Grid, tokens, density, zoom and target widths can be inspected.

**Claim not allowed:** More white space increases trust or conversion.

**Evidence needed:** Responsive inspection for visual relationship; research or experiment for perceived or business effect.

**Dated replay:** 2026-09-04 — verify that each proof remains closer to the claim it supports than to the next claim.

#### Defining the visual grammar of surfaces

**ID :** `UXUI08` · **Accountable:** UI / visual design — Design system, accessibility, engineering

**Conversion context:** Differentiate content, demonstration, limitation and action areas on a dense page.

**Acceptance for this use:** Border, surface and elevation map to a documented relationship rather than an isolated decorative effect.

**Publicly observable:** Surface treatments and their uses can be compared in the design system.

**Claim not allowed:** Cards or shadows make the offer feel more premium.

**Evidence needed:** Specimen and inspection for consistency; perceptual protocol for a premium claim.

**Dated replay:** 2026-09-04 — reserve emphasis treatment for evidence limits and actions that genuinely change the next step.

#### Creating the icon and illustration language

**ID :** `UXUI09` · **Accountable:** UI / visual design — Brand, content, accessibility

**Conversion context:** Support an action or explanation without replacing its label.

**Acceptance for this use:** Every essential sign has a stable function, a label or an appropriate alternative.

**Publicly observable:** Consistency, decorative or informative role and alternatives can be inspected.

**Claim not allowed:** An illustration increases trust or engagement.

**Evidence needed:** Alternative-text audit for access; comparative research for perception or engagement.

**Dated replay:** 2026-09-04 — verify that no icon alone carries the meaning of download, continue or open an external service.

#### Tuning motion for a transition

**ID :** `UXUI10` · **Accountable:** UI / motion design — UX, accessibility, engineering

**Conversion context:** Signal state change, progress or availability without delaying action.

**Acceptance for this use:** Motion explains state, remains interruptible and respects reduced-motion preference.

**Publicly observable:** Duration, trigger, outcome and motion preference can be tested.

**Claim not allowed:** Animation guides users better or increases engagement.

**Evidence needed:** State and prefers-reduced-motion tests; user observation for the guidance effect.

**Dated replay:** 2026-09-04 — disable animation and verify that opening a detail preserves the same state and meaning.

Shared responsibility · 10 decisions

### Shared responsibility

Structure, content, behaviour and presentation cannot be decided independently.

#### Designing a call to action

**ID :** `UXUI11` · **Accountable:** UX + UI — Content, product, engineering

**Conversion context:** Turn intent into an understandable, reachable and reversible action where needed.

**Acceptance for this use:** Label, priority, placement, destination, accessible name and states describe the same action.

**Publicly observable:** Visible text, href, hierarchy, focus and states can be inspected.

**Claim not allowed:** This CTA converts, or converts better than the previous one.

**Evidence needed:** Comprehension and task testing; experiment or controlled comparison for conversion uplift.

**Dated replay:** 2026-09-04 — replace ‘Prioritized checklist’ with ‘Generate my checklist in ChatGPT’: the action becomes explicit; its effect remains unproven.

#### Designing a form field

**ID :** `UXUI12` · **Accountable:** UX + UI — Content, accessibility, engineering, domain experts

**Conversion context:** Collect only the data needed for a valid enquiry or transaction.

**Acceptance for this use:** Every field is justified, named, operable, announced and understandable in all states.

**Publicly observable:** Declared necessity, HTML, keyboard, help, validation and autocomplete can be checked.

**Claim not allowed:** Removing a field mechanically increases conversion rate.

**Evidence needed:** Business justification and accessibility testing; experiment for the effect of removal on outcomes.

**Dated replay:** 2026-09-04 — associate every label with its control, identify required fields and verify relevant autocomplete.

#### Designing an error experience

**ID :** `UXUI13` · **Accountable:** UX + UI — UX writing, accessibility, engineering

**Conversion context:** Allow an error to be corrected without losing data or guessing the solution.

**Acceptance for this use:** The error is identified, associated, locatable, announced and correctable.

**Publicly observable:** Detection, message, focus, DOM, retention and correction can be retested.

**Claim not allowed:** Better error design recovers lost leads.

**Evidence needed:** Failure scenarios for recovery; funnel measurement or experiment for business impact.

**Dated replay:** 2026-09-04 — trigger every server and client error, then verify focus, message and retention of valid values.

#### Adapting navigation for mobile

**ID :** `UXUI14` · **Accountable:** UX + UI — Content, accessibility, engineering

**Conversion context:** Preserve access to offer, evidence and action on a small screen.

**Acceptance for this use:** Every critical destination remains visible or discoverable, ordered, announced and touch-operable.

**Publicly observable:** Desktop/mobile inventory, reflow, keyboard, zoom and touch targets can be tested.

**Claim not allowed:** The mobile interface converts better after adaptation.

**Evidence needed:** Responsive and task tests; segmented analysis or experiment for conversion effect.

**Dated replay:** 2026-09-04 — at 390 px, verify that the breadcrumb scrolls without hiding the current item and the primary action remains reachable.

#### Designing a modal or drawer

**ID :** `UXUI15` · **Accountable:** UX + UI — Accessibility, content, engineering

**Conversion context:** Present interruptive information or action only when it is necessary.

**Acceptance for this use:** Pattern purpose, name, focus, closing, background and exit are documented.

**Publicly observable:** Opening, closing, focus order, Escape and background content can be tested.

**Claim not allowed:** A modal or pop-up increases sign-ups.

**Evidence needed:** Keyboard journey and pattern audit; experiment with guardrails for sign-up effect.

**Dated replay:** 2026-09-04 — open and close a modal by keyboard and verify that focus returns to its trigger.

#### Designing loading, progress and empty states

**ID :** `UXUI16` · **Accountable:** UX + UI — Content, accessibility, engineering

**Conversion context:** Maintain understanding during loading, waiting, no-result or progress states.

**Acceptance for this use:** Every state describes reality, preserves safe actions and exposes a perceivable, programmatic status.

**Publicly observable:** Simulated delays, states, announcements and available actions can be tested.

**Claim not allowed:** A progress indicator reassures people and reduces abandonment.

**Evidence needed:** State map and announcement test; observation or experiment for trust and abandonment.

**Dated replay:** 2026-09-04 — simulate a slow response, failure and empty result, then compare visible message and announced status.

#### Designing a data table or dashboard

**ID :** `UXUI17` · **Accountable:** UX + UI — Data, accessibility, product, engineering

**Conversion context:** Present metrics, comparison or estimation that genuinely supports a decision.

**Acceptance for this use:** Every visual answers a named question and preserves unit, period, provenance and alternative.

**Publicly observable:** Data, units, encoding, source and tabular alternative can be inspected.

**Claim not allowed:** A dashboard or estimator increases engagement or enquiries.

**Evidence needed:** Data checks for accuracy; task testing or experiment for effect on the decision.

**Dated replay:** 2026-09-04 — verify that a conversion figure always shows its numerator, denominator, period and source.

#### Designing onboarding

**ID :** `UXUI18` · **Accountable:** UX + UI — Content, product, research, engineering

**Conversion context:** Reach first useful value without imposing unnecessary teaching steps.

**Acceptance for this use:** Every step answers an immediate need, can be exited and does not block an already-capable person.

**Publicly observable:** Exit, resumption, progress, mandatory steps and outcome can be tested.

**Claim not allowed:** The guided tour improves activation.

**Evidence needed:** Novice/experienced scenarios; cohort or experiment to attribute an activation change.

**Dated replay:** 2026-09-04 — complete the primary action without starting help, then verify that help remains available when needed.

#### Creating a design-system component

**ID :** `UXUI19` · **Accountable:** UX + UI — Content, accessibility, engineering, design system

**Conversion context:** Reuse the same contracts for CTAs, fields, errors, evidence and confirmation.

**Acceptance for this use:** Use, non-use, content, states, accessibility and reference implementation are documented.

**Publicly observable:** Documentation, variants, code and component tests can be checked.

**Claim not allowed:** Design-system consistency increases conversion.

**Evidence needed:** Component-conformance audit; product comparison for business effect.

**Dated replay:** 2026-09-04 — compare every action button and record each difference in label, state, focus or destination.

#### Designing confirmation and the next step

**ID :** `UXUI20` · **Accountable:** UX + UI — Content, product, accessibility, engineering

**Conversion context:** Confirm the real outcome, provide a useful trace and offer a proportionate next step.

**Acceptance for this use:** Server status is announced before any new request and the useful reference remains available.

**Publicly observable:** Response, confirmation, focus, reference and next action can be tested.

**Claim not allowed:** Adding a secondary action after confirmation increases customer value.

**Evidence needed:** End-of-task test; downstream data or experiment for commercial effect.

**Dated replay:** 2026-09-04 — submit a valid enquiry and verify that confirmation precedes any proposed next step.

Evidence required · 4 decisions

### Evidence required

Ownership depends on a cause or effect that must be observed rather than assumed.

#### Explaining abandonment in a journey

**ID :** `UXUI21` · **Accountable:** To be assigned after observation — Research, data, UX, UI, product, engineering

**Conversion context:** Explain why a person leaves a step or does not continue.

**Acceptance for this use:** The signal is described without a single cause and competing explanations remain visible.

**Publicly observable:** An exit, error or break can be located when it is measured.

**Claim not allowed:** The person abandons because of design, lack of trust or the form.

**Evidence needed:** Journey data, technical incidents, interviews or tests, and a hypothesis log.

**Dated replay:** 2026-09-04 — classify every sentence beginning ‘visitors abandon because’ as a hypothesis until the cause is observed.

#### Attributing a conversion increase or decrease

**ID :** `UXUI22` · **Accountable:** To be assigned by the protocol — Data, product, research, UX, UI

**Conversion context:** Attribute a change in enquiries, sign-ups, payments or qualification to a modification.

**Acceptance for this use:** Metric, population, window, randomisation unit, guardrails and decision rule are fixed before reading results.

**Publicly observable:** Time variation and raw volumes can be described; causality cannot be read from a before/after comparison alone.

**Claim not allowed:** The new design increased or decreased conversion.

**Evidence needed:** Randomised experiment or justified quasi-experiment, controlled instrumentation, data-quality checks and raw results.

**Dated replay:** 2026-09-04 — ban any uplift percentage in an Edikka case without a protocol, denominator, period and verifiable data.

#### Claiming that a label is understood

**ID :** `UXUI23` · **Accountable:** User research — UX writing, UX, product

**Conversion context:** Claim that a promise, proof, label or next step is understood.

**Acceptance for this use:** Population, task, comprehension question and threshold are defined before testing.

**Publicly observable:** Accuracy, grammar and coherence can be inspected; comprehension must be observed.

**Claim not allowed:** The message is clear, obvious or immediately understood.

**Evidence needed:** Comprehension or task test, anonymised quotes, results by scenario and sample limitations.

**Dated replay:** 2026-09-04 — ‘Generate my checklist in ChatGPT’ names the action better than ‘Prioritized checklist’, without proving it is understood.

#### Claiming that an interface feels trustworthy or premium

**ID :** `UXUI24` · **Accountable:** User research — Brand, UX, UI, content

**Conversion context:** Claim that the interface reassures, inspires trust, reduces risk or feels premium.

**Acceptance for this use:** Audience, context, terms, stimuli and expected responses are defined before observation.

**Publicly observable:** Presence, accuracy, provenance and accessibility of evidence signals can be inspected.

**Claim not allowed:** These logos, testimonials, colours or finishes create trust.

**Evidence needed:** Comparative protocol, responses linked to seen elements, coding, limitations and any observed behaviour.

**Dated replay:** 2026-09-04 — verify that customer evidence exists and has a source, but leave ‘inspires trust’ open until dedicated research.

Dated replays · Edikka page

## Three changes can be verified publicly without inventing an uplift.

*Public observations · 4 September 2026*

| Decision | Previous state | Published state | Allowed conclusion | Still unproven |
| --- | --- | --- | --- | --- |
| UXUI11 / UXUI23 | “Prioritized checklist”. | “Generate my checklist in ChatGPT”. | The visible label names both the action and external service. | That the label is understood or produces more use. |
| UXUI02 | Standalone rules article with no stable mapping. | Every recommendation is attached to UXUI01–24 and linked to the matrix. | The source and ownership of each decision are traceable. | That readers decide faster or contact Edikka more often. |
| UXUI22 | Conversion language without a published result protocol. | Causal claims are explicitly blocked until population, metric, window, guardrails and comparison exist. | The publication rule rejects unsupported uplift. | Any Edikka conversion result. |

Low-traffic B2B

## When traffic is scarce, improve certainty before chasing significance.

A small B2B site may not have enough eligible journeys for a trustworthy experiment. The work does not stop: fix reproducible defects, test critical tasks with relevant participants, inspect sales and support evidence, publish raw volumes and verify instrumentation. These actions can close interface or usability questions.

They do not turn a small sample into causal proof. A percentage without its numerator, denominator, window and eligibility rule is not a decision. The correct result may remain **insufficient data**.

Editorial architecture

## This page owns the interface decisions; related pages own the next questions.

### Do not ask one article to prove the whole system.

The matrix owns responsibility. CRO owns hypothesis and experiment. The funnel owns denominators. Web development owns performance and implementation.

- [01UX/UI matrixAssign the 24 canonical decisions](/en/insights/ux-ui-design/ux-vs-ui-differences)
- [02CRODiagnose and test a conversion hypothesis](/en/insights/ux-ui-design/cro-improve-conversion-rate)
- [03FunnelDefine transitions and denominators](/en/insights/digital-strategy/conversion-funnel-guide)
- [04EngineeringOwn performance and implementation evidence](/en/expertise/web-development)

Open resources · CC BY 4.0

## Download, replay and challenge the conversion application.

- [UX/UI conversion application · XLSX](/docbd/data/application-conversion-uxui-edikka-v1.xlsx) — working sheets, decision log and adversarial replay.
- [Canonical bilingual application · JSON](/docbd/data/application-conversion-uxui-edikka-v1.json) — 24 rows keyed by UXUI01–24.
- [English Markdown edition](/llms/insights/design-that-converts.md) and [French Markdown edition](/llms/insights/design-qui-convertit.md).
- [Canonical UX/UI Responsibility Matrix · XLSX](/docbd/data/matrice-responsabilites-ux-ui-edikka-v1.xlsx) — source ownership, acceptance and evidence.

For v1.1, five independent practitioners should answer one question row by row: “Which line is false, ambiguous or impossible to decide?” Objections, accepted changes and retained disagreements should be published with the reviewer’s permission.

Primary sources

## Sources define evidence boundaries, not Edikka results.

- [ISO 9241-11:2018 — Usability: Definitions and concepts](https://www.iso.org/standard/63500.html) — Frames effectiveness, efficiency and satisfaction as outcomes of use in a specified context.
- [W3C — Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — Provides testable criteria for perception, interaction, understanding and robustness.
- [W3C WAI — Forms Tutorial](https://www.w3.org/WAI/tutorials/forms/) — Documents labels, groups, instructions, validation, errors, notifications and multi-page forms.
- [GOV.UK Service Manual — Measuring the success of your service](https://www.gov.uk/service-manual/measuring-success/measuring-the-success-of-your-service) — Combines performance metrics with user research and recommends multiple data sources.
- [GOV.UK Service Manual — Usability benchmarking a website or whole service](https://www.gov.uk/service-manual/measuring-success/usability-benchmarking-a-website-or-whole-service) — Frames tasks, success, time, abandonment and repeated usability benchmarking.
- [Microsoft Research — Online Experimentation at Microsoft](https://www.microsoft.com/en-us/research/publication/online-experimentation-at-microsoft/) — Explains why randomisation and controlled design are needed to attribute a product effect causally.
- [Microsoft Research — Trustworthy analysis of online A/B tests](https://www.microsoft.com/en-us/research/publication/trustworthy-analysis-of-online-a-b-tests-pitfalls-challenges-and-solutions/) — Documents statistical assumptions and risks that can make A/B-test analysis misleading.

**Method limit:** this application is authored by Edikka. It is not an ISO, W3C, GOV.UK or Microsoft standard and reports no measured Edikka conversion uplift. Version 1.0 reviewed on 4 September 2026. Next review: 4 December 2026.

### Change log

- **1.0 · 4 September 2026:** replaced a standalone rules article with an application of the existing UXUI01–24 matrix; added evidence gates, 24 acceptance shifts and open resources.