DELIVERY EXAMPLES / INSPECT THE WORK
A process you can see.
Four populated sample artifacts show how discovery, design, review, and handoff can connect. One fictional purchasing workflow keeps the examples consistent. No client work, completed testing, or live deployment is claimed.
- Discovery
- Prototype
- Acceptance
- Handoff
01 / DISCOVERY
Map the work before the screens.
A sample workflow makes users, decisions, and exceptions visible. This purchasing example defines a first-release boundary and records the approval questions that still need an owner.
Download the populated sample (.md) ↓- DraftRequester prepares the item, quantity, and reason.
- ReviewDesignated reviewer checks context and authority.
- DecisionApprove or return with a recorded explanation.
- Next actionFollow the agreed process; no purchase is issued by this sample.
Clarification path: return → revise → review. Approval authority and revision rules remain decisions to validate.
02 / DESIGN
Review a concrete experience.
A prototype review connects the screen to a task. This static request detail excerpt shows the information hierarchy and the questions a reviewer should be able to answer.
Download the populated sample (.md) ↓Replacement conveyor belt
- Quantity
- 2 EA
- Reason
- Planned maintenance
- Next owner
- Designated reviewer
Review question: is there enough information to make a decision, and is the current revision clear?
03 / BUILD & REVIEW
Define what needs to be demonstrated.
Acceptance checks turn the scope into observable behavior. These are proposed checks for a fictional workflow; they are deliberately marked Not run.
Download the populated sample (.md) ↓On smaller screens, scroll the table horizontally to see every column.
| Scenario | Expected behavior | Status |
|---|---|---|
| Missing required information | Keep the draft and identify the missing field. | Not run |
| Return without a note | Request a note before changing state. | Not run |
| Unauthorized approval | Reject at the authorization boundary. | Not run |
| Phone and keyboard review | Keep the journey understandable and usable. | Not run |
04 / LAUNCH & HANDOFF
Leave an operating record.
A handoff needs more than a download link. This sample identifies deliverables, operating responsibilities, and release decisions that a real project would need to resolve.
Download the populated sample (.md) ↓- What is handed over
- Agreed source, configuration instructions, user guidance, known limitations, and open-item register, as defined for the real project.
- Who operates it
- Identify account owners, user-access responsibility, hosting, backup and recovery ownership before release.
- What happens next
- Record acceptance, release authorization, support coverage, and the next decisions. This sample is not a live handoff.
FROM EXAMPLE TO YOUR PROJECT
The documents should fit the work.
Your proposal defines which artifacts are included, who reviews them, and how acceptance and handoff are recorded. These examples show a possible format; they are not a fixed package or an executed engagement.