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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.