Protecht Remote Athlete

Protecht Remote Athlete: Designing the Companion App for a Smart-Mouthguard Head-Impact System

Executive Summary

Protecht is a real-time head-impact monitoring system built by Sports & Wellbeing Analytics (SWA), a Swansea-based company spun out of a longitudinal research project at Swansea University. Sensors embedded in an athlete's mouthguard capture head impacts, and the data is surfaced to coaches, medical staff and the athletes themselves so that dangerous impacts in contact sports — rugby foremost among them — are recognised, understood and acted on.

I designed Protecht Remote Athlete, the mobile companion app (iOS and Android) that lets an athlete pair with their mouthguard, download a training or match session from the device, and push that data to the cloud where designated staff can analyse it. The brief came with hard time and budget constraints and a deliberately minimal brand, so the work was an exercise in doing the most with the least: a focused, intuitive flow for a single critical job, delivered as production-ready assets the development team could drop straight in.

1. Discovery & Research

Understanding the audience

The app sits inside a wider system used by three distinct groups — athletes, coaches, and medical/performance staff — but Remote Athlete is aimed squarely at the athlete managing their own sessions, often away from a clubhouse setup. That user isn't technical, is frequently doing this immediately after training when they're tired, and needs one thing to work reliably: get the data off the mouthguard and into the cloud so the people who interpret it can do their job. Any friction — a failed Bluetooth pairing, an ambiguous "is it working?" moment — means data doesn't make it back, which undermines the entire safety proposition.

Understanding the system around the app

Before designing screens I mapped where the app fits in the Protecht pipeline: sensor capture in the mouthguard, transfer over Bluetooth to the phone, upload to the cloud, then analysis and feedback by staff. The app owns only one segment of that chain — capture and transmission from the athlete's side — but it's the segment where the human is least supported and most likely to drop out. That framing kept the scope honest: the app didn't need to visualise impact analytics (that lives elsewhere in the system); it needed to make pairing, downloading and sending feel certain.

Constraints as a design input

Two constraints shaped everything: a tight budget and timeline, and a deliberately simple company brand with a limited visual toolkit. Rather than treat these as limitations to apologise for, I treated them as the design brief — a minimalist interface is the right answer for a single-purpose utility used under fatigue, not just the affordable one.

"I just need to get my session off the gum shield and know it's actually sent — without thinking about it." — Athlete, the primary user

2. Ideation & Information Architecture

Defining the core flow

I reduced the app to one spine: sign in → detect mouthguard → select a session → download → send to cloud. Everything else is secondary to making that path unambiguous. Mapping it this way meant each screen had exactly one primary action, and the user always knew what the app was waiting for and what they were waiting for.

Designing for the "in-between" states

The riskiest moments in this kind of app aren't the screens where something has happened — they're the waits: detecting the device, downloading a session, uploading to the cloud. A blank or ambiguous wait reads as failure, and the user walks away. I designed explicit, reassuring states for each transitional moment — for example a dedicated "Detecting mouthguard, please wait" screen with clear progress feedback — so the athlete never has to guess whether the app is working or stalled.

Low-fidelity structure

Early layouts tested how to present a list of sessions, how to make the download and the subsequent send feel like two distinct, completed steps, and how to confirm success unambiguously. The priority throughout was reducing cognitive load: one decision per screen, large and obvious primary actions, and confirmation that a session had genuinely been downloaded and then genuinely been sent.

3. Iteration & Visual Design

A minimal system, used deliberately

Working within the simple Protecht brand, I built a small, consistent visual language: a dark interface with a single confident accent (the Protecht red arc), generous spacing, and a clear type hierarchy so that the one thing that mattered on each screen was always the most prominent thing. Constraint drove the aesthetic — with a limited palette, consistency and restraint do the heavy lifting that decoration otherwise would.

Designing the states, not just the screens

• Menu and sign-in — a low-friction entry that gets the athlete to the task quickly.

• Detection — an explicit "please wait" state so a Bluetooth handshake never looks like a hang.

• Session list and download — session details with a single clear download action, then a visible record of what's been downloaded.

• Send to cloud — a distinct send step with an email/upload option, so "captured on my phone" and "sent to the staff" never blur into one uncertain action.

Built for handoff

Because the developers — not I — would assemble the final product, the design only succeeds if the assets are clean and complete. I delivered everything the build needed in the formats it needed: icons as both PNG and SVG, the app icon, and the store thumbnails for the Google Play and App Store listings. Collaboration with the developers was close and smooth, which let the assets integrate without the usual rounds of re-exporting and rework.

4. Outcome & Handoff

The result is a shipped, live product: Protecht Remote Athlete is available on both Google Play and the Apple App Store, letting athletes with a Protecht mouthguard capture and upload their own session data for staff to analyse — supporting performance, injury-risk mitigation in training, head-impact monitoring, and a safer return to sport.

What I delivered:

• The full app UI across its core flow — menu, sign-in, device detection, session download, and cloud upload — designed for clarity under real-world, post-training conditions.

• A complete, minimal visual system extracted from a deliberately simple brand and applied consistently across every screen and state.

• Production-ready handoff assets — icons in PNG and SVG, the app icon, and app-store thumbnails — supplied in the formats the developers needed for a clean integration.

5. Reflections & Takeaways

• Constraints clarified the design. A tight budget and a minimal brand pushed me toward a single-purpose, low-friction app — which is exactly what an athlete using it while tired actually needs. The constraint and the correct answer turned out to be the same thing.

• The waits were the product. In a capture-and-transmit utility, the transitional states — detecting, downloading, sending — are where users are lost or kept. Designing those explicitly mattered more than any "finished" screen.

• Scope discipline came from understanding the whole system. Knowing the app owned only the capture-and-send segment of the Protecht pipeline kept it from bloating into an analytics tool it was never meant to be, and kept the athlete's one job front and centre.

• Designing for handoff is part of designing. Delivering clean, complete, correctly-formatted assets and collaborating closely with developers was what turned the design into a product that actually shipped to two app stores.