At the halfway point of my Leadership in Action placement at Papworth Trust, the most important thing I had built was not yet the prototype. It was a clearer understanding of what was actually worth building.

I began Project TEAL with a broad aim: to explore how engineering could support greater independence for people with learning disabilities and other disabilities. Rather than arriving with a predetermined product, I spent the first stage joining normal activities, observing where people needed repeated support, and speaking with staff and caregivers. I used a simple field sheet to separate isolated incidents from recurring patterns and to ask whether a difficulty affected independence, participation, confidence, safety or staff workload.

This was more challenging than I expected. In engineering, we are often given a problem statement. Here, the problem itself had to be discovered. Some needs could not be captured by simply asking, “What do you find difficult?” Behaviour, routine and the support provided by others often revealed more than a direct interview.

One theme that gradually stood out was communication around physical discomfort. Episodic pain or other symptoms can be difficult to remember and describe afterwards, while opening a conventional health app and typing notes during an uncomfortable moment may be unrealistic for some users. This led to a much simpler interaction concept: record the moment physically, then review it digitally later.

The first prototype was deliberately basic. I used an ESP32 with an FSR406 force sensor so that pressing the device could capture both the occurrence and relative intensity of an episode. I also planned haptic feedback, but before I had the correct motor protection components, I substituted an LED and resistor on the breadboard. It used the same software path as the future vibration motor, giving me a visual way to test the interaction loop.

The breadboard quickly exposed assumptions I had not noticed on paper. At one point the ADC reading stayed permanently at 4095, regardless of pressure. The issue was a simple but important voltage-divider error: the pull-down resistor was not correctly referenced to ground. After fixing it, different pressures became visible, although medium force already saturated much of the ADC range. I therefore had to rethink how the useful sensing window should be mapped in software.

Feedback also evolved. A simple on/off output could confirm that something had been pressed, but it could not express “harder press, stronger feedback.” Moving to PWM allowed the output intensity—and eventually the vibration strength—to follow the applied pressure. Even that required adaptation when changes in the ESP32 Arduino Core altered the LEDC API.

In parallel, I began building a Flutter companion app. The early version focused on the essentials: BLE connection, a live pressure display, local episode storage, a basic timeline and the beginnings of calibration.

By halfway, the project had therefore moved through several layers of uncertainty: from observing broad needs, to defining a specific communication problem, to translating that problem into sensing, feedback and software.

The strongest lesson so far has been that human-centred engineering does not begin with choosing components. It begins with deciding which problem deserves a component at all. The prototype was becoming tangible, but the more important progress was the evolution of the question itself.