• EdTech
  • Enterprise
  • Assessment

VigiLearn

An exam portal with five objects and no room for error

Role
Senior Product Designer
Timeline
April 2025 to present
Team
Design lead across three products
Platforms
Web and mobile — EdiifyLMS, Studio, Apply
Status
Live
Outcome
Shipped without the rebuild that killed the two previous attempts. Measured

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.

Three decisions

With what I turned down, and what each one cost.

Decision 01

No 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.

Decision 02

Three 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.

Decision 03

Every 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.

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.