Miles is a voice-based driving companion that learns from a driver's behaviour and offers context-aware recommendations before being asked. It came out of a five-week sprint in my Interface Design course at SFU, where I identified the problem space, ran the research, and designed and prototyped the solution around distracted driving.
Originally built under the name Copilot, before I knew Microsoft had shipped a product by that name. The case study uses Miles, which is what the assistant itself is called.
“The current driving assistant I use (Android Auto) is still not great. If I receive several messages in a row, it only displays the most recent one and I can only see all of them through text to speech. Sometimes I ask it a question too and it straight up can't answer me.”Anonymous interviewee (2024)
Current systems rely on rigid commands, memorised phrases, and repeated confirmations. Drivers switch between screens, repeat themselves, and adjust their wording to match what the system expects. Siri and Google Assistant handle isolated actions reliably, but interaction stays command-driven: follow-up questions reset context, multi-step tasks need repeated confirmation, and a request outside the predefined structure fails or pushes the driver to a screen. They execute tasks rather than interpret intent across a journey, so the driver is still managing the flow.
A voice-first companion that adapts to natural speech, holds context across a trip, and stays present without pulling eyes off the road.
I used Nielsen's heuristics as constraints rather than sketching screens at random.
Visibility of system status shaped how confirmations appeared, match between system and real world guided conversational tone, and error prevention informed how misheard commands were handled. From there I mapped three flows: starting a task while driving, handling a multi-step request across a trip, and recovering from a misunderstanding mid-interaction. Mapping them exposed the friction points early and defined what the first version had to support. I prototyped the MVP in Protopie and put it in front of users.
After making the first MVP, I ran a UI heuristics evaluation with 5 users and got them to do think-aloud testing, which drew out 3 insights that drove MVP 2's design decisions.
The problems I thought were visual were structural.
I spent the first MVP on interface polish with spacing, states, interaction detail. Testing showed that none of what confused people was visual. The assistant felt disconnected because its architecture was unclear, and the metrics felt meaningless because the terminology had no framing. Both fixes were structural, and no amount of visual refinement would have surfaced either one. I now test for root causes before I refine surfaces.
I’m a designer that enjoys decomposing messy things into their real structure to help me find thoughtful ways to create meaningful experiences. By taking things into my chaotic brain, I get the pieces mapped to its parts refining it until it’s precise and intentional.
Outside of design, I love a good night out with friends (usually being the photographer), but most of the time, I am either driving my 86 around Vancouver doing random side quests (or looking at cars), dancing around at raves (if you can call it dancing), or eating food on a random 2am night (I love food).