BitShovel.One real problem at a time
Open the current workflowCurrent Workflow中文

One real problem at a time

中文

HISTORICAL DIG · JUL—AUG 2026

How do I review an AI-made page before delivery?

Looking “AI-made” is usually only the surface symptom. The expensive failures are a primary action hidden in decoration, long copy breaking the layout, errors with no way out, or a path that fails on mobile or by keyboard. Asking only whether a page looks good misses those breaks.

First recorded · Last public revision · Revision 3
Core taskHierarchy & copyStates & recoveryWidth & languageKeyboard & focus

HOW IT RELATES TO WORKFLOW 001

Relation to the current subject

It finds task breaks before delivery—it does not give AI work a new skin.

This historical record follows the first local-image and AI-output verification Digs. Generation only shows that a page appeared; verification returns to what a person actually needs to finish. Its link to Workflow 001 is methodological: tools can propose changes, but completion, recovery, and delivery still need human confirmation.

Record state at the time

  • AI-made websites
  • AI product prototyping
  • Standard record
  • Developing
  • Historical E1 · current primary sources rechecked · no real-project or user-task outcome

THE GUIDANCE AT THE TIME

Judgment at the time

Treat the page as a route someone must finish, not a poster to score.

Open full rationale and return rules
Treat the page as a route someone must finish, not a poster to score. Give one defined user one believable task, then inspect entry, next step, failure and recovery, and outcome. Deal with stylistic sameness after that. A tool suggestion must map to a locatable break and a retest—not merely “more premium” or “more modern.”
Who it was for
Solo developers and small teams who can generate a page with AI but need a delivery review that does not collapse into endless taste debates
Why it mattered then
Open note

A page opening, a polished screenshot, or a green test suite does not by itself show that a person can complete the task. The later a task, state, or narrow-screen break is found, the more of the page it tends to disturb.

Where the judgment stops
Open note

BitShovel rechecked the current Impeccable repository, W3C accessibility material, and GOV.UK usability-testing guidance, but did not install Impeccable in a real project, recruit target users, or compare task completion before and after changes. W3C material supplies minimum accessibility boundaries and GOV.UK explains task observation; neither proves a particular page is usable.

CHECK BEFORE READING ON

Fit check

The walk matters only when a defined user, one core task, and a reversible preview already exist.

This record may help

  • You have a local or preview page that opens, and can name the most important user and one core task.
  • You are willing to fix at most five locatable breaks before redesigning the entire visual language.

Do not use it yet when

  • The page has no minimum end-to-end route yet, or the core task is still changing.
  • You need formal accessibility certification, security review, legal acceptance, or a large-sample usability finding.
  • You only want an automatic restyle and do not plan to check whether the task becomes easier to finish.

HISTORICAL TRIAL · NO REAL-USER VALIDATION

Historical trial

Use one task that does not reveal the control and walk from entry to outcome.

Time needed
15–25 minutes for one pre-delivery walk
Likely cost
Start manually; buy no design tool or model credits
Permission boundary
Use a local branch, preview URL, and fictional data only; do not publish or enter real accounts or client material
  1. 01

    First step

    Open this step

    Write one task that does not reveal the control, such as “find the current judgment and open one source.” Start at the top and complete it once by keyboard, then repeat at 320 and 1440 pixels in every language the page actually supports. Trigger one recoverable empty or error state; if none exists, record that gap.

  2. 02

    What should exist

    Open this step

    At most five fixes. Each states who stopped where, the screenshot or focus evidence, what to change, and how to retest.

  3. 03

    How to tell it worked

    Open this step

    The core task completes in supported languages at both widths; focus stays visible, failure has text and a next step, and every change can be retested against the same task. Passing this walk does not equal validation with real users.

  4. 04

    Stop when

    Open this step

    Stop when a suggestion says only “prettier” or “more premium” and cannot map to a task, readability, state, narrow-screen, keyboard, or error-recovery break.

  5. 05

    How to back out

    Open this step

    Keep each kind of change separate. If the retest does not improve the task or breaks another language, width, theme, or state, revert that change instead of stacking patches.

