Q-Access
Multi-role campus access system
Built a multi-role access system that hit all usability targets. Failed at pricing because we never validated the buyer. Changed how I approach products permanently.
Key Results
What Q-Access Was
An end-to-end access control system for large campuses—universities, corporate parks—designed to make visitor entry fast and simple for every role involved, not just digitize a logbook.
The Problem
Campus visitor entry was slow, expensive, and confusing:
- Guards manually checking visitors, calling inside for confirmation
- Guests getting lost once past the gate
- Admins buried in approvals and spreadsheets
- Staff unable to efficiently invite external visitors
Existing tools focused on badges or security hardware—not on the full experience from invitation to arrival.
What Worked
From a user and UX standpoint, the system delivered:
- Guards could instantly identify visitors and destinations at the gate
- Guests stopped getting lost inside the campus
- Admin approval flow became faster and more consistent
- Staff created invitations without training
The system did what it was supposed to do.
System Design
Four distinct roles, each with different needs and time constraints:
| Role | Primary Action | Constraint |
|---|---|---|
| Staff | Create guest invitations | Minimal friction |
| Admin | Approve/reject invitations | Compact queue, 1-3 clicks |
| Guard | Verify identity at gate | Must work under time pressure |
| Guest | Enter and navigate | Zero learning curve |
Core Flow:
- Staff creates invitation (few fields)
- Admin receives compact queue → approves in 1-3 clicks
- Guest receives QR code with instructions
- Guard scans QR → sees: who, visiting whom, going where
- System shows guest the route from gate to destination
Everything optimized around speed for guards and clarity for guests.
The Hard Lesson: Users ≠ Buyers
Where it broke was pricing.
We had validated the problem and solution with users, but never with the economic buyer. When we finally sat down to discuss price:
- We didn’t know who actually owned the budget
- We had no anchor for what the solved problem was worth
- Conversations stalled—not because of usability, but because we’d skipped the buyer entirely
A product can be well-designed and still be unsellable if you don’t start with the person who controls the money.
Key Learnings
- Users ≠ buyers. Validating usability means nothing if you haven't validated the problem with the person who controls the budget.
- A product can be well-designed and still be unsellable if you skip the economic buyer.
- My default sequence since Q-Access: start with the buyer, sell a minimum showable product, then build a minimum sellable product tied to real willingness to pay.