# From a recurring problem to a prototype

Pretectal · https://pretectal.com/workflows/idea-to-prototype
Updated October 2, 2026

Use this workbook to make one task easier and test the first version with a person who performs it. Example text describes a possible project, not a measured Pretectal result. Replace it with your own observations.

Project:
Builder:
Version / date:
Person who will try the task:

## 1. Find the friction

Finish the sentence:

When [person] needs to [task], they currently [steps], and the difficult part is [observed friction].

- Trigger that starts the task:
- Current input:
- Current steps and handoffs:
- Desired output:
- What I observed directly:
- What I am assuming:
- What the person doing the task confirmed:
- Current time or error baseline, if observed (otherwise write unknown):
- How the baseline was collected:

Checkpoint: a specific person recognizes the problem and can show you the current process.

## 2. Write the smallest useful brief

- User:
- One task this version supports:
- Input and non-sensitive sample:
- Main action:
- Expected output:
- Required behavior:
- Explicitly outside this version:
- Existing form, spreadsheet, or tool considered:
- Why a custom prototype is worth testing:

### Choose the parts separately

- Interface the person will use:
- Frontend tooling or framework, and the reason for the choice:
- Backend needs, if any (data storage, authentication, server work):
- What can stay local or use sample data for this version:
- Where data would go in a later trial; decisions still needed:
- Does the finished product need an AI feature? Why or why not?

For the distinction between frontend tooling, a framework, and backend services, see https://pretectal.com/ai-tools#stack.

### Acceptance criteria

Write behavior you can observe, not general qualities such as "easy" or "smart."

| Given this input | When the user does this | Expected result | How I will check |
| --- | --- | --- | --- |
| | | | |

Checkpoint: you can explain the complete task without adding another feature.

## 3. Build one complete path

- Coding tool used:
- Brief and sample input supplied:
- Source / project location:
- How to run or preview:
- Known working version before changes:
- Main path implemented:
- Empty state:
- Bad-input message and recovery:
- Limits visible to the person trying it:

### Reusable instructions or skill

Capture repeatable context in a project instruction file or reusable skill. Keep it narrow enough to inspect and update.

- Task it helps with:
- Constraints the assistant must preserve:
- A good example:
- Checks to run after a change:
- Decisions that still belong to the person:
- When the instructions were last checked against the project:

### Build record

| Requested change | AI contribution | Files or behavior changed | What I ran and checked | Result |
| --- | --- | --- | --- | --- |
| | | | | |

Checkpoint: the whole path runs with sample data, and the observed result matches the brief.

## 4. Try it with a person

Give the person a task, not a tour of the interface. For example: "Use these sample project details to prepare a handoff the next person could act on."

- Participant and date:
- Version tried:
- Neutral task instruction:
- Sample input:
- Expected output:
- Incomplete or unexpected input to try:

| What the person did or said | Did the task complete? | Output issue or hesitation | Interpretation to investigate |
| --- | --- | --- | --- |
| | | | |

- Did I need to explain how to finish? Where?
- Does the output meet the acceptance criteria?
- What remains uncertain?

Checkpoint: record the attempt and resulting output. A positive comment alone does not show the task works.

## 5. Choose the next version

- Most important issue:
- One change to make:
- Version after the change:
- Result when the person tries the task again:
- Decision: stop / revise / prepare a limited team trial
- Reason based on observations:
- Remaining questions:
- Next owner and action:

### Prototype handoff

- [ ] Brief and scope boundaries are saved.
- [ ] Source files and run instructions match the saved version.
- [ ] Sample data, expected output, and a failure case are included.
- [ ] User-test observations are separate from assumptions.
- [ ] Known limits and the next decision are written down.
- [ ] The prototype is clearly identified as a prototype.

Before wider use, work through https://pretectal.com/workflows/prototype-to-team-tool.

## Starting prompt

Help me scope a small tool for one recurring task. Use my notes to identify the user, trigger, current steps, input, and desired output. List missing information as questions. Propose the smallest complete path and compare it with using an existing form or spreadsheet. Separate required behavior from later ideas. Write observable acceptance criteria, a sample-data test task, and one failure case. Do not invent user research, savings, integrations, or access I have not confirmed. Do not add an AI feature just because AI is assisting the build. Wait for my choice before generating implementation code.

Task notes and constraints: