Design work
Abstract prototypes test structure before surface.
An abstract prototype represents layout, navigation, objects, and interaction flow without committing to final visual styling or implementation technology.
Why Abstract
High-fidelity mockups can make weak interaction structure look finished. Abstract prototypes keep attention on whether the right work is supported in the right way. They make it easier to revise architecture before visual design hardens expectations.
What To Include
- Primary workspaces and their purpose.
- Major interface objects and their relationships.
- Commands or actions needed to complete essential use cases.
- Information required for safe decisions.
- Feedback, status, errors, and recovery states.
- Navigation paths for starting, pausing, resuming, and handing off work.
What To Avoid Early
Brand polish
Color palettes, illustration, and marketing polish can wait until the structure has survived review.
Widget commitment
A dropdown, table, tree, or wizard may be the right solution, but early prototypes should not hide the underlying task decision.
Fake completeness
Do not prototype only the happy path if exception handling carries major design risk.
Untraceable screens
Every screen or major region should map back to a role, a task, or a system responsibility.
Reviewing Abstract Prototypes
Use the prototype as a model inspection tool. Walk through essential use cases and ask where each intention is expressed, where each system responsibility is fulfilled, and where the user receives enough feedback to proceed.
- Select a primary role and one high-value task case.
- Trace the task through the prototype without explaining missing pieces verbally.
- Mark any place where context, status, command, or recovery is missing.
- Repeat with an exception path and a secondary role.
- Revise the model, not just the mockup, when the walkthrough reveals a task misunderstanding.
Fidelity Ladder
| Stage | Question | Typical artifact |
|---|---|---|
| Conceptual | Do we understand the roles, tasks, and objects? | Role map, task model, object sketch. |
| Abstract | Does the interface structure support the work? | Low-detail prototype, wireframe, interaction walkthrough. |
| Concrete | Does the chosen UI pattern work in practice? | Clickable prototype, coded spike, usability test build. |
| Production | Does the delivered system perform under real constraints? | Released software, analytics, support feedback. |