QueueLess
A mobile queuing experience designed to reduce uncertainty, unnecessary waiting, and crowded service locations.
- Role
- Sole designer — research framing, flows, wireframes, UI, prototype
- Discipline
- UX design · UI design · Prototyping
- Platform
- Mobile app (iOS & Android concept)
- Tools
- Figma, Auto Layout, Interactive prototyping
Designed end to end and tested informally. Usability findings changed the design; no quantitative metrics were recorded.
projects/queueless/cover.pngOverview
Context
Clinics, government offices, banks and service counters in Lebanon still run on physical presence. You take a paper ticket, or you take a chair, and then you wait without information.
Problem
The cost of queuing is not only the wait — it is the uncertainty. Because nobody can see how long a queue really is, people arrive far too early, stay in the room to avoid losing their place, and the space fills up with people who did not need to be there yet.
Objective
Let someone join a queue from wherever they are, watch it move in real time, and arrive when they are actually needed.
What I did
- Framed the problem and mapped the end-to-end service journey
- Designed the flows, information architecture, and screen states
- Built the UI system and the interactive Figma prototype
- Ran informal usability sessions and reworked the design from what they showed
The challenge
A queue is a shared resource that nobody can see.
Every person in a waiting room is solving the same problem alone: am I about to be called, or do I have an hour? With no answer, the rational move is always to show up early and stay put. Multiply that by everyone, and the room fills with people whose turn is nowhere near.
The people this hits hardest are the ones with the least slack — someone taking unpaid hours off work, a parent with a child, anyone travelling in from outside the city for a single appointment. A wasted morning is not a minor inconvenience for them.
So the design problem was never build a ticket dispenser in an app. It was: what has to be true for someone to feel safe leaving the room?
Research and discovery
Grounded in observed behaviour, not a survey.
This project began from direct observation of how queuing works in local service locations, and from the behaviour the existing system produces: early arrival, physical place-holding, and repeated checking with staff.
No formal interview programme, survey, or quantitative study was run for QueueLess. Rather than dress up the discovery phase, the design brief was built from what could be observed and reasoned about — and the assumptions that came out of it were then tested against the prototype.
The assumption that mattered most: people will only leave a queue if leaving cannot cost them their place. Everything else in the product follows from that single condition.
What shaped the design
Four conclusions that each changed a screen.
- 01
Uncertainty costs more than waiting
An hour you can plan around is tolerable. Twenty minutes of not knowing is not. The interface leads with position and progress, not with a promise about saved time.
- 02
Leaving must be safe, and obviously so
If there is any doubt that stepping out could forfeit your turn, nobody steps out and the product has achieved nothing. Queue position is persistent, visible, and never silently lost.
- 03
Choosing where to go is part of the wait
When two branches offer the same service, the shorter queue is the better product. Comparison had to sit before joining in the flow, not be buried in a settings screen.
- 04
The last five minutes are their own problem
Knowing you are next is useless if you do not know which door, which floor, or which counter. Arrival guidance is a distinct step, not a footnote on the tracking screen.
The core journey
Six steps, each one reversible except the last.
- 01
Discover
Find services nearby, with current queue conditions surfaced on the list itself rather than one level down.
- 02
Compare
Weigh branches against each other on the two things that actually decide it: how far, and how long.
- 03
Join
Take a place in the queue remotely. Confirmation states exactly what has been secured, before anything else.
- 04
Track
Watch the queue move in real time, with position and progress always on screen — no refresh, no re-checking.
- 05
Leave
Step away with the place held. The state travels with the person instead of with the chair.
- 06
Arrive
Get called back in time, with directions to the specific counter or room, not just the building.
Wireframes and exploration
Structure resolved in low fidelity, before any colour decisions.
projects/queueless/wireframes-discover.pngprojects/queueless/wireframes-tracking.pngKey design decisions
Each of these had a credible alternative that was rejected for a reason.
Show queue position, not a countdown clock
- Evidence
- A precise “12 minutes remaining” is a promise the system cannot keep — one slow appointment breaks it, and a broken estimate destroys trust in everything else on screen.
- Alternative considered
- A live countdown timer as the primary display.
- Decision
- Position in the queue is the hero, with a time range as clearly secondary supporting information.
- Trade-off
- Less immediately satisfying to read, but it degrades honestly instead of becoming a lie the moment reality slips.
One primary action per screen state
- Evidence
- Testing showed people hesitating when leaving, cancelling, and rescheduling were presented with equal weight — the destructive option looked exactly as inviting as the safe one.
- Alternative considered
- A row of equally weighted controls covering every possible action.
- Decision
- A single dominant action per state, with secondary and destructive options demoted and visually distinct.
- Trade-off
- Less powerful for the rare expert user; considerably safer for someone acting quickly in a waiting room.
Comparison before commitment
- Evidence
- If the app only lets you join the branch you already chose, it has automated the ticket but left the actual decision — where to go — unsupported.
- Alternative considered
- Join first, switch later.
- Decision
- Comparison is a first-class step, sitting between discovery and joining.
- Trade-off
- Adds a step for someone who already knows where they are going, mitigated by making it skippable.
Arrival treated as a separate stage
- Evidence
- Being called is not the same as knowing where to go. The gap between the two is where a saved wait gets spent anyway.
- Alternative considered
- Fold directions into the tracking screen as supplementary text.
- Decision
- A dedicated arrival state with location guidance and the specific counter.
- Trade-off
- One more screen in the journey, at the point where clarity matters most.
The final experience
The flow as it stands: discover, join, track, arrive.
projects/queueless/final-discover.pngprojects/queueless/final-join.pngprojects/queueless/final-track.pngprojects/queueless/final-arrive.pngVisual system
Built to stay legible in a bright waiting room, at arm’s length, in a hurry.
Typography
- One sans-serif family across the product, with weight — not colour — carrying hierarchy
- Queue position set at display scale: readable at a glance without focusing
- Metadata held at a consistent small size so it never competes with the number
Colour
- A restrained neutral base, so status colour means something when it appears
- A single accent reserved for the active queue state and the primary action
- Status never carried by colour alone — every state also has a label and an icon
Components
- Service row: name, distance, and live queue condition in one scannable unit
- Queue card: position, progress, and the single primary action for the current state
- Status pill: reused across joined, waiting, called, and completed states
- Action bar: one dominant control, with secondary actions visually demoted
Interaction states
- Every interactive element specified for default, hover, focus, pressed, and disabled
- Loading and empty states designed rather than left to chance
- Destructive actions such as leaving a queue always require explicit confirmation
Testing and iteration
Three problems the prototype exposed, and what changed because of them.
Timing logic did not hold up. The earliest version implied a precision the underlying system could never deliver. It was reworked so that position leads and time is expressed as a range — a claim the design can actually keep.
Competing actions caused hesitation. Presenting several actions at equal weight made people stop and re-read, particularly around leaving a queue. Each state was reduced to one clear primary action, with everything else stepped down.
Labels were read differently than intended. Wording around joining, holding, and leaving a place was ambiguous enough that people were unsure what a tap would actually do. The terminology was rewritten to describe the outcome, not the mechanism.
These sessions were informal. No participant count, task completion rate, or timing data was recorded — so this section reports what changed and why, rather than a number that was never measured.
Outcome and reflection
QueueLess resolves into a complete, coherent mobile flow: someone can find a service, compare where to go, take a place remotely, watch it move, step away safely, and be guided back at the right moment.
What I would take further: the design assumes a service provider willing to expose live queue data, and that assumption deserves its own validation. I would also want to design the failure cases more thoroughly — what the experience does when the connection drops, or when an estimate is badly wrong.
What it taught me: the strongest decision in this project was subtracting precision. Choosing position over a countdown made the product less impressive to demo and considerably more trustworthy to use, and that is a trade I now look for deliberately.
Contact
Have a product idea worth shaping?
I’m open to UI/UX and product design roles, and to freelance design and frontend projects. Tell me what you’re working on.