Case study
2026
Role: frontend architecture,
interaction design
Internal system
not public
Exam management & proctoring
An internal system I cannot show. I designed and led the frontend architecture, defined the core interaction flows, and implemented the proctoring features on top of browser APIs — so what follows is about the decisions, not the screens.
01. Context
Context
Software people use on their worst day
This one is a closed system, built for a client and used inside their own institutions, so there is nothing to link to and no screens to show. What I can write about is the thinking.
Proctoring software is used by people who are already anxious, on hardware you do not control, over a connection you cannot rely on. A permission prompt that appears at the wrong moment, or a check that fails silently, does not read as a bug — it reads as an accusation.
So the interaction flows mattered as much as the detection did. Where consent is asked for, what happens when a check cannot run, and how a failure is explained all had to be designed, not left to whatever the browser API happened to do.
02. Outcome
Outcome
I defined the frontend architecture and the core flows, then implemented the proctoring features themselves — screen sharing, voice activity detection, face verification — with reliability treated as a usability property rather than a technical one.
The adjacent work was less glamorous and just as useful: going through a complex enterprise system with QA and stakeholders, finding the places where the interface was quietly costing people time, and fixing them.