UXR Lab &
Hardware Prototype
How do you validate an experience that doesn't exist yet?
Client
Glydways
Role
Principal Design Technologist
Type
UX Research · Hardware Prototype
Stack
Arduino · iOS · Linux · WebSocket · M5Stack · ElevenLabs
01
The Question
Autonomous transit is a new category. You can't do a usability study of something that doesn't exist yet, and you can't design for a rider experience by looking at what competitors have built. The research problem is: how do you generate real data about a hypothetical experience?
Borrowing the real thing was not an option either. Vehicle hardware came online in pieces and belonged to engineering for engineering's validation; a research schedule built around borrowed access would have run a handful of sessions a quarter, if that.
So the answer was to build a physical approximation the design team owned — a multi-modal lab environment that could reproduce the sensory conditions of a pod ride closely enough to surface real rider responses, and could be run on any afternoon without asking anyone.
“You can't usability-test something that doesn't exist — and you can't wait in line for it either. So we built a close-enough version we controlled.”
02
The Rig
iOS Controller
Orchestrates state transitions · Sends WebSocket events to all connected devices
Arduino
LED lighting control · Receives state and drives interior + exterior color/brightness
M5Stack Display
In-cabin display surface · Shows UI states synchronized to ride phase
Linux Audio
AVAS playback · AI voice interaction via ElevenLabs TTS pipeline
Every surface answers one event. A tap on the NFC reader — or a state fired from the iOS controller — moves the whole bench at once: the display cluster changes together, the LED strip shifts colour, the audio channel follows. Boarding, in-transit, arrival, emergency.
Bench rig — one state event across displays, lighting, and NFC boarding
That is what made structured UXR sessions possible: participants met a coordinated multi-modal response at real brightness and real volume, not a screen prototype of one.
What the bench cannot do is scale. One pod, one context, no fleet and no street. That half of the picture was built in UE5 and walked in VR — the multi-surface system at scale, where continuity is bought back at the cost of fiction.
03
In-Cabin Intelligence
Designing an LLM-driven audio interaction system for a context where the rider may be anxious, disoriented, or non-verbal. The system needed to read journey state and respond appropriately — not just answer questions.
Multi-agent architecture with ElevenLabs TTS, tuned for acoustic comfort in a small enclosed space. Deliberation is audible — the system thinks out loud at a volume and cadence matched to the environment.
In-cabin display — journey state (Civic Center)
04
What We Learned
Acoustic environment dominates
Participants consistently cited sound before visual feedback when describing their comfort level. Audio sequencing became a primary design constraint, not a secondary one.
State transitions need anticipation
Sudden state changes — even positive ones like arrival — caused anxiety. A 2–3 second anticipatory cue before each transition measurably reduced stress responses.
Physical props outperform screen prototypes
Participants suspended disbelief much more readily in the physical rig than in any screen-based simulation. Embodied experience generates qualitatively different feedback.
Next project
Hyphen — Director of DesignHMI for a robotic kitchen