Diagnosing a legacy education platform without direct user access

How I turned recurring support complaints into a structured usability diagnosis and a roadmap for future research and product improvements.

  • UX Research
  • Heuristic Evaluation
  • Legacy SaaS
  • Facilitation
  • Research Strategy
01

Project snapshot

A quick overview of the product, the constraints and the shape of my contribution.

Product
Web-based SaaS platform for public education institutions
Sector
EdTech · Public education
Primary users
Teachers and education professionals
My role
Product Designer & UX Researcher
Methods
Support evidence review · Heuristic evaluation · Task scenario definition · Collaborative workshop · Findings synthesis · Research roadmap
Year
2024
Status
Diagnostic completed. Recommendations and research roadmap proposed.
Main constraint
No direct access to users during the project
02

Product and operational context

A web-based platform used by teachers and education professionals as part of a wider public-sector education ecosystem. It was mandatory to use, sat inside daily workflows, and had been in production for several years without dedicated UX work.

Support complaints indicated recurring friction across key workflows, but the team lacked direct evidence about users' behaviours, constraints and working contexts. Basic information — age range, digital literacy, devices, connectivity, accessibility needs — had never been documented.

03

The constraint that changed the plan

The initial plan was to establish a baseline through direct research. When that path closed, the diagnostic approach had to change — and be honest about what it could and could not do.

01 · Initial intention

Conduct direct user research and a user survey to build a baseline understanding of teachers.

02 · Constraint

Access to users and continuity of the survey were interrupted for reasons outside the UX team's control.

03 · Decision

Conduct a collaborative heuristic evaluation based on real tasks derived from support evidence.

04 · Limitation

The method could identify interface risks, but it could not validate behaviours, needs or mental models.

What the evaluation could identify
  • Inconsistent interaction patterns.
  • Missing or unclear system feedback.
  • Error-prevention risks and data-loss exposure.
  • Undisclosed dependencies between modules.
  • Navigation friction across recurring workflows.
What it could not validate
  • Actual user behaviour in context.
  • Users' mental models and expectations.
  • Frequency of problems in real usage.
  • Environmental constraints (devices, connectivity, time).
  • Accessibility needs and task success with real users.
04

Diagnostic strategy

Rather than replacing user research, the evaluation was structured to make risks visible and to sharpen the research questions worth investigating next.

  1. 01

    Review recurring support evidence

    Read across support tickets and complaint themes to identify workflows generating the most friction.

  2. 02

    Translate complaints into task scenarios

    Convert those themes into representative task scripts anchored in real product journeys.

  3. 03

    Run an independent collaborative expert review

    Facilitate a session with other UX designers, evaluating each scenario against a defined set of criteria.

  4. 04

    Consolidate findings and identify systemic patterns

    Merge overlapping findings, compare severity across evaluators and surface patterns rather than isolated issues.

About the framework

The evaluation used Nielsen's ten usability heuristics as evaluation criteria — a widely adopted expert-review framework. The value of this case study is not in restating those heuristics, but in how they were applied to a real legacy product under access constraints. The full criteria are available below.

05

Task scenarios

Nine representative task scenarios were derived from the workflows most frequently mentioned in support evidence, so evaluators would experience the platform through high-priority journeys rather than abstract feature tours.

06

Evaluation session

I facilitated a collaborative session with other UX designers from the company. Each participant worked through the nine scenarios and rated the platform against the evaluation criteria and the severity scale.

I consolidated overlapping findings and compared severity ratings across evaluators. Equal weighting was used to prevent any individual assessment from dominating the synthesis, and disagreements were reviewed together before merging.

07

Results overview

Rather than a single interface problem, the evaluation surfaced systemic patterns that cut across multiple workflows and modules.

Qualitative summary

This overview is intentionally qualitative. The original scoring spreadsheet is not being published here, so the emphasis is on the shape of the risks rather than counts. Aggregate figures can be added later if there is a need to disclose them.

  • Navigation and consistency emerged as the most critical risk areas.
  • Several workflows depended on data or actions in other modules that were not made visible to users.
  • Feedback for user actions, ongoing processes and errors was often absent or unclear.
08

Key systemic findings

