YOUR FIRST UX CASE STUDY / LESSON 4 OF 6
Design a small prototype and plan an honest test.
Prototype the critical path, check accessibility intentions, and investigate a focused task without overstating what a small usability session can prove.
Build only what the task needs
Turn the flow into a small set of screens: session browsing, details, review, confirmation, and the unavailable state. Use readable synthetic content rather than decorative placeholders. Keep the finish level consistent so the task, not an isolated polished screen, receives attention. Label the Neighbourhood Classes prototype as fictional and make clear that it cannot create real bookings. Before testing, walk every link yourself and check that a broken connection will not be mistaken for a participant’s difficulty.
Check design accessibility without claiming compliance
Check the contrast of actual text and background pairs, not just your palette. Do not use colour alone to communicate availability or errors. Provide clear labels, visible focus designs, and space for longer text. Annotate intended keyboard order and error behaviour. Figma can express these intentions but cannot establish browser semantics or assistive-technology support. A contrast checker or design review cannot certify accessibility compliance. Record which checks must happen in an implementation and keep any unresolved issues visible beside the prototype.
Write a neutral task and define what to observe
Ask for an outcome without naming the control someone should use. Decide in advance what counts as independent completion, a request for help, or a prototype limitation. Observe actions and explanations without turning your impressions into precise success rates. The task should test a design question rather than encourage praise.
Run sessions only within a safe consent boundary
If you can recruit appropriate adults, explain the study, data handling, observers, recording choice, and ability to skip or stop before starting. Ask them not to enter real personal information. Keep identifying notes and consent records restricted and separate; do not upload sensitive material to public files or unapproved services. During the task, avoid pointing at the answer. Record help you provide and distinguish interface issues from prototype failures. Research involving sensitive contexts or additional support needs may require experienced guidance beyond this beginner exercise.
Make one traceable revision
After any real session, connect each proposed change to an observation, interpretation, and remaining question. Small or convenience samples limit what you can generalise. Without participants, conduct a self-review or peer critique and label it as such; do not call it usability research. Choose one issue to revise, preserve the earlier version, and explain why the change is worth trying. Mark the revised design untested until checked again. Never invent quotes, test completions, or improved outcomes to give the case study a tidier ending.
YOUR TURN / A SMALL, CONCRETE NEXT STEP
Prototype, inspect, and revise one decision
- Build the main path and unavailable state with synthetic content and a fictional-project label.
- Record contrast checks and annotate keyboard and error behaviour that needs implementation testing.
- Write a neutral task; run consented sessions only if feasible, otherwise label your review accurately.
- Save one before-and-after revision with its source, rationale, and untested limitations.
Your deliverable: A small prototype, a task script, an accessibility check list, and a revision note with an honest evidence status.
A personal checklist, not an assessment. Mark it when you’re ready.