The problem they could see and the one that had to be found.
Instituto Cervantes commissioned the conceptualisation of an academic management system to solve a concrete operational problem: teachers and students coordinating classes, schedules and payments without a centralised tool.
I led the 3-person team responsible for research, product specification (PRD and FRD) and usability tests - in a 6-week cycle. My role covered research direction, interface design and, additionally, the design of the system's business logic.
02 - What the system did
Role - Student
Upcoming class management and a centralised dashboard for tracking academic activity. Attendance confirmation within specific time windows.
Role - Teacher
Management of assigned students, classes, rescheduling and pending payments for hours taught. Launch of Google Meet sessions directly from the app.
Business logic designed
The system automatically managed teacher availability through a confirmation scheme with two time windows - 2 days before or 30 minutes before class. If the teacher did not confirm, the system automatically assigned an emergency tutor. This business rule was designed by me as part of the specification - it was not a prior client requirement.
03 - Figma Prototype
Student view
Teacher view
Institution view
04 - Research process
Phase 01Specification
Built the PRD and FRD from Instituto Cervantes' objectives, defining the functional scope before prototyping: class management, payments, rescheduling and the confirmation scheme with emergency tutor fallback.
Phase 02Usability tests
Functional Figma prototype tested with 4–6 real teachers from the institute. I simulated the student role during sessions to evaluate cross-role interactions without depending on a second sample group.
05 - The finding
Impeccable usability. Limited academic impact.
Pilot teachers described the system as functional and intuitive. There was no navigation friction or confusion about how to operate the core features.
But in post-testing interviews, something emerged that had nothing to do with the interface: teachers said the system would improve their organisation but would not allow them to increase their academic workload - meaning it did not solve the underlying reason the institution wanted this tool.
The real diagnosis: the operational model was efficient, but the bottleneck was not in the software - it was in the absence of a person dedicated to administration and support for teachers and students.
"The system solved the problem it was asked to solve. The real problem was different, and it only surfaced after listening to users beyond whether the interface was easy to use."
06 - The recommendation
Don't build yet. Hire first.
Instead of moving to technical development of the LMS, I recommended prioritising an operational change: hire a person to handle administration and support for teachers and students - before, or in parallel with - investing in building the full system.
Recommendation accepted and adopted as launch strategy
07 - Why this case matters
Unexpected finding
Taking seriously a clue that did not fit the plan required going beyond usability testing: reviewing documentation and talking to whoever held the client's strategic context.
Logic as a lens
Designing the system's logic - the confirmation rules, the emergency tutor fallback - trained a wider view of the full operational problem.
Honesty about limits
I could not follow up on the project after the decision was made. That is a real limitation of this case, and I mention it honestly rather than presenting a closure that never happened.
