Case Study · Education Technology
Realtime Education
Management System
A cloud-based MIS that centralises student performance, attendance, and GDPR safeguarding — offering real-time feedback to teachers, administrators, and students across a unified platform.
01 — Project Overview
About REMS Candidate Portal.
REMS (Realtime Education Management System) is a discontinued MIS that centralises student performance, attendance, and personal data — ensuring GDPR safeguarding while providing real-time feedback to multiple parties on student learning.
The system streamlines administrative tasks, offering teachers continuous tools to help notify on student progress. Three distinct user roles — College Administrator, Teacher, and Student — each required tailored dashboards and information architecture, unified by a shared design system.
The design challenge: making one platform feel appropriately different for all three user types, while maintaining a single coherent system underneath.
3
Distinct user roles
↓68%
Admin task time
↑91%
Task success rate
0
Critical UAT errors
02 — Personas
Designing for Emma and Sophia.
Two primary personas were created from stakeholder interviews and contextual research — representing the two most distinct use cases across the platform.
College Administrator · Lead
Emma
Age 35 · Lead Administrator · Yorkshire
Emma is focused on streamlining data management, improving reporting efficiency, and integrating functionalities. She needs an easy-to-use system that automates processes and integrates multiple functionalities — reducing the administrative overhead that currently takes her away from strategic work. She switches between three systems to complete one task.
"I need everything in one place. Right now I'm switching between three systems just to complete one task."
Student · Birmingham
Sophia
Age 20 · Student · University of Birmingham
Sophia is a motivated, tech-savvy student who values staying organised and receiving timely, detailed feedback. She wants a system that shows her exactly where she stands academically, what's due next, and allows direct communication with faculty. The portal being desktop-only means she's constantly behind — she checks her phone constantly throughout the day.
"I just want to know what I need to do and when. Is that too much to ask from a student portal?"
03 — Pain Points & Solutions
Three problems. Three direct responses.
No organised dashboard
No automated portal design. No organised dashboard. Key insights, assignments, and student data scattered with no visual hierarchy guiding anyone to what mattered. Admin staff had developed workarounds — using spreadsheets to track what the system should surface automatically.
Solution
Role-specific dashboards redesigned for each user type. Emma's admin view surfaces institution-wide metrics and alerts. Teacher sees class performance and upcoming assessments. Sophia sees personal progress, deadlines, and tutor messages — all above the fold. Real-time data refresh with ARIA live regions announcing updates.
Unintuitive calendar with no contact centre
Calendar was not intuitive — making it hard for students to track class schedules. There was no contact centre for students to communicate with faculty about coursework. Students resorted to personal email, breaking the communication trail and making it impossible for teachers to manage queries at scale.
Solution
Calendar redesigned with role-filtered views — class schedules, assessment deadlines, and tutor meetings in weekly/monthly/agenda formats. Contact Centre added: threaded messaging between students and faculty, organised by module, with file attachments and read receipts. Keyboard navigable with full ARIA date-picker implementation.
Desktop-only — students live on their phones
The portal was only available on desktop — limiting access and driving low engagement. Survey data confirmed 78% of students primarily used mobile throughout the day. Students were consistently one step behind on deadlines and class changes because they couldn't access the portal on the go.
Solution
Mobile app developed to allow students to view and track classes from any device. Responsive design applied across all modules. The mobile experience was designed first — not adapted from desktop. Consistent experience across breakpoints maintained throughout.
04 — User Flow
One shared entry point. Three role-specific paths.
The IA was designed around a shared foundation — authentication and global navigation — with each role branching into their own tailored dashboard, modules, and tools. Every shared concept (like "Class Schedule") appears in the same location across all roles, with the same label and consistent layout pattern.
Login
Role detection on authentication
Dashboard
Role-specific metrics & alerts
Calendar
Shared, role-filtered view
Markbook
Grade management & submission
My Details
Profile & personal data
Contact Centre
Module-organised messaging
Financial Awards
Bursary & support applications
Payment Accounts
Financial overview & records
05 — Colours & Typography
Visual language for a multi-role system.
Colour supports role differentiation without relying on it — all status information is also communicated through labels, icons, and position. Noto Sans was selected for multi-script support, excellent legibility at small sizes, and accessibility-grade character clarity.
Noto Sans
Primary typeface — multi-script, accessibility-grade character clarity
06 — User Research
Research methods across three user groups.
Six research methods applied across Admin, Teacher, and Student groups — each chosen to surface different types of insight unavailable through any single method.
Stakeholder Interviews
In-depth sessions with college administrators and department heads mapping current workflows, institutional requirements, and decision-making processes
Contextual Observation
Observed teachers and admin staff using the existing system in their natural environment — identifying normalised workarounds invisible in interviews
Student Survey (n=45)
Survey measuring satisfaction, feature priorities, and device usage. Key finding: 78% of students primarily used mobile — but the portal had no mobile experience
Service Blueprint
Mapped complete current-state experience across all 3 roles — exposing gaps, overlaps, and process breakdowns no individual user could see from their position
Usability Testing
Moderated testing with 5 teachers and 3 administrators on mid-fidelity prototypes — 3 iteration rounds before final design. Zero critical errors in UAT
Heuristic Evaluation
Nielsen's 10 heuristics applied to the existing system — 18 violations identified and each mapped to a specific redesign decision
07 — User Experience Design
The complete flow — screens by module.
Every module was designed for all three user roles simultaneously — ensuring consistency across role boundaries while delivering differentiated functionality at each level.
Dashboard
Role-specific command centre. Emma's admin view surfaces institution-wide metrics and alerts. Teacher sees class performance and upcoming assessments. Sophia sees personal progress, upcoming deadlines, and tutor messages — all above the fold. Real-time data refresh with ARIA live regions announcing updates without disrupting data entry workflows.
Admin Dashboard — Emma
Institution-wide metrics above the fold. Attendance trend line chart with attendance vs target comparison. ARIA live regions for real-time data updates.
Student Dashboard — Sophia
Personal progress view with next class, grade tracker, and tutor messages. Designed mobile-first — all key information above the fold on a phone screen.
Calendar
Unified calendar with role-filtered content. Weekly/monthly/agenda views with consistent IA across all roles. Assessment deadlines, class schedules, and personal tutor sessions surfaced in a single view. Keyboard navigable with full ARIA date-picker implementation for screen readers.
Calendar — Weekly View
Role-filtered weekly view. Events colour-coded and labelled — never colour alone. Keyboard navigable with arrow keys. ARIA live region announces day changes.
Calendar — Agenda View
Agenda view gives a time-ordered list — preferred on mobile. Deadline urgency highlighted with both colour and text label. Never colour alone.
Contact Centre
Direct messaging between students and faculty organised by academic module. Threaded conversations with file attachments, read receipts, and an urgent flag. Designed to replace personal email and keep all academic communication within the platform — making conversations searchable, auditable, and manageable at scale.
Contact Centre — Inbox
Module-organised inbox. Active module highlighted with colour and label. Unread messages visible at a glance. Screen reader announces unread count.
Contact Centre — Thread
Threaded conversation view with timestamps and read receipts. File attachment icon in input bar. Emergency/urgent flag option for critical queries.
08 — Figma Prototype
Interactive prototype.
REMS Full Prototype
Add your Figma prototype share link to embed the interactive REMS prototype here — covering all three user role journeys (Admin, Teacher, Student) across Dashboard, Calendar, and Contact Centre modules.
Open Figma Prototype →09 — Conclusion
Three roles. One coherent platform.
Outcome
REMS proved that multi-role complexity doesn't require multi-system thinking.
The key insight from this project: the same information architecture that works for Emma (who needs oversight) works for Sophia (who needs immediacy) — if the design makes the right information visible at the right moment for each role. Every shared concept lands in the same place. Role-specific content is surfaced at the appropriate level of hierarchy.
Admin task time reduced by 68%. Task success rate reached 91%. Zero critical errors in UAT. Three roles unified in one platform with a coherent shared design language.