From low engagement to confident conversations.

This project was developed in collaboration with Singapore’s Ministry of Education and selected primary schools. It aimed to create more opportunities for young learners to practise speaking their Mother Tongue Language, while giving educators the tools and oversight needed to create, assign and manage suitable learning activities.

Building informed hypotheses when direct access was limited.

Direct interviews with Primary 1 and Primary 2 students were limited during early discovery because research involving young children requires additional consent, ethical safeguards and age-appropriate communication methods.

Instead of presenting assumptions as confirmed research, I created proto-personas using:

• Input from MOE stakeholders and educators
• Discussions with the Product Manager
• Existing knowledge of the classroom environment
• Product and curriculum requirements
• Child-centred interaction principles
• Expected reading and speaking abilities
• Known technical and AI constraints

These proto-personas were working hypotheses, not validated personas. They gave the team a shared starting point and were later refined through school trials, observation and behavioural evidence.

Defining the experience before drawing the interface.

With four roles depending on each other, I mapped each one’s path through its own task first — what it depends on, and what happens when things go wrong — then turned every step into a requirement before drawing a screen.

The four user flows

Pre-sketch requirements

Before creating wireframes, I translated each requirement into a structured pre-sketch framework. This helped me understand the user’s motivation, expected behaviour, technical dependencies and intended outcome before deciding how the interface should look.

This framework became the bridge between requirements and wireframes. It helped ensure that every screen and interaction existed for a clear user or system need.

One product ecosystem, two visual languages.

Once the low-fidelity flows were agreed upon, I moved into high-fidelity design. The platform needed to serve two very different audiences. Instead of forcing one visual approach across every role, I created two connected design themes.

Both themes were built on a shared underlying component system, which kept the two experiences consistent with each other and kept development efficient.

StudentsStudents TeachersTeachers School AdministratorsAdmins System OwnersOwners

The playful theme, tuned for a six-year-old: one clear action per screen, audio ahead of text, and feedback a child can read at a glance.

01 / 04

Home: new exercises, each with its picture, status and one clear action

Click to enlarge

01 02 03 04

Building a testable product, then watching how children really used it.

Throughout implementation, I worked closely with the Product Manager, developers and AI engineers to resolve design and technical issues.

• Clarifying interaction behaviour
• Reviewing implementation against the designs
• Resolving edge cases
• Adjusting components where technical constraints affected the experience
• Defining loading, empty, error and fallback states
• Reviewing AI conversation behaviour
• Maintaining consistency between child and adult experiences

Once MVP 1 was ready, we presented it to MOE stakeholders. Their feedback helped us identify areas that required further refinement before testing the experience with students in selected primary schools.

1. Initial concept
2. Low-fidelity validation
3. High-fidelity design
4. Development collaboration
5. MVP 1
6. MOE review
7. School trials
8. Behavioural analysis
9. MVP 2

Validation and behavioural analysis

Asking Primary 1 and Primary 2 students to describe every frustration point directly was not always reliable or age-appropriate. Observation became a critical research method.

Following the MVP 1 school rollout, I reviewed more than 500 student sessions using Hotjar and supported the analysis with Google Analytics. I looked for behavioural signals such as:

• Long pauses before taking action
• Repeated or rapid tapping
• Revisiting the same screen
• Difficulty starting an exercise
• Confusion around text instructions
• Unsuccessful speaking attempts
• Abandonment points
• AI misunderstanding or irrelevant responses
• Unexpected language switching
• Time spent reading instead of speaking
• Difficulty recovering from errors

All student information shown in this case study is anonymised. No recording, name, class or identifying detail appears in the portfolio.

Hotjar findings report · MVP 1

What 536 recorded sessions showed

Observation period

18 Oct – 7 Nov 2024

Recordings reviewed

536

Behaviour labels

427

Key findings

8

Devices and browsers

• Desktop 341 64%
• Mobile 139 26%
• Tablet 56 10%

• Chrome 300
• Safari 171
• Edge 42
• Other 20
• Firefox 3

36% of sessions were on a phone or tablet, even though the parent guide recommended desktop Chrome.

How the sessions were labelled

• Frustration203 48%
  AI engine failed to start or continue
• Success166 39%
  Task completed without issues
• Confusion33 8%
  Unsure of the next step
• UI/UX issue16 4%
  Interface got in the way
• Bug9 2%
  An application error blocked progress

Frustration was the largest label, and every instance was the AI engine failing to start or continue an exercise, not the interface.

Eight key findings

1. 01Setup

   The parent guide went unread

   Students joined on whatever device and browser was to hand, although desktop Chrome was the supported setup.

2. 02Product

   Phones and tablets could not be an afterthought

   36% of sessions came from phones and tablets, which made a responsive web app a priority.

3. 03AI

   Exercises stalled before they began

   The AI engines failed to produce the prompt needed to start or continue an exercise 203 times.

4. 04UX

   The instruction modal had no way out

   Unsure what to do next, students tapped each icon in turn. The fix: a clear “OK, got it” button.

5. 05AI + Eng

   Failures left students stranded

   In 76 sessions the engine did not load the exercise (16) or the next prompt (60). Students went home to retry, or refreshed the page.

6. 06AI

   Responses were inconsistent

   Tamil mixed with Japanese characters, Chinese mixed with English, repeated characters, a sudden switch to English, and replies that continued after the exercise had ended.

7. 07AI

   Some exercises ended too soon

   In three sessions the engine produced only five responses before marking the exercise complete.

8. 08UX

   Exercises could be finished in silence

   Some students completed exercises without speaking at all, simply tapping Send until it ended.

What the AI engine produced

Smaller issues logged

• The Start button appeared before both onboarding steps were complete.
• On Safari, the speaker list stayed empty, so no speaker could be chosen.
• Most students tapped “Yes, I hear” without playing their recording back.
• The header navigation was missing on the microphone-recording screen.
• Long names broke across three lines on My Profile.
• A typo on the “Sent a new PIN” confirmation.

From the recordings

Login: the heatmap shows students signing in without trouble. Onboarding: most taps went to Test and Add parent’s email. Onboarding: Start appeared before both steps were done. Safari: the speaker list stayed empty. Microphone denied: clicks scattered with no clear way forward. Instruction modal: with nothing to continue, students tapped every icon. Mic check: “Yes, I hear” tapped without playing the recording. Each dot is a tap: the exercise never finished loading. Repeated tapping after the engine failed to give the next prompt. An exercise that ended after five AI responses. Chat history of an exercise “completed” with no spoken reply. My Profile: a long name broke across three lines.

Student names, email addresses and browser addresses have been removed from every screenshot.

A more focused, trustworthy speaking experience.

The project established a connected product ecosystem across students, teachers, school administrators and system owners. More importantly, it demonstrated how behavioural UX research could improve both the visible interface and the underlying AI experience.

What the work produced

• A child-centred model for AI-assisted speaking practice
• Connected workflows across four user groups
• A student-first MVP grounded in the product’s main learning objective
• Two appropriate visual experiences for children and adults
• A structured approach to designing AI uncertainty and recovery
• Evidence-based improvements informed by more than 500 observed sessions
• UX findings that supported further LLM training and language-control improvements
• A clearer, more focused audio-first conversation experience
• An improved MVP 2 delivered to MOE

Measurement

These are the measures the work is meant to move. They are left unfilled rather than estimated — a case study that invents its own numbers is worth less than one that says what it does not yet know.