The Daily 10

Overview

I inherited a product that was in development for 2 years

Found fundamental barriers to deploying it

Turned it into something that reached a classroom for testing

What I Inherited

I worked with what I inherited, simplifying key flows, reducing unnecessary clicks, improving navigation, making small UI changes to create a clearer experience

Solving The Early Problems

A UX case study on introducing the calculator into the quiz flow

Keeping students in context without simplifying the challenge

The Problem

The existing calculator opened as a separate notepad taking the students away from the question

I created a calculator that was directly integrated into the quiz so the students could use it without losing context

Keeping the familiar four column layout that people have come to understand to make students immediately feel comfortable using the calculator

Adding a fifth column

Adding a fifth column for operations specific to the current question

After confirming with the developer if we could set up a dynamic calculator like this to match the question

A disagreement settled by testing

The client was concerned that question specific operations might make the quiz too easy.

We tested the idea with students, the feedback supported keeping the feature, so it remained in the design.

Iterating from classroom feedback

Several usability issues emerged during testing with a Year 8 class.

Answering Questions

There was no way to transfer from calculator to input

Number Pad

The calculator and keypad competed for space

Visibility

The calculator could sometimes obscure the question

I redesigned the desktop quiz into three columns, keeping the equation consistently visible alongside the question, answer input and calculator. On mobile, the calculator is replaced by the number pad.

The product couldn’t enter the classroom

The product was originally being developed as a native app, but school cybersecurity restrictions created a major barrier to classroom deployment.

The team pivoted to a web app, removing the installation barrier and making the platform easier for schools to access.

The pivot exposed a bigger issue: I had been improving individual screens without first understanding the product as a whole. I changed my approach, using OOUX to identify structural problems before redesigning further.

Changing my approach

I mapped the product’s core objects, their relationships and the actions users could take between them.

Learning flow

To reduce cognitive load we grouped subtopics under topics, we also added a visual of what medal can be achieved for each level which wasn’t apparent before.

From buttons to a hub

The original home screen was little more than three navigation buttons. It gave users no indication of what was due, what needed attention, or what their class was currently working on.

I redesigned it as a dashboard, surfacing classes, upcoming assignments and the current topic so users could understand what mattered as soon as they logged in.

Class needed to be a core element

Mapping the system showed that students were being managed individually, while the real-world experience was organised around classes. Making Class a core object gave us a structure for class-level information and actions.

Building classes

• Creating classes: The teacher would create a class with a code linked to that class
• Joining classes: The students would enter that code in order to join, waiting on approval from the teacher
• Approving students: Once accepted the student is now part of the class

Two User Types, Different Needs

1. Teacher

Teachers want to look at how their class is doing

This way they can see who needs help and who’s completing the work

and they can approve and deny join requests

2. Student

We want to give users relevant prompts with context, this way they can

• Learn maths better
• Meet teachers’ requirements.

Students should be able to see how they’re going with their studies and where they are excelling/struggling

Assignments needed simplifying

Assignments were originally buried inside Learning Paths, meaning teachers could only create them through an existing path. Teacher feedback showed they needed the flexibility to assign work independently.

Assign From Anywhere

Teachers could now create work from scratch or enter from a Learning Path or Class, with relevant information pre-filled.

Assigning Process

Despite the technical challenge of refactoring the existing system, we separated Assignments into a standalone feature.

Once Assigned

Notification, dashboard visibility, incomplete students prioritised first

Designing for a changing environment

Whilst working on it the students’ syllabus had changed from algebra to measurement, which was an important detail

We had to ask

Focusing on an area

The class set up allowed us to give teachers the freedom to select what the current topic is for students, which could then highlight this for students and teachers as the area of focus

A shared framework

Early on, questions were written first and I designed around them.

As the product grew, it became clear that content, design and development needed a shared structure.

I worked with the team to create a question framework that aligned the learning goal, difficulty progression, interface and feedback before a question was built.

Each section has 10 questions

Wrong questions aren’t the end

Getting an answer wrong shouldn’t end the learning process.

I designed the feedback flow to respond to the mistake and give students another opportunity to apply what they’d learned.

What I Learned

OOUX

Object Oriented Design which helps manage complex systems, find the important questions early and is a great resource in working with AI

Think in systems

It’s not just about designing an amazing feature, but how it fits into the existing system, and how it fits into users’ mental models.