Purpose
To plan and document all interaction states for each screen, ensuring user flows remain predictable and resilient.
Table – Multi-State Wireframe Planner
| Screen ID | Screen Name | State Type | Wireframe Reference | System Behavior | Notes / Design Intent |
| WF1 | Dashboard | Empty | Wireframe – Empty Dashboard | Shows blank state | Provide CTA: “Create First Project” with illustration |
| WF1 | Dashboard | Loading | Wireframe – Loading Dashboard | Fetch projects from API | Use skeleton loaders, not spinners |
| WF1 | Dashboard | Success | Wireframe – Project Dashboard | Show project list | Default to most recent project |
| WF1 | Dashboard | Error | Wireframe – Error State | API timeout / failure | Show error message + “Retry” button |
| WF1 | Dashboard | Permission | Wireframe – Restricted Dashboard | User lacks access | Show lock icon + message: “Ask admin for access” |
| WF2 | Booking Form | Empty | Wireframe – Blank Form | No inputs yet | Placeholder text only |
| WF2 | Booking Form | Loading | Wireframe – Processing Submission | Waiting for backend response | Show progress indicator |
| WF2 | Booking Form | Success | Wireframe – Confirmation | Form submitted successfully | Show confirmation + calendar link |
| WF2 | Booking Form | Error | Wireframe – Invalid Input | Validation fails | Highlight fields with inline error messages |
Usage Notes
- Each screen must have at least 3 states: Empty, Success, Error.
- For data-driven screens, include Loading and Permission states.
- States should be documented in this sheet + visualized as wireframes in Figma.
- Keep notes precise — devs should know exactly what happens.