# Reusable design prompts

These are **new adaptations** of the method, written for this exercise. The five verbatim historical image prompts are in [prompts/original/](prompts/original/); their required inputs are mapped in [attachments.md](attachments.md). Save a copy of each prompt with its output and your reason for the next revision.

## 0. Establish the task

```text
We are improving [existing product] for [user].
The work they need to finish is [concrete task].
Read the relevant code and previous decisions before proposing changes.
List the available data, constraints and unanswered questions.
Use [ordinary content volume], not only an ideal three-item example.
Do not invent existing capabilities or observed user outcomes.
```

For the supplied exercise: compare twelve fictional films across two exact accounts, then inspect a measurement and its source. The default table aligns each measurement in a column; a compact grid remains an alternative. The fixture is sample-data.json. Its measurements are invented; the task is to evaluate the interface behavior.

## 1. Research through Mobbin MCP

```text
Use Mobbin MCP to find three relevant screens for [task].
Try separate searches for collection scanning, summary-to-detail
hierarchy, and inspection of supporting information.
For each reference save: app, canonical screen link, search query,
one observed pattern, why it helps this task, and what remains unknown.
Treat a screenshot as evidence of a layout. Do not infer that an
interaction works without observing the actual flow.
Return a short reference list that the next design prompt can use.
```

Expected output: a small linked list like [references.json](references.json), with reasons. For another product, choose its own references. Mobbin screenshots are not bundled; obtain references through your own authorized access or use your own screenshots.

## 2. Make competing priorities visible

Attach your starting screen and the references you selected. If working without an existing product, use the exercise as a starting point.

```text
Generate a readable desktop interface concept for the task above.
Use twelve fictional films and the exact field names in sample-data.json.
Make the main assumption explicit: [browsing / comparison / inspection].
Use compact identifiers instead of requiring real film artwork.
Show the full navigation and filters, plus enough ordinary content
to judge density. Mark all numbers as fictional sample data.
Keep text readable at laptop size. This is a visual proposal;
record any interactions or calculations that it leaves unresolved.
```

Run separately with two different priorities, then compare which task each serves. In this exercise, comparison is the chosen priority and the table is the default. The grid alternative lets you inspect the difference between fitting more items and aligning values for comparison. Do not use pixels in a generated chart as numerical evidence; [expected-results.json](expected-results.json) is the calculation reference.

## 3. Turn an objection into a revision

Attach the selected draft. State what should stay and what must change.

```text
Preserve the navigation, search, exact-account filter and sorting.
The main task is comparison. Make the table the default, with
one film per row and consistent columns for title, account,
latest views, runtime watched and shares per 1,000 paired views.
Put shared labels in the column headings and explain scope once.
Keep identifiers compact and unavailable values distinct from zero.
Retain a grid as an alternative, with six columns at a 1440px
desktop width. Explain which task each arrangement supports.
```

For a detail view:

```text
Statistics are the primary task. Give the retention curve and its
measurements most of the workspace. Keep playback compact and
expandable. Allow inspection of the selected metric's definition,
input values and source time. Preserve the task and selected account.
Use the supplied fictional data; do not fabricate an improvement.
```

## 4. Resolve the behavior

```text
Turn the selected direction into a behavior specification.
Define each action, the state it changes, and what survives Back.
Specify loading, empty, failure, missing, unsupported and zero states.
For every rate, name its population, numerator, denominator and
source time. Write one ordinary case and one awkward case with
an exact expected result. Separate observations from assumptions.
Use behavior-spec.md and expected-results.json as a worked example,
not as a production API contract for a different application.
```

## 5. Implement and challenge it

```text
Build the selected direction inside the existing product using
its components and real data paths. Revisit the mockup when those
constraints reveal a better choice, and record why it changed.
Run the acceptance tasks with a keyboard and at supported widths.
Verify the deliverable from its packaged files, not only a dev server.
Report separately: proposed visuals, behavior actually verified,
remaining questions, and whether anything was released.
```

For this small exercise, open index.html and use [the checklist](verification-checklist.md). For your own product, replace the fixture with an adapter to your data and extend the checks to authentication, loading, errors and the actual user task. A successful local exercise does not validate that integration.