Teacher Portal

400 helpdesk calls a month, and most of them came from teachers

The previous version of the learning management system was being used by hundreds of teachers across vocational schools in the Netherlands. They were also calling the helpdesk constantly. Not for student questions, but to figure out how to set up their own courses. How to add a course item to a variant. How to give a different scoring scale to one group of students and another to a parallel group. How to find a single student in a class with three different cohort years in it.

The student side of the product had real UX problems, and those got the most visible attention in the redesign. But the teacher side was where the real complexity lived. And it was where the product was losing schools, because if a teacher cannot set up a course, the school cannot use the system at all.

Stop measuring what is easy. Start measuring what is hard to argue with.

The student-side work measured the obvious things: task time, navigation success, helpdesk volume. Those numbers told the right story for that audience. They were not going to work here. Teacher tasks are not three-second tasks. They are multi-step workflows that span weeks, sometimes a full term. Measuring them needed a different approach.

So the research methods on this side of the project were chosen specifically to make the complexity visible. Contextual inquiry to see teachers in their actual classrooms, not in a lab. Diary studies across a full term, because the rhythm of vocational teaching has seasons that a two-week test cannot capture. Cognitive walkthroughs to score how much each task asked of a teacher's working memory. Helpdesk ticket categorisation to turn flat call volume into something you could actually act on.

Watching teachers work, not asking them to describe it

Contextual inquiry

I spent time in two schools observing teachers during their actual workdays. Not in a meeting room with a prototype. In the staff room between classes, on shared computers with five-minute windows of time, with students walking in to ask questions over their shoulder. That is the environment the product has to work in, and watching a teacher try to update a scoring domain in a four-minute window between two classes told me more than any usability test in a clean lab ever could.

Contextual inquiry was the right method here because vocational teaching has a particular rhythm. Teachers are not knowledge workers sitting at a desk for eight hours. They teach a class, walk to another room, find a shared computer that someone else is logged into, fix something in the platform, walk back. The system has to work inside those gaps. Asking a teacher to describe that workflow does not capture it. You have to see it.

I sat with five teachers across two schools, in three observation sessions each. The first session in each school was just watching. No questions. No prompts. The next two sessions I asked questions during natural pauses, mostly clarifying questions about decisions they had made without thinking. Those unconscious decisions were the most useful data. They were the things teachers had stopped explaining to anyone, including themselves.

Diary studies across a full term

The contextual inquiry sessions told me what one teacher's workflow looked like on one day. Diary studies told me what teaching looks like across an entire term. I recruited four teachers (two from each school) to log their interactions with the platform for one full term. Short entries, two or three minutes per day, focused on what they had tried to do, what worked, what did not, and what they had given up on.

Diary studies are expensive. They take months. They produce messy data. They are also the single best method for surfacing problems that controlled testing cannot reach. Vocational teaching has its own seasonal rhythms, and each season stresses a different part of the platform.

Two findings from the diary study shaped the entire teacher-side redesign. First, the cohort year problem, Variant 2025 students alongside Variant 2026 students in the same class, was not an edge case. It was happening in roughly a third of the classes I tracked. Second, teachers were quietly abandoning features they had given up on, not because the features did not work, but because they could not remember how to find them. That is a UX problem, not a feature problem. It changed the priority list.

Stakeholder interviews

Eight interviews. Five teachers, two school administrators, one product owner. Each interview was structured around three questions: what does this system make easy that you wish it did not, what does it make hard that should be easy, and what would have to be true for you to recommend it to a colleague at another school.

The third question gave me the most. People will tell you what they hate. They are slower to tell you what would make them advocate for something, and that gap, between not-hated and actively-recommended, is the gap a redesign actually has to close.

Testing the redesign on the rhythm it had to survive

Two waves of testing, plus post-launch monitoring.

Wave 1: Prototype testing with task scenarios

Six teachers, three from each school, working through realistic task scenarios on a Figma prototype. Each session was 90 minutes, structured around three scenarios: setting up a new variant for a class with mixed cohort years, configuring a non-standard scoring domain, and finding a single student's progress in a class with three different variants. Think-aloud throughout, with minimal interruption.

Two findings from this wave changed the design. First, the scoring domain switcher was unclear. Teachers understood that they could change it, but several missed that the change applied per variant rather than per course. We added a confirmation step and a small explanatory line that tested cleanly in wave 2. Second, the bulk operations were powerful but invisible. Teachers did not discover them unless prompted. We added a bulk-mode toggle that surfaces the operations explicitly, which lifted discoverability significantly.

Wave 2: A/B testing on the live system, post-launch

After launch, we ran an A/B test on the variant tree's default state, comparing fully expanded against collapsed-by-default. The collapsed version produced 24% faster task completion for teachers managing courses with more than ten variants, and showed no measurable difference for smaller courses. We shipped collapsed-by-default for trees over a certain size.

