A report such as “the form lost my note” needs a starting state and a sequence someone else can repeat. Before requesting a change, keep the original steps, try a shorter sequence, and record a nearby case that behaves as expected.
This is an optional Part 4 guide in Test the app you built. You will leave with an evidence card and a focused change request for an existing app. Overskill’s editor has an AI Prompt Builder for app changes; the card helps you prepare what to ask and what to check afterward.
Keep the filled example and blank reproduction card beside your app. The worked example below uses four supplied fictional traces. It is not an Overskill template or a customer incident, and no app or repair was tested to produce these outcomes.
1. Fix the starting state
Choose one symptom on one page. Record the app, page, build or revision, and whether you are using a preview or the published app. If the revision is unavailable, write “Unknown.” Add the actor’s role, browser, device, observation date, and relevant starting data.
Write down how to return to that state before each attempt. “Start again” is too vague if one attempt uses an empty form and another restores earlier values. Keep the context the same while you change the steps; record any difference you cannot avoid.
Use sample data you are allowed to inspect. For a local field problem, keep the check on an unsent form. If an action would submit an order, contact someone, or change shared records, use an authorized test path before trying it.
Our fictional bag-request form starts like this:
| Context | Starting value for every supplied trace |
|---|---|
| Revision | R7, a fabricated teaching label |
| Form | Fresh and unsent |
| Category | Tote |
| Instruction | Empty |
| Sizing help | Closed |
| Actor | The same authorized operator |
The example covers these local fields only. It supplies no browser observations, attempt counts, saved records, or network results.
2. State the rule and keep the original sequence
Name the behavior you expect before deciding that an outcome is a failure. Use a requirement the app’s owner can confirm. If the intended behavior is unclear, record that uncertainty rather than silently making the rule up.
The teaching rule is explicit: instruction text is independent of category, so changing category must preserve the exact instruction.
F1 is the original four-action report:
- Open sizing help.
- Close sizing help.
- Enter
Wide blue handlein the instruction field. - Change category from Tote to Pouch.
The supplied result is an empty instruction. That violates the declared rule. Keep all four steps in the card even if some look irrelevant. The help actions happened before the loss; their position in the sequence does not show that they caused it.
For your own app, record the exact visible result and the number of attempts and reproductions. A screenshot can preserve a value or error, but it needs the starting state and ordered steps beside it. Remove private customer details, credentials, and tokens from evidence you share.
3. Remove steps and compare the result
Return to the same starting state. Try leaving out an action, or a small related group of actions, and record exactly what you removed. Keep the remaining order and sample values unchanged.
F2 removes the two help actions from F1:
- Enter
Wide blue handle. - Change category from Tote to Pouch.
The supplied result is still an empty instruction. In this case, the help actions are unnecessary for the supplied failure. F2 gives the next person a shorter sequence to investigate while F1 preserves the original report.
If a shorter sequence in your app does not reproduce the symptom, keep that result too. Return to the longer sequence rather than declaring the removed action responsible. One successful or unsuccessful attempt does not establish how often a symptom occurs.
When a problem is intermittent, retain the actual attempt counts and any differences in starting state. If none of your attempts reproduces it, write “Not reproduced under these conditions.” Do not fill in a successful reproduction to complete the card.
4. Try a nearby comparison
A comparison helps describe the boundary of the symptom. Start fresh again and change one relevant part of the sequence. Here, reversing the two remaining actions and leaving out the category change give different results:
Scroll horizontally to compare all columns.
| Trace | Ordered actions from the same fresh state | Supplied fictional result |
|---|---|---|
| F1: original report | Open help → close help → enter instruction → change category | Instruction becomes empty |
| F2: remove help | Enter instruction → change category | Instruction becomes empty |
| F3: reverse the order | Change category → enter instruction | Instruction remains Wide blue handle
|
| F4: keep category unchanged | Enter instruction only | Instruction remains Wide blue handle
|
F3 is a two-action order comparison. F4 is a one-action comparison with no category change. Together, they narrow this teaching case to entering the instruction before changing category.
F2 is the shortest failing sequence among these four supplied traces. That is the useful, bounded conclusion. The traces do not identify the code responsible, prove a minimum across every possible sequence, or show that other category transitions work.
For your own card, keep the comparison’s actual outcome even if it also fails. A nearby passing case is useful when observed; it must not be invented.
5. Write the existing-app request
Put the page, rule, starting state, ordered actions, and actual result together. Include what you removed, the comparison outcomes, and the behavior the change must preserve. Leave unknowns visible.
Use this structure with your own observations:
On [page and actual revision], start from [recorded state].
When I [ordered actions], I expected [rule] but observed [result].
This occurred in [reproductions] of [attempts], or remains
[not reproduced under these conditions / not tested].
Removing [steps] produced [actual result]. The nearby comparison
[ordered actions] produced [actual result].
Please investigate this behavior. Preserve [the expected rule
and unrelated valid behavior]. After a change, repeat the original
sequence, the reduced sequence and the recorded comparisons.
Record the changed revision, actual results and remaining unknowns.
The reproduction card includes a filled request for the fictional bag form. Replace its context and outcomes before using it for your app. The example asks for instruction retention; it does not ask for a new save flow or an unrelated redesign.
Review your checked request in the affected existing app’s AI Prompt Builder. Getting help in Overskill explains the distinction between that editor tool and Help Chat, which handles support questions. This guide and its card do not select an app, import evidence, send a request, or apply a fix.
6. Recheck the change against the original evidence
Record the actual changed revision. Repeat the original sequence, the shorter failure sequence, and the comparisons from the same starting state. Keep expected and observed results in separate columns.
For the fictional case, the intended after-change result is the exact text Wide blue handle in every sequence:
Scroll horizontally to compare all columns.
| Sequence to repeat on the changed revision | Expected instruction | Actual result |
|---|---|---|
| F1: original four actions | Wide blue handle |
Not tested |
| F2: enter, then change category | Wide blue handle |
Not tested |
| F3: change category, then enter | Wide blue handle |
Not tested |
| F4: enter only | Wide blue handle |
Not tested |
These cells stay “Not tested” until someone records an observation. A builder response or a code change does not establish that the behavior is repaired. If the original failure remains, or a comparison now fails, add those results to the same card before requesting another change.
Keep checks for other behavior with their existing guides: interruption testing covers reloads, retries, sign-in, and saved state; shared-record editing covers people changing the same record. For a broader readability and usability review, use Make an app easier to use.
Choose one symptom in your existing app and fill in the blank card. Take the recorded request and its recheck cases back to that app when the evidence is ready.