BITSHOVEL R3 EXPLAINER · NOT A TOOL INTERFACE

Method and interfaces

The agate line follows one task. Citrine points record only visible, retestable evidence.

Open method boundary

Inspect entry, next step, failure and recovery, and outcome, then repeat on mobile, desktop, in supported languages, and by keyboard. If “more premium” cannot map to a break, it stays in the poster-score lane and out of the fix list.

Five-stop task walkBITSHOVEL R3 EXPLAINER · NOT A TOOL UI
Pre-delivery page-review route from one believable task through entry, next step, failure recovery, outcome, and retests across mobile, desktop, language, and keyboard

The agate line follows one task; citrine points mark observable evidence. The poster-score lane is a stop line: a suggestion that discusses mood without explaining task improvement does not enter the fix list.

About this image and its source

BitShovel explainer created August 15, 2026 from the current public Impeccable scope, W3C reflow/focus/error guidance, and GOV.UK task-testing method. It is not an Impeccable interface, real-user outcome, accessibility certification, or endorsement.

Open source page ↗

SOURCES AND EVIDENCE

Sources and evidence

As of August 15, 2026, one maker repository, three W3C boundaries, and one GOV.UK method can structure the walk. They do not show that BitShovel pages—or any tool—improved user completion.

Open evidence boundary

The historical E1 checked only Impeccable maker material. Revision 3 adds primary W3C and GOV.UK method sources and separates tool vocabulary, technical checks, and real user tasks; there is still no BitShovel outcome data.

  1. 01
    Current maker material · Rechecked

    Impeccable now separates design review into critique, audit, harden, adapt, and other actions

    Open source boundary

    The current repository lists design context, commands, and deterministic detector rules. Its broader scope describes the maker's method; it does not establish real-user task completion.

    Open original source ↗
  2. 02
    Current accessibility guidance · Rechecked

    W3C Reflow: content should not lose information or require two-dimensional scrolling at 320 CSS pixels

    Open source boundary

    This is a minimum accessibility boundary, not a visual-quality score. Complex graphics can have exceptions, while ordinary copy and controls still need to remain readable at narrow widths.

    Open original source ↗
  3. 03
    Current accessibility guidance · Rechecked

    W3C Focus Visible: keyboard users need to see where they are

    Open source boundary

    Visible focus answers where a person is. Order, labels, and whether the action makes sense still need inspection.

    Open original source ↗
  4. 04
    Current accessibility guidance · Rechecked

    W3C Error Identification: errors must identify what went wrong in text

    Open source boundary

    Showing an error does not make recovery clear. The walk also checks the next step and whether retrying preserves completed work.

    Open original source ↗
  5. 05
    Current user-research method · Rechecked

    GOV.UK: observe likely users completing believable tasks rather than asking whether they like the page

    Open source boundary

    A usability finding needs actual or likely users. BitShovel recruited no participants for this record, so it offers a pre-delivery self-check—not user validation.

    Open original source ↗

REVISION RECORD

Revision record

Revision 3 treats the “AI look” as a symptom and puts the real task back at the center.

Open 2 revisions
  1. Revision 2

    Reframed a product-feature assessment as a user decision about pre-delivery design review.

  2. Revision 3

    Treated AI-style sameness as a surface symptom and organized hierarchy, states, narrow screens, language, keyboard, and error recovery around one believable task. Removed three Impeccable images without open reuse rights and used a BitShovel explainer.

    What the record said before
    Before delivery, inspect hierarchy, copy, states, mobile, and accessibility, then decide whether to accept tool suggestions.
    What changed
    Use one believable task to connect every check: where a person enters, whether the next step is clear, how failure recovers, and where the outcome appears. Width, language, and keyboard are different ways through the same route. A style change enters the list only when it can explain a task improvement.

WHAT THIS RECORD LEAVES

What this record leaves

Fix where people cannot continue before debating whether the page looks like everyone else's.

A pre-delivery review does not need a hundred taste notes. It needs at most five issues locatable in a screenshot, focus path, error, or task route—and the same task run again after each change.

Back to the Dig index