Project Overview
TL;DR: ExamSoft's legacy platform had grown one feature at a time into something that no longer held up on either side of the product: the backend couldn't support the features the business needed next, and the front end had never been designed around who was actually using it. This was a full rearchitecture and redesign, focused on the UX research that uncovered where the platform was actually failing users, synthesizing what was learned across personas, and turning that synthesis into intentional design direction the team could build from.
Role: Product Designer, on a team of roughly five designers, a couple of UX researchers, and an engineering team, at ExamSoft, a secure digital assessment platform used for high-stakes exams across law schools, medical and health sciences programs, and professional licensing and certification bodies. The focus was UX research and synthesis, and translating findings into intentional UX design.
The Challenge & Context
The legacy platform had two compounding problems. Underneath, the codebase and backend architecture weren't built to support the features ExamSoft needed to add next, so every new capability meant fighting the foundation rather than building on it. On top of that, the front end had never been designed around who was actually using the product: students taking an exam, proctors monitoring it, and institutional admins configuring and overseeing it all had fundamentally different needs, but the interface treated them as roughly the same problem. That mismatch meant real usability friction for the people who touched the platform every day, on top of a backend that was already limiting what the product could become.
What ExamSoft had wasn't working, and what they wanted to build next didn't have a foundation it could stand on.
The Process & Decision-Making
Work happened closely with ExamSoft's teams in Dallas and Florida, alongside the design team, a couple of UX researchers, and engineering, and an early, deliberate call was made: rather than redesign around the existing front end, it was nuked entirely and rebuilt starting from research. That meant not assuming where the pain was, but going and finding it directly, understanding where users were getting frustrated and why the current system wasn't serving them.
A central finding shaped everything downstream: the old system had never been built around distinct personas, even though the people using it ranged from students under exam pressure to proctors managing live sessions to institutional admins responsible for the program as a whole. Once those personas were identified, the work centered on going back to interview and research each one individually, understanding their actual process end to end and what they liked and didn't like about how things worked today, then synthesizing those findings into patterns the rest of the team could design against.
Take Susan, one of the personas that came out of that research: a university instructor who is simultaneously course coordinator, question writer, exam builder, proctor, and grade poster. Naming that many distinct jobs inside one "user" was the first sign of how much the legacy platform had been treating fundamentally different work as a single flow.
Mapping her actual process end to end, from gathering questions to posting final grades, surfaced the specific friction hiding inside each stage: confusing question editors, no easy way to handle a late student without throwing off the rest of the class, item-analysis reports that were hard to read and easy to forget to act on. Only once there was enough signal like this to make informed decisions did that synthesis turn into low-fidelity design, using early concepts to validate direction with real users before investing in higher-fidelity work.
The Solution & Final Design
- Persona-defined experiences. Distinct flows designed around how students, proctors, and institutional admins actually work, replacing a one-size-fits-all interface with one built for each role's real process.
- Research-validated design, from low-fidelity up. Concepts tested early with each persona before moving to high fidelity, so direction was grounded in real user behavior rather than assumption.
- Full front-end rebuild. The entire front end rearchitected from scratch on a modern foundation, rather than layered on top of the constraints of the legacy system.
- Scalable design system. A shared system built alongside the redesign so new features could be designed and shipped consistently going forward, instead of each addition straining the platform further.
For an institutional admin, that meant a dashboard built around their actual question: which departments and courses need attention, and why.
For an instructor like Susan, it meant a course-level view built around her real cadence: what's due, what's live, and who's falling behind.
And for the specific moment Susan named as a real pain point, reviewing item analysis, the redesign turned a dense report into something scannable at a glance.
The exam-builder flow got the same persona-first treatment, surfacing the settings an exam builder actually needs, scoring, security, and accommodations, without burying them in a generic settings panel.
And for the proctor role Susan also carries, a live view built for exam day: time remaining, download and upload status per student, and a continuation code close at hand.
Impact, Outcomes & Learnings
The result was a platform that looked and behaved like it had been built for the people actually using it, because for the first time, it had been. Students, proctors, and institutional admins each got an experience shaped around their own process instead of a shared compromise, and the new architecture and design system meant ExamSoft could keep building on top of the platform instead of running into the same scaling wall that prompted the rebuild in the first place.
Reflection: This project reinforced how much a persona gap can hide in a system that's been growing for years without one: the old platform wasn't failing because any single screen was badly designed, it was failing because it had never been organized around who was actually using it. It also sharpened the thinking on when a redesign needs to start over versus iterate. Patching the front end onto the same backend would have just relocated the same ceiling; starting from research and rebuilding the foundation alongside the experience was what let the redesign actually hold up under new functionality instead of hitting the same wall again in a year.