# App design review worksheet

Use one worksheet per person, task and starting state. This worksheet is a test plan, not a completed review. Keep fictional data in screenshots and use an authorized app or test copy.

## Define the task

- App / URL:
- Date and app version, if known:
- Person and their job:
- Starting state (signed out / demo / test account):
- Task sentence:
- Observable ending state:
- Reviewer:

## Capture what you can see

- Screenshot or evidence file:
- Viewport / device:
- Actual rendered theme:
- Theme menu selection:
- What is the primary action?
- What information is needed before choosing it?
- Which text, label or control is unclear?

Example screenshot observation: Bookslot's September 9, 2026 service screen groups each sample service name, duration and price. That observation does not establish selection, storage, confirmation or payment behavior.

## Run the checks

Use Pass / Fail / Not tested / Not applicable. Do not convert a screenshot observation into an interaction pass.

| Check | Expected behavior | Observed behavior and evidence | Status |
| --- | --- | --- | --- |
| Next action | Reader can identify the next useful step | | Not tested |
| Decision information | Price, duration, conditions or relevant details are visible near the choice | | Not tested |
| Selected state | Choice is clear without relying only on color | | Not tested |
| Labels and statuses | Intended reader understands the terms and next action | | Not tested |
| Light and dark | Required text and controls remain readable; record doubtful foreground/background pairs | | Not tested |
| Links | Text links are recognizable before hover in each supported theme | | Not tested |
| Theme navigation | Selection and rendered page agree after reload and cross-link navigation | | Not tested |
| Keyboard | Focus is visible; actions and menu exit work without a pointer | | Not tested |
| Phone | Task remains usable with the on-screen keyboard and long sample values | | Not tested |
| Errors and recovery | Error explains a correction and preserves appropriate input | | Not tested |
| Repeat original task | Proposed improvement has not broken the existing journey | | Not tested |

Persistence, private-record permissions, bookings and payments need their own functional checks. A readable screen does not establish those outcomes.

## Request one change

- Observed problem and exact starting state:
- Who it affects and how it interrupts the task:
- Proposed change:
- Information and behavior to preserve:
- Passing check:
- Evidence after the change:
- Still untested:
- Decision: keep / revise / investigate:

For a user observation, record the person's task, pause and expectation without claiming their result represents all visitors. Do not include private account details.

Read the guide: https://www.overskill.com/learn/make-an-app-easier-to-use
Booking workflow: https://www.overskill.com/learn/build-a-service-booking-app
Client-portal checks: https://www.overskill.com/learn/build-a-client-portal