VigiLearn — EdiifyLMS
Enterprise Learning Management System & Exam Portal
Role
Senior Product Designer
Timeline
April 2025 – Present
Platforms
Web · Mobile (EdiifyLMS, Studio, Apply)
Status
Live
Overview
VigiLearn is a UAE-based EdTech platform building institutional learning infrastructure across EdiifyLMS (the core LMS), Studio (content authoring), and Apply (admissions and enrolment). As Senior Product Designer, I own the design vision and execution across all three products — operating at both the strategic and execution layers. The flagship challenge was the v2 Exam Portal: a product with genuine architectural complexity, a 5-object state machine, and real institutional stakes.
The Problem
Enterprise LMS products fail in two ways: they're either so feature-complete they become unusable, or so simplified they can't serve institutional requirements. VigiLearn's Exam Portal faced both risks simultaneously — a complex assessment engine (auto-graded, manually-graded, timed, proctored, multi-attempt) that had to feel simple enough for students who had never used it before and powerful enough for institutions that had been running exams for decades.
Constraints
These constraints shaped every design decision:
Five core objects, each with multiple states: Student, Exam, Attempt, Question, Score. A state change on one object cascades through the others — design errors here propagate everywhere.
Institutional requirements are non-negotiable. Academic integrity, time integrity, and scoring accuracy are regulatory requirements, not preferences.
Multi-role product: Learners, Instructors, and Admins each have fundamentally different mental models of the same Exam object.
The system had to work across devices — students take exams on whatever device they have access to, including low-end Android phones.
My Role
I own the full design vision for EdiifyLMS, Studio, and Apply: product strategy alignment, ORCA system mapping, end-to-end UX design for all core flows, design system definition and governance, interaction patterns, and design reviews. I also mentor junior designers on the team, raising design maturity across the product organisation.
Approach
I opened with an ORCA map — defining the core Objects (Student, Exam, Attempt, Question, Score), their Relationships, CTAs, and Attributes — before any screen design began. The Exam object alone has seven distinct states: Draft, Published, Active, In Progress, Submitted, Graded, and Archived. Each state has different available CTAs, different visible attributes, and different rules for who can see it. Mapping this upfront prevented a dozen downstream design errors. For the multi-role problem, I designed three parallel object models — how a Student, Instructor, and Admin each understand 'an Exam' — before attempting a unified interface.
Key Decisions
Decision 1
ORCA Mapping Before Wireframes
The Exam Portal had been partially designed twice before I joined — both times collapsing under the weight of undiscovered edge cases. I insisted on a full ORCA map before any UI work began. The map revealed three object relationships that previous designs had missed entirely: the relationship between an Attempt and a Question's answer state, the relationship between a Score and an Instructor's grading action, and the recursive relationship between an Exam and its Question bank. These relationships generated the most complex UI requirements. Knowing them upfront prevented the third rebuild.
Decision 2
Multi-Role Object Models Over One Shared View
Early designs tried to build a single 'Exam' view that worked for students and instructors simultaneously — toggling between modes. The ORCA mapping showed this was architecturally wrong. A Student's Exam is a thing to be taken. An Instructor's Exam is a thing to be managed. An Admin's Exam is a thing to be audited. These are fundamentally different object orientations — and they require different interfaces that happen to read from the same data model, not one interface with a role toggle.
Decision 3
State Visibility as a First-Class Design Requirement
Every state in the Exam lifecycle — Draft, Published, Active, In Progress, Submitted, Graded, Archived — needed to be visually distinct and actionable. In an earlier design iteration, three of these states were visually identical. That meant an instructor couldn't tell at a glance whether an exam was still being taken or already submitted. The fix wasn't visual — it was architectural: each state needed its own defined attribute set and CTA set before any visual design could be applied correctly.
Outcome
End-to-end design ownership across EdiifyLMS, Studio, and Apply
v2 Exam Portal ORCA-mapped and designed — handling 5-object state machine without previous rebuild failures
Design system established covering component patterns, interaction standards, and design tokens
Multi-role architecture (Student, Instructor, Admin) clearly delineated at the object model level
Junior designer mentorship raising team-wide UX maturity
What I'd Do Differently
The most important thing I did on this project wasn't design a screen — it was refuse to design a screen until the object model was clear. That refusal, backed by the ORCA map, is what prevented the third rebuild. The methodology isn't theoretical overhead. On a product this complex, it's the only thing that works.