Gerald Ajam

When ease of use is not ease of learning

How might we reduce unnecessary interface friction without removing the cognitive effort that contributes to learning?

Status From practice

Published November 2026

All practice cases

Institutional detail is generalised. The platform, its governance and the people involved are not named, and internal figures are left out.

Context

Teachers and students use a national learning platform every day. Teachers build lessons on it, assign work, give feedback and follow progress. Students open it to do the work they’ve been set. It was built for learning first, and it grew feature by feature as more was asked of it. Ease of use was sometimes what gave way.

In 2026 I was working on its user experience. Five of us wrote twelve design and learning considerations: what the platform has to protect for learning to happen, from focusing attention to letting support fade as students grow more independent. The platform’s leadership endorsed them. Then a small design team turned to the screens themselves, and to rebuilding the design system every screen is drawn from.

So two pieces of work met on the same screens. One said what learning needs. The other set out to make the platform easier to use.

The question

How do you make a national learning platform easier to use, when some of the effort it asks of students is the learning?

What made it difficult

Ease of use and learning come apart, and most product methods can’t see it. Conditions that make practice feel smooth often teach least, and learners prefer them even after seeing their own results. A usability review files every difficulty as a defect. Some of those difficulties were doing the teaching.

The obvious fixes cut both ways. A hint, an autocomplete or a worked example is a mercy in one situation and a theft in another. Nothing in the existing design system said which was which.

The people building screens were good at removing friction, because that is what design training rewards. Few were trained in education, and the platform asked them to make calls about learning on every screen.

The measures pointed one way. We could count complaints and helpdesk tickets. Nothing we had could show what a student could still do a week after a task, and that is the measure that tells you whether learning survived a redesign.

And years of features had been built at different times in different ways. Fixing a screen fixed one screen.

What we noticed

Much of the effort the screens asked for was plain waste. We audited the live platform three times: the teacher experience, the student experience and its conventions. We found text too faint to read, pages that opened in different ways and a module with three separate navigation tools. Grouped by cause, the findings came down to ten patterns. Each recurred wherever a shared part had been built inconsistently, so one fault turned up on many screens.

Some of the waste sat inside learning tasks. User reports described students who couldn’t see the question while they typed their answer. That is effort spent holding the question in memory, and it teaches nothing.

The student audit read differently from the teacher one. Teachers are adults with workarounds and a helpdesk. Students are children, some with disabilities, on school devices, often with one attempt at a piece of work.

Years of user research said the same thing about students. Most opened the platform to clear what they’d been assigned and left as soon as they had. Some asked for streaks, points and reminders to keep them going.

Some moves that looked like pure convenience would have removed the skill being practised. An e-dictionary in a reading comprehension task removes a barrier. The same dictionary during a spelling test removes the test.

A reviewer added that fear spends attention too. A student bracing to be wrong in front of the class, or facing a mistake they can’t undo, is busy protecting themselves.

Judgement

Sort the work first. My draft of the principles treated every screen as a contest between smoothing and stretching. A colleague pointed out in review that the two only collide on tasks meant to teach. It was the sharpest correction the draft got, and I took it whole. Where a task isn’t meant to teach anything, such as saving, finding a page or changing a setting, smooth without limit. Where it is, name the effort it exists to create, protect that and clear everything else.

Make the learning effort a sentence someone has to write. A principle on a slide is easy to forget under a deadline. So the design system asks every feature to state before it’s built whether it’s a learning task and, if it is, what the learner must think or do, in one sentence. The release check asks whether that effort is still there.

Let support fade. Hints should thin out as a student improves and come back when needed. A retry should keep the work and carry no penalty. Help that never fades becomes the thing a student leans on.

Draw the line on attention by who sets it. Another colleague asked what happens if a student sets their own streak. That reframed the rule. We ban streaks, rankings and urgency that the system imposes. We allow a goal the learner sets and can change.

Separate principles from standards. The draft that went to review had seven positions, and we kept five. A principle had to take a side on a real tension. Anything nobody would argue against, such as speed or accessibility, became a standard every screen must meet.

What changed

I wrote a primer for the design team on how people learn and why that differs from how most products are designed. It gives the team one question to test every principle against: does this help the learner do the thinking that causes learning, or does it just make the experience feel good?

We set five design principles for the design system. The first is “smooth everything but the learning”. The others cover attention, automation, building for everyone and where complexity should sit.

Each principle became build rules and pass or fail checks for engineers and testers, with examples of what to build and what not to build.

The design system’s feature handoff asks for the task type and the intended learning effort, and its release gate checks that a learning feature still contains it.

We redesigned twelve screens on the new system as working mockups. On the answering screen, the question, its rubric and the actions now sit together on one card.

When we were asked what UX work was worth, our answer included a rule: every measure of friction removed needs a measure of learning kept.

What happened

The platform has adopted the design system and accepted the twelve design and learning considerations. The principles, their checks and the learning-effort question are written into the design system’s documentation. The redesigned screens are working mockups and will change as testing continues.

What I can’t tell you yet is whether any of it protects learning. The redesigned screens haven’t reached students. Nothing the design team has can show what a student can still do a week after a task. And I don’t know whether teams will write the learning-effort sentence with care or as a formality.

This is the gap the case is about. Friction is easy to count. Learning kept is much harder to show, and so far our record holds only the first kind of evidence.

What transferred

  1. Sort the work before you smooth it.

    Ask first whether a task is meant to teach. If it isn’t, remove every bit of effort you can. If it is, name the effort that teaches and protect only that.

  2. Put the principle where the decision is made.

    One line in a feature handoff is read when a choice is being made. A principle on a slide is remembered at the start of a project.

  3. Fear is load.

    A low-stakes space where work survives a retry protects the struggle instead of softening it.

  4. Every measure of friction removed needs a measure of learning kept.

    Without the second, a learning platform drifts into a completion platform, and the dashboard calls it success.

Singapore