DesignDocToUI Negative Case

Overview

Use this skill to create a non-production "negative case" UI package from a requirements document. The package shows how the product could go wrong, why those choices violate the source requirements or user needs, and what a better direction should preserve.

This skill does not replace design-doc-to-ui. It is a lighter contrastive design workflow for critique, training, risk discovery, design reviews, and early prototype thinking. React and Figma are extension targets, not default outputs.

Default Output

Produce a compact package unless the user asks for more:

• source-summary.md: source-backed goals, users, tasks, constraints, pages, and open questions.
• negative-case-map.md: anti-patterns to demonstrate, each linked to source evidence and expected harm.
• prototype.md or static prototype/index.html: screen-by-screen negative-case UI prototype, including flow, layout, content, states, and interaction notes.
• design-notes.md: critique of the negative prototype plus corrected design principles and recommended next direction.
• qa/review.md: traceability, coverage, accessibility, and safety review.

Use the current conversation when no filesystem output is useful. Use files when the user provides a source artifact, asks for a reusable package, or the output is too large for chat.

For the exact output contract, read references/output-contract.md.

Workflow

1. Ingest the requirements document.
2. Summarize the product intent, user roles, top tasks, required pages, key data, constraints, and explicit style or platform signals.
3. Identify 3-7 negative-case themes. Prefer concrete product risks over generic bad UI labels.
4. Create a source-backed negative-case map. Every anti-pattern must cite the requirement, task, or user need it violates.
5. Draft the UI prototype as a coherent product flow, not a random gallery of mistakes.
6. Write design notes that explain why the negative case fails and what the corrected design should do instead.
7. Review the package for coverage, traceability, accessibility, and non-deployability.

Do not collapse the source into one generic dashboard unless the source itself defines a single-screen product. Do not invent pages that are unrelated to the document just to make the negative case more dramatic.

Negative-Case Themes

Choose themes that match the source. Useful categories include:

• Missing or misleading primary task path.
• Overloaded navigation or hidden cross-page relationships.
• Weak information hierarchy, unreadable density, or false visual priority.
• Missing loading, empty, error, permission, offline, or edge states.
• Data model mismatch, stale content risk, or impossible user inputs.
• Accessibility failures such as contrast, keyboard traps, tiny targets, motion dependence, or unclear labels.
• Internationalization, localization, or content expansion failures.
• Trust and safety gaps, especially for financial, medical, legal, identity, privacy, or admin workflows.
• Inconsistent component behavior across screens.

Treat "ugly" as insufficient. A negative case must demonstrate a specific product or user failure.

SubAgent Use

Use SubAgents for long or multi-screen work when the environment supports them and the user has not asked for a sequential run. This borrows the long-task coordination idea from HatchPet without copying its sprite generation workflow.

Read references/subagent-contract.md before spawning workers.

Default division of responsibility:

• Parent agent owns source interpretation, output scope, final integration, user communication, and final QA.
• Source audit worker extracts page inventory, task flows, entities, constraints, and evidence from the document.
• Screen negative-case workers each own one page, route, or tightly scoped flow.
• Critique worker reviews whether the negative prototype is source-backed, useful, accessible, and clearly non-production.
• Prototype worker may assemble static HTML only when the user asks for a runnable prototype.

Keep worker write scopes disjoint. Do not let workers overwrite the final integrated package or each other's files. The parent decides what to accept, merge, revise, or reject.

If SubAgents are unavailable, continue sequentially only for moderate tasks. For large documents or more than 5 screens, tell the user the SubAgent capability is blocked before reducing scope.

Prototype Rules

Create prototypes that are inspectable and useful for critique.

• Use realistic product structure from the source, even when showing a bad design.
• Make each negative choice visible enough to critique.
• Label non-production artifacts clearly in filenames and headings.
• Include critical states, not just the happy path.
• Keep copy in the requested output language. If unspecified, match the source language.
• For static HTML, keep dependencies minimal and avoid framework setup unless explicitly requested.

Do not create deployable dark patterns, scams, coercive consent flows, or unsafe advice interfaces. If the requested negative case touches harmful UX, present it as a warning artifact and include mitigation notes.

Design Notes

The design notes must include:

• A short product reading: what the source appears to ask for.
• The negative-case thesis: what failure mode this prototype demonstrates.
• Screen-by-screen critique.
• Requirement traceability: source point, bad design choice, user impact, corrected principle.
• Accessibility and safety findings.
• Suggested corrected UI direction.
• React/Figma expansion notes only when useful.

Do not present the negative prototype as an acceptable final design.

React And Figma Extension Boundary

This skill may prepare handoff notes for future React or Figma work:

• route map and component inventory for React;
• frame list, interaction links, and design token candidates for Figma;
• asset and state inventory for either target.

Do not implement a full React app or Figma file by default. If the user asks for production React/Figma delivery, switch to the existing design-doc-to-ui skill or explicitly load the relevant frontend/Figma skills for the implementation stage.

Acceptance Criteria

The work is complete when:

• Required pages, users, and tasks from the source are represented or explicitly marked out of scope.
• Each negative-case choice maps to a source-backed risk.
• The prototype is coherent enough to review as a product flow.
• The design notes explain both failure and correction.
• Accessibility, edge states, and safety risks are reviewed.
• React/Figma extension notes are present only as forward-looking handoff guidance unless requested.