Post-launch: helpdesk ticket categorisation

This is the method I would most strongly recommend to anyone redesigning a B2B tool. Helpdesk tickets are an unfiltered view of where the product is failing in production. Pre-launch and post-launch, I categorised every teacher-facing ticket for one term into themes: variant setup, scoring configuration, student lookup, group management, other. The shift in those categories before and after launch is the strongest evidence the redesign worked.

How the numbers were measured

Every metric in this case study is the result of a deliberate methodological choice. This appendix documents how each headline number was produced, what method generated it, and why I trust it. If a number cannot survive this kind of scrutiny, it should not be in a portfolio.

This level of transparency is unusual to include in a case study. I include it because the methods I chose are at least as much of the work as the numbers they produced, and because a hiring manager who asks 'how did you measure that?' deserves a real answer, not a deflection.

38% drop in teacher helpdesk tickets about variant setup

Method: Helpdesk ticket categorisation across two terms (one pre-launch, one post-launch). I categorised every teacher-facing ticket into themes (variant setup, scoring configuration, student lookup, group management, other) and tracked the volume in each category before and after launch. The 38% headline is the weighted average across all teacher-facing categories. The variant setup category alone dropped 81%, but other categories moved less, which is why the headline number is lower than the most dramatic individual line. Reporting the weighted average rather than the best-performing category keeps the claim defensible.

6 minutes variant setup time, down from 22 minutes

Method: Time-on-task measurement during prototype testing (wave 1) and a follow-up timed study post-launch. Six teachers each completed the same variant setup scenario on the old and new systems, with task time captured by stopwatch. The 22-minute baseline came from a pre-redesign cognitive walkthrough where I worked through the task on the production system, cross-referenced against diary study entries where teachers had logged the duration of similar setups. The 6-minute post-redesign number is the median across the six prototype testing participants. I report the median rather than the mean because one participant in wave 1 was unusually fast and another unusually slow, and the median is less misleading.

62% of teachers using bulk operations weekly

Method: Product analytics across the first full term post-launch. Tracked via event analytics on bulk-operation interactions (bulk delete, bulk add, bulk move). 'Weekly active' was defined as 'used at least once in a calendar week.' The 62% figure represents the average weekly active rate across the term, not a peak. Adoption depth metrics matter more than raw adoption rate because a teacher who logs in but never uses the feature designed to save them time is a worse outcome than a teacher who uses it regularly. The 62% sits in the middle of the typical 50 to 70% range for B2B feature adoption when the feature solves a real problem.

Teacher SUS score, 3.1 → 4.4 (out of 5)

Method: System Usability Scale survey, distributed pre and post-redesign to teachers using the platform. I used a 5-point SUS adaptation rather than the standard 100-point version because vocational teachers are not survey enthusiasts and shorter scales improve response rates in this audience. Pre-redesign, 14 teachers completed the survey. Post-redesign, 19 teachers completed it. The pre-score of 3.1 is higher than the student pre-score (2.8) because teachers had built more workarounds and were less acutely frustrated than students were. The post-score of 4.4 is just below the student post-score (4.5), which reflects that teacher tasks remain inherently more complex even after a good redesign.

81% drop in variant setup tickets specifically (167 → 31 per term)

Method: Direct count from the helpdesk ticketing system, filtered by category. This is the cleanest number in the case study because it is a direct count rather than a measurement. Pre-launch term: 167 tickets categorised as variant-setup-related. Post-launch term: 31 tickets in the same category. The category definition was kept identical across both terms (I wrote the categorisation rules before launch to avoid post-hoc reframing). I report this number alongside the headline 38% because the category-level data is what makes the headline credible.

24% faster task completion on collapsed-by-default variant trees

Method: A/B test on the live system, two-week window, randomised assignment. Test was limited to teachers managing courses with more than ten variants, since the design hypothesis was specifically that the default state mattered for large trees. Sample size: 47 teachers in the experimental group, 44 in the control. The 24% improvement was significant at p < 0.05. For courses with ten or fewer variants, the test showed no measurable difference between conditions, which confirmed the redesign should be conditional on tree size rather than blanket.

Onboarding cut from 4.5 hours / 3 sessions to 1 hour / 1 session

Method: School administrator self-report, gathered via follow-up interviews two terms post-launch. This is the softest number in the case study. It comes from interviews with three school administrators reporting on their experience onboarding new teachers, not from a controlled study. The 4.5-hour baseline is an average of their estimates of pre-redesign onboarding time. The 1-hour figure is also an average. I report it as a directional metric rather than a precise one because that is what it is. Including it because the magnitude of the change was consistent across all three administrators, and because qualitative methods produce qualitative metrics, not precise ones. Pretending otherwise would be worse than admitting the methodology.