The individual issues clustered into a small number of systemic patterns. Each pattern combines what was observed, why it matters for users and what it implies for the product.

  1. 01

    Inconsistent interaction patterns

    Observation

    Buttons and controls with the same purpose used different labels, styles and positions across screens and modules.

    Consequence for users

    Users had to relearn the same actions in different contexts, slowing routine tasks.

    Product implication

    A consolidated interaction inventory and shared component patterns would be needed before further feature work.

  2. 02

    Error prevention and data-loss exposure

    Observation

    Destructive actions could be executed without confirmation, and leaving pages with unsaved changes did not always trigger a warning.

    Consequence for users

    Small mistakes could produce disproportionate consequences that felt like system failures.

    Product implication

    Confirmation patterns and unsaved-state protection should be treated as immediate safeguards rather than backlog polish.

  3. 03

    Insufficient system feedback

    Observation

    Ongoing processes, action outcomes and system state were often communicated late, ambiguously or not at all.

    Consequence for users

    Users could not tell whether an action had succeeded, was in progress, or had failed.

    Product implication

    Consistent status, loading and confirmation feedback would need to be introduced as a base layer across the platform.

  4. 04

    Hidden workflow dependencies

    Observation

    Some workflows required data or configurations from other modules or external systems, without informing users or providing access paths.

    Consequence for users

    This created a risk that blocked workflows could be interpreted as system failures.

    Product implication

    Dependencies would need to be surfaced in-context, with clear next steps rather than dead ends.

  5. 05

    Unclear help and error recovery

    Observation

    Error messages rarely explained what happened or how to recover, and help resources were difficult to locate during complex tasks.

    Consequence for users

    Users depended on external support to complete parts of core workflows.

    Product implication

    Contextual guidance and error messaging need to be designed alongside the interface, not attached afterwards.

09

Prioritisation and research roadmap

Heuristic severity alone was not treated as a product prioritisation criterion. Recommendations were organised into horizons that reflect both risk and the type of work required.

  1. H1

    Immediate safeguards

    High-risk issues involving error prevention, data-loss exposure and missing critical feedback.

  2. H2

    Short-term consistency improvements

    Aligning labels, components, states and interaction patterns across the platform.

  3. H3

    Structural workflow redesign

    Issues rooted in workflow logic or information architecture, requiring deeper redesign.

  4. H4

    Research required before solutioning

    Questions the expert review could not answer responsibly — behaviours, mental models, task success — that need direct user evidence.

10

Preparing the next research phase

A new product priority changed the roadmap and direct research could not yet continue. Two artefacts were designed to reduce the future barrier to reaching users.

In-product recruitment

A recruitment mechanism inside the product itself, so teachers willing to participate in future research could opt in during normal usage. The goal was to build a participant pool that could be activated as soon as research could resume.

Satisfaction measurement (NPS)

An NPS proposal was designed to start collecting a baseline sentiment signal. NPS was framed explicitly as a recommendation / overall perception indicator, not a usability metric.

How NPS was framed
  • Measures likelihood to recommend or overall perception.
  • Does not measure task success or reveal specific interaction problems.
  • Needs to be complemented with task metrics and qualitative feedback to be actionable.
11

Outcomes, status and limitations

Outputs produced
  • A structured usability diagnosis grounded in real support evidence.
  • A synthesis of systemic patterns and associated risks.
  • A prioritised research and product-improvement roadmap.
  • Designs for in-product recruitment and NPS baseline measurement.
Organisational effect

Recommendations were incorporated into the development prioritisation conversation and reinforced internally the need for direct research with teachers.

Product outcomes

The recommendations were not fully implemented during the project timeframe, so no post-release usability or operational metrics are available to attribute to this work.

Limitations
  • No direct access to users during the project.
  • Expert evaluation cannot validate real user behaviour or mental models.
  • Findings were based on a selected set of task scenarios, not on exhaustive coverage.
  • A new product priority interrupted the next research phase before it could start.
  • No post-release measurement was available to quantify impact.
12

Reflection

The evaluation was valuable not because it replaced user research, but because it separated interface risks that could already be addressed from behavioural questions that still required direct evidence. It also showed that improving the product would require more than isolated interface fixes: the team needed clearer workflows, consistent interaction patterns and a sustainable way to involve users in future decisions.
bzarocha@gmail.com in/bruna-zveiterGet in touch
Back to home

This case study has been anonymised. Product names, screens, tickets and data have been generalised and no identifiable material is disclosed.