EdTech · Enterprise · Assessment
VigiLearn
An exam portal with five objects and no room for error
Shipped without the rebuild that killed the two previous attempts.
Delivered: What shipped. No outcome claimed.
- Role
- Senior Product Designer
- Timeline
- April 2025 to present
- Team
- Design lead across three products
- Platforms
- Web and mobile: EdiifyLMS, Studio, Apply
- Status
- Live
Impact
Junior designers mentored through design reviews on live work
Directional
The problem
Enterprise learning platforms fail in one of two directions. They either grow so many features that nobody can use them, or they simplify until an institution can't run a real exam. VigiLearn's exam portal had to avoid both at once: an assessment engine handling auto-graded, manually-graded, timed, proctored and multi-attempt exams, simple enough for a student who has never seen it, rigorous enough for a university that has been running exams for fifty years. It had been designed twice before I arrived. Both times it fell apart when the edge cases showed up.
What made it hard
- Five objects (Student, Exam, Attempt, Question, Score), where a state change on one cascades through the others. Get a relationship wrong and the error surfaces everywhere at once.
- Learners, instructors and admins each hold a genuinely different mental model of the same exam. It's a thing to sit, a thing to run, and a thing to audit.
- Students take exams on whatever device they own, including low-end Android phones on unreliable connections, and a dropped session mid-exam has real academic consequences.
The decisions that shaped it
With what I turned down, and what each one cost.
01No wireframes until the object model was settled
- Chose
- A full map of objects, relationships, actions and attributes before any interface work.
- Rejected
- Starting from the screens the previous attempts had already produced, which would have been considerably faster.
- Why
- Both earlier versions had missed the same three relationships: how an attempt relates to a question's answer state, how a score relates to an instructor's grading action, and how an exam relates recursively to its own question bank. Those three generated most of the hard interface requirements. Starting from existing screens would have inherited the same blind spots.
- What it cost
- Three weeks with nothing visual to show. That's an uncomfortable thing to defend to stakeholders who have already watched two versions fail.
02Three interfaces reading one data model
- Chose
- Separate views for student, instructor and admin, built on shared data.
- Rejected
- A single exam view with a role toggle, which is what the earlier designs had attempted.
- Why
- The mapping made it obvious these weren't the same object seen from different angles. They're different objects that share a name. A student's exam has a countdown and a submit action. An instructor's has a roster and a grading queue. Forcing both into one layout meant both got a compromised version.
- What it cost
- Three surfaces to design, build and maintain instead of one, and a real risk of drift between them if the design system isn't enforced.
03Every exam state got its own visual treatment
- Chose
- Seven states (draft, published, active, in progress, submitted, graded, archived), each with a distinct appearance and its own set of available actions.
- Rejected
- Grouping them into three broad status categories to reduce visual noise.
- Why
- In an earlier iteration three of these looked identical, so an instructor couldn't tell whether an exam was still being sat or already handed in. That's not a styling problem. Each state needed its own defined attributes and actions before any visual treatment could be correct.
- What it cost
- Seven states is a lot of visual vocabulary to hold, and it needed a documented pattern so engineering didn't invent an eighth.
Delivered
What shipped. No outcome claimed.
- The portal shipped without the rebuild that ended the two previous attempts
- Design ownership across three products: EdiifyLMS, Studio and Apply
- A documented design system covering components, patterns and tokens
What I'd do differently
The most useful thing I did here was refuse to design a screen. That refusal only held because the object map gave me something concrete to point at. Without it I'd have been arguing for a delay on instinct, and I'd have lost. Methodology isn't overhead on a product this tangled. It's the thing that lets you say no with evidence.
What the labels mean
- Measured:
- Instrumented. Number, source and date range shown.
- Directional:
- Observed in practice, not instrumented.
- Target:
- The goal the design was built against. Not yet measured live.
- Delivered:
- What shipped. No outcome claimed.