Design: fast high-fidelity mockup + a feedback loop on it (before building, not after) #12

New issue

Open

opened 2026-08-11 14:56:19 +00:00 by jbr870 · 1 comment

jbr870 commented

2026-08-11 14:56:19 +00:00

Owner

The gap

There is no way, anywhere in the loop, to get a high-fidelity mockup of a feature's UI in front of a
human quickly and take structured feedback on it. Today the first thing anyone can actually look at
is the built feature at the UAT gate — after /technical-plan, /develop and the whole QA loop have
been spent on it. Everything before that is prose: the PREQ describes behaviour, the validation cases
describe outcomes, neither shows what the thing looks like.

That makes visual and interaction design the one part of the process with no cheap iteration and no
early gate. A layout or flow that is simply wrong is discovered at the most expensive possible moment,
and the UAT return path then has to walk it back to the PREQ.

Not the same as #6

#6 ("we need a qa-design") is QA of design — did the styling come out wrong, is stuff off, checked
against what was built. This issue is authoring a mockup early to decide what to build before
building it. Opposite ends of the loop, and both are wanted. Related, not duplicate.

Why this is not a text change — the unknowns

What produces the mockup. A rendered HTML page? An artifact? Screenshots driven through a browser?
Something generated against the project's own design system so the fidelity is honest rather than a
generic-looking approximation?
How feedback is captured. Free-text reaction is easy and worthless downstream. It has to land as
something later phases can consume — findings with dispositions, a recorded PREQ amendment, or a
decision — under the same one-record-one-fact discipline as everything else.
Where it sits in the loop. A phase of /requirements (the mockup is part of eliciting what the
human wants), a step between requirements and /technical-plan, or a standalone skill invoked only
for features with a UI surface. Probably needs an applicability test like the observability
policy's — most features have no visual surface, and a mandatory mockup step on an API-only change is
pure friction.
Stack-agnosticism (the hard one). Per this repo's core rule the skill must not name a framework,
component library, or styling system. Anything it renders comes from a project declaration — the
equivalent of a design: block naming where the design system lives and how to render against it —
never a default baked into the skill.
Whether the mockup is an artifact of record. If yes it needs a schema, a producer, and a place on
the issue. If it is throwaway scaffolding, the feedback is the only thing that persists.

Next step: an experimental session, not an edit

Try two or three ways of generating a mockup and reacting to it on a real feature, then decide from what
the friction shows — the way Fork B was closed on Run C's evidence rather than on a guess. Skill text
comes after that.

Source: sdlc-suite-simplification-decisions.md I1.

## The gap There is no way, anywhere in the loop, to get a **high-fidelity mockup of a feature's UI in front of a human quickly and take structured feedback on it**. Today the first thing anyone can actually *look at* is the built feature at the UAT gate — after `/technical-plan`, `/develop` and the whole QA loop have been spent on it. Everything before that is prose: the PREQ describes behaviour, the validation cases describe outcomes, neither shows what the thing looks like. That makes visual and interaction design the one part of the process with **no cheap iteration and no early gate**. A layout or flow that is simply wrong is discovered at the most expensive possible moment, and the UAT return path then has to walk it back to the PREQ. ## Not the same as #6 #6 ("we need a qa-design") is **QA of design** — did the styling come out wrong, is stuff off, checked against what was built. This issue is **authoring a mockup early** to decide what to build *before* building it. Opposite ends of the loop, and both are wanted. Related, not duplicate. ## Why this is not a text change — the unknowns - **What produces the mockup.** A rendered HTML page? An artifact? Screenshots driven through a browser? Something generated against the project's own design system so the fidelity is honest rather than a generic-looking approximation? - **How feedback is captured.** Free-text reaction is easy and worthless downstream. It has to land as something later phases can *consume* — findings with dispositions, a recorded PREQ amendment, or a decision — under the same one-record-one-fact discipline as everything else. - **Where it sits in the loop.** A phase of `/requirements` (the mockup *is* part of eliciting what the human wants), a step between requirements and `/technical-plan`, or a standalone skill invoked only for features with a UI surface. Probably needs an **applicability test** like the observability policy's — most features have no visual surface, and a mandatory mockup step on an API-only change is pure friction. - **Stack-agnosticism (the hard one).** Per this repo's core rule the skill must not name a framework, component library, or styling system. Anything it renders comes from a *project declaration* — the equivalent of a `design:` block naming where the design system lives and how to render against it — never a default baked into the skill. - **Whether the mockup is an artifact of record.** If yes it needs a schema, a producer, and a place on the issue. If it is throwaway scaffolding, the *feedback* is the only thing that persists. ## Next step: an experimental session, not an edit Try two or three ways of generating a mockup and reacting to it on a real feature, then decide from what the friction shows — the way Fork B was closed on Run C's evidence rather than on a guess. Skill text comes after that. *Source: `sdlc-suite-simplification-decisions.md` I1.*

jbr870 referenced this issue

2026-08-11 14:57:36 +00:00

We need a qa-design #6

jbr870 commented

2026-08-25 08:34:30 +00:00

Author

Owner

Candidate mechanism surfaced (2026-08-25, operator note): Claude Code now ships a /design
command (Claude Design canvas, early preview inside Claude Code) — and we have used it. It maps
directly onto this issue's first two unknowns:

What produces the mockup: /design creates a multi-artboard visual design published as an
Artifact running a canvas editor. The model drafts the artboards (UI mockups, screen flows,
landing pages); a human then refines every element visually — click-to-select, properties
panel, inline text editing, undo/redo — and Save publishes a new version for everyone. Where
saving isn't enabled it degrades to a view-and-export (PNG/PDF) preview. That's "fast
high-fidelity mockup in front of a human" with the human able to correct it by hand rather than
by prose round-trips.
How feedback is captured: published Artifacts carry comment threads that are readable
programmatically (and resolvable), so reactions can land as enumerable findings rather than
free-text chat — a plausible bridge to the one-record-one-fact discipline this issue requires,
though mapping comments → dispositions/PREQ amendments is still design work.

Caveats for the eventual PREQ: /design is a Claude Code platform feature (an external
capability, not suite glue) — the skill would invoke it the way domains invoke a browser, and
needs the same applicability test + graceful absence story. The third unknown (where it sits in
the loop) is untouched by this note.

**Candidate mechanism surfaced (2026-08-25, operator note):** Claude Code now ships a **`/design` command** (Claude Design canvas, early preview inside Claude Code) — and we have used it. It maps directly onto this issue's first two unknowns: - **What produces the mockup:** `/design` creates a multi-artboard visual design published as an Artifact running a canvas editor. The model drafts the artboards (UI mockups, screen flows, landing pages); a human then refines every element *visually* — click-to-select, properties panel, inline text editing, undo/redo — and Save publishes a new version for everyone. Where saving isn't enabled it degrades to a view-and-export (PNG/PDF) preview. That's "fast high-fidelity mockup in front of a human" with the human able to correct it by hand rather than by prose round-trips. - **How feedback is captured:** published Artifacts carry **comment threads** that are readable programmatically (and resolvable), so reactions can land as enumerable findings rather than free-text chat — a plausible bridge to the one-record-one-fact discipline this issue requires, though mapping comments → dispositions/PREQ amendments is still design work. Caveats for the eventual PREQ: `/design` is a Claude Code platform feature (an external capability, not suite glue) — the skill would *invoke* it the way domains invoke a browser, and needs the same applicability test + graceful absence story. The third unknown (where it sits in the loop) is untouched by this note.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jbr870/devwork-skills#12

No description provided.

Rows
Columns