UX as quality control: Building the interface that trains Sky's ML Model

Outcome

UX as the quality-control layer for the dataset

This was an MVP capture tool for an internal ML effort. The measures below are what the design was built to improve. I designed the capture layer; the model outcomes sat with the ML team.

Over a two-week sprint, my scope was the capture interface. This was the one surface where the user and the model’s data requirements met, inside a multi-stage ML pipeline built by a small ML engineering team. Every interaction shaped the training footage. Better framing meant fewer unusable clips. Clear recovery meant fewer abandoned recordings. Consent, reframed as participation, meant more people opting in.

Sky Live ML capture interface in colour. Plank task in a living-room studio, with task panel showing Plank, 1 person, 5 second duration, and Record, Submit, View preview, Back controls.

Positioning variability

Ready, Countdown, GO! gives users time to enter frame and settle. The intent: more videos reach the model already in the correct starting position.

Recovery without abandonment

Errors map to pipeline stages, camera, network, upload, ingestion, so users get the right recovery action instead of a generic dead end.

Consent as participation

Consent is framed as helping train the model, not as legal friction. The aim was to lift opt-in, since every opt-out is a person missing from the dataset.

Challenge

The problem space

Sky was building a machine learning system that needed real people to record specific body movements to train a computer-vision model. The tool was a TV app running on the Sky Live camera. My job was to design the capture experience, where every UX decision directly determined whether a recording could be used for training or had to be thrown away.

The interface was, in effect, part of the pipeline.

How the system works

Pipeline first, interface second

Understanding the technical architecture was essential to designing an effective experience. The system works end-to-end as five sequential stages, with UX sitting at the very top. The clarity of the capture interface determines whether the data that reaches the model is usable.

Authentication

Secure sign-in, with consent as a hard gate.

Task assignment

Modular task: name, duration, instructions.

Capture

Sky Live camera, adaptive resolution and rate.

Where the UX scope sat

Upload

Asynchronous, event-driven upload to cloud storage.

ML ingestion

Final destination of every recording.

What the model needs

The constraints behind every screen

The interface fed a custom classifier built on a third-party pose-estimation model. That model maps the body as a set of 3D landmarks but doesn’t know what a plank is. Ours learned the positions from that data, so every recording had to clear the upstream model first. It has four hard requirements:

Drops low-confidence frames
Needs the full body visible
Works best side-on
Defaults to a single person

Every task instruction is a landmark requirement in disguise.

Minimum confidence threshold

The model drops low-confidence frames, so I made the camera view dominant, users self-check position before recording and more frames clear the threshold.

Full body, side-on

The model needs the whole body in side profile. So a reference image shows the exact framing, teaching the angle the model needs, not just the movement.

Preparation time

A cold start gives the model a bad first second. Ready, Countdown, GO! lets users settle into the pose, so capture begins with high-confidence landmarks.

Single-person detection

The model expects one person. The task label says “Plank, 1 person” so the metadata mirrors the model config, not just the user-facing copy.

The design

The capture flow

Seven states designed to reduce uncertainty, improve data quality, and give users confidence at every step.

Screen 1

Sky Live ML capture, initial state. Live camera preview dominates the left, task panel with instructions and controls on the right.

Screen 1 · Press record to start

The initial screen sets the split-screen layout: ~80% live camera preview, because what the camera sees is what the model trains on, and a persistent right-hand panel with task name, duration, and instructions. "How to do the task" is available as a pull, not a push, so confident users go straight to Record.

Screen 2 · How to do the task

Tapping "How to do the task" replaces the live feed with a reference photograph of the correct pose. Showing the ideal position teaches users what a good recording looks like before they make one, guidance that serves the pipeline as much as the person.

Screens 3 to 5 · Ready, Countdown, GO!

Borrowed from sports timing: "READY!" gives time to enter frame, the countdown gives time to settle, "GO!" removes ambiguity about when recording is active. Each phase prevents users from starting a recording out of position.

Screens 6 and 7 · Finished and Submitted

After recording, users see the final frame with two clear options: Re-take or Submit. Knowing they can try again means users are more likely to produce a higher-quality recording on the second attempt than to submit a bad one under pressure. "Your video is submitted" closes the loop.

Key design decisions

Trade-offs between user friction and dataset integrity

Camera-dominant layout

The camera view is what enters the pipeline, so I kept it central. Users self-correct their positioning in real time, treating the camera as their feedback rather than a separate instruction.

Three-phase launch (Ready, Countdown, GO!)

A cold start produces off-frame, out-of-position data. The three-phase launch gives people time to move into position, so recordings begin consistently framed.

Pipeline-aware error states

Generic errors cause abandonment. Mapping each error to its pipeline stage, camera, network, upload, ingestion, gives users the right recovery action at the point it fails, so a recoverable problem doesn’t cost the whole recording.

Consent as purposeful participation

Consent is a hard gate before any recording. Framing it as participation in training the model, rather than legal friction, was designed to lift opt-in and reduce drop-off at the gate.

Reflection

What I took from it

This was a small, tightly scoped project, two weeks, one interface, but the constraints were real: a model with a hard confidence threshold, landmark requirements that made every task instruction a data-quality requirement in disguise. The user wasn't simply completing a task, they were an operator in a pipeline, and their accuracy directly affected the model being trained downstream.

Small scope, real constraints

Rigour doesn't require a big system, it requires understanding what the machine actually needs.

Mapping invisible failures

The highest-impact decisions mapped invisible system failures to clear recovery actions.

Teaching the user what the machine needs

Reference imagery, launch timing, and Re-take agency all implicitly taught users what good training data looks like.

Designing for reuse, not just one model

The task structure was deliberately generic. New ML use cases could plug in by defining a new task, not requesting a new interface, the same pattern that let one capture tool serve multiple ML projects.

The interface is part of the pipeline. Every design decision is a data-quality decision.