Skip to content

UI wireframes and annotated screen designs

Design question 4: How does the user interact with the system?

Screen layouts with numbered notes, plus journeys, CLI sessions and chatbot flows.

What it explains and when it is useful

A wireframe is a simple drawing of a screen's layout before it is built. Annotations explain what each part does, which success criterion it serves and how it behaves in different states.

When to use it: Any solution with a graphical interface (web, mobile, desktop, game screens). For text interfaces, use example sessions; for chatbots, a conversation flow (both below).

Worked example

Illustrative: PracticePal is a fictional project used throughout this guide.

Annotated wireframe of PracticePal's week grid on a laptop: week selector, room tabs, a grid of days and 30-minute slots showing free, booked, your own and blocked slots, and a booking panel with the loud-instrument option, weekly counter and an error message areapracticepal.school.org/week?room=P5&w=2026-11-02PracticePal◀ Week of 2 Nov 2026 ▶Maya L. ▾ | My bookingsP1P2P3P4P5 ♪P6 ♪♪ = loud instruments allowedMon 2Tue 3Wed 4Thu 5Fri 612:00BookedBooked12:30BookedselectedYou13:00Booked13:30Booked16:0016:3017:00Blocked17:30BlockedFreeBookedYour bookingBlockedBook this slotRoom P5 (Drum room)Tue 3 Nov, 12:30–13:00Loud instrument (drums, amp)Confirm bookingYou have 2 of 3 bookings this weekError message areae.g. “Not booked: P6 next doorhas a loud booking at 12:30.”Join waiting list(only shown when the slot is taken)1234567
Annotated wireframe: the week grid on a laptop.

Scroll sideways to see the whole diagram.

#ElementBehaviourSC
1Week selectorCurrent and next week only; arrows disabled beyond thatSC2
2Room tabs♪ marks rooms that allow loud instrumentsSC2, SC6
3GridFree / booked / your booking / blocked, never names of other studentsSC2
4Selected slotOne tap selects; the panel fills inSC3
5Weekly counterUpdates after each booking; “3 of 3” disables ConfirmSC5
6Error message areaShows the reason from make_bookingSC4–SC6
7Join waiting listOnly when the slot is takenSC7
Annotated phone wireframe of PracticePal's My bookings screen: an offer banner for a freed slot with a countdown, booking cards with Check in and Cancel buttons, and a bottom menuMy bookingsA slot opened for youP1 · Thu 5 Nov · 16:00Accept14:52 leftP5 · Tue 3 Nov · 12:30Starts in 4 minCheck inCancelP2 · Wed 4 Nov · 13:00Check-in opens 12:55CancelP5 · Fri 6 Nov · 16:30Loud instrumentCancelWeekMineOffersLog out1234
Annotated phone wireframe: My bookings, with an offer banner and check-in.

Scroll sideways to see the whole diagram.

#ElementBehaviourSC
1Offer bannerCountdown from 15:00; disappears when accepted or expiredSC7
2Check inActive from 5 min before to 10 min after the startSC8
3Booking cardRoom, day, time and a status lineSC2
4Bottom menuSame four places on every screenSC3

User journey diagram

User journey for a student booking a practice room: from opening the link to checking in, with the screen used and the requirement each step supportsOpen linkLog in screenSC1Pick room + weekWeek gridSC2Tap free slotBook panelSC3Confirmrules checkedSC4–6Get resultBooked / reasonSC3–6Arrive, check inMy bookingsSC8Pain point found while observing the paper sheet: students could not see free slots until they reached the music office.Design response: the week grid is the home screen and works on phones (SC2).
A student's journey from opening the link to checking in.

Scroll sideways to see the whole diagram.

Command-line interaction example

Alternative scenario. A text-based version of PracticePal for a terminal.

$ python practicepal.py
PracticePal  ·  logged in as u381 (Maya L.)

> book P5 2026-11-03 12:30 --loud
Not booked: noise clash with P6 (loud booking 12:30–13:00).

> book P5 2026-11-03 13:00
Booked P5, Tue 3 Nov 13:00–13:30. You have 3 of 3 bookings this week.

> book P1 2026-11-05 16:00
Not booked: weekly limit (3) reached.

> book P9 tomorrow
Unknown room 'P9'. Rooms: P1 P2 P3 P4 P5 P6.
Usage: book ROOM YYYY-MM-DD HH:MM [--loud]

Conversation flow for a chatbot

Alternative scenario. A chatbot that books rooms.

Conversation flow for an alternative scenario, a chatbot that books practice rooms: the bot asks for a room and time, validates the answer, re-asks on invalid input and confirmsBot: Which room?lists P1–P6User replies“drum room”Valid room?match code or nameBot: Which day and time?suggests 3 free slotsBot: I don't knowthat room. Try P1–P6Free + rules pass?same rules as the web appBot: Booked P5, Tue 12:30 ✓Bot: Taken. Join waiting list?yesnore-askyesno
What the bot asks, how it validates replies and how it recovers.

Scroll sideways to see the whole diagram.

Notation and legend

Symbol or partMeaning
RectanglesAreas of the screen (no real colours or images needed)
ShadingState: booked, yours, selected
Dashed boxSpace for something that appears only sometimes (errors)
Numbered circlesAnnotations explained in the table

Design decisions it communicates

A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:

  • The booking panel is on the same screen as the grid to keep booking to three taps (SC3).
  • Other students' names are never shown, only “Booked” (privacy).
  • Errors appear in a fixed area so the user always knows where to look.

Common mistakes

  • Only input screens: the exemplars were told to model outputs too.
  • No annotations, so behaviour is unclear.
  • Screenshots of the finished product presented as design (design comes first).
  • Every screen drawn; pick the important ones.

Checklist for your own version

Ticks are saved in this browser only, so you can use the list while you draft.