The second half of Project TEAL was where separate ideas had to become one system. A breadboard circuit that worked on a desk was not enough. The hardware needed to survive being handled, the enclosure needed to support the intended interaction, the software had to serve different users, and the whole system had to make sense outside my own development environment.
Moving beyond the breadboard
Transferring the electronics to stripboard and permanent wiring immediately exposed problems that jumper wires had hidden.
One of the most frustrating faults was also one of the simplest. The SOS and REC inputs began triggering together, even though the firmware treated them independently. After continuity testing, the cause turned out to be copper tracks on the stripboard that had not been fully isolated. Cutting and reworking the tracks restored the intended separation.
The vibration motor created a different class of problem. It could not simply be driven like an LED from a GPIO, so I added a transistor driver and flyback diode. Under load, power integrity also mattered. The battery and TP4056 charging/protection path had to be reorganised correctly, and additional bulk capacitance helped prevent motor-related instability. These were small circuit decisions individually, but together they determined whether the prototype behaved reliably in someone’s hand.
The INMP441 microphone created another deceptive failure mode. The system could apparently create a valid audio file while recording almost no meaningful sound. The problem was not the file format but an intermittent I2S clock connection and configuration details such as the microphone channel selection. It was a useful reminder that “the software ran” and “the system worked” are not the same statement.
Mechanical integration introduced yet another layer. A circuit that behaved normally outside the enclosure could develop intermittent faults once installed because slight deformation changed pressure on wires, tracks or solder joints. I increasingly stopped thinking of electronics, mechanics and software as separate subsystems. In a physical product, they fail together.
Designing the object around the interaction
In CAD, I iterated the enclosure around the way the device would actually be held and used.
The FSR needed to sit where a thumb or finger could press naturally. SOS and recording controls needed to be visually and physically distinguishable. The board, battery and wiring had to fit without being compressed into unreliable positions. Early geometries could look tidy on screen while feeling awkward in the hand, so later versions prioritised grip, access and spacing rather than symmetry.
That process changed my understanding of enclosure design. The case was not packaging added after the electronics; it was part of the interface.
Building a two-layer software system
At the same time, the software became much more ambitious.
The firmware and Flutter app developed into an offline-first hardware–software system. Events could be stored locally on the device and synchronised over BLE when the tablet reconnected. Individual events could contain time, duration, pressure metrics and a pressure curve. I also added functionality around voice notes, SOS, calibration, vibration settings, personalised labels and post-event prompts.
One of the most important iterations, however, involved removing complexity rather than adding it.
The full app had grown into a useful caregiver interface with settings, statistics, calibration and detailed event views, but that did not mean the same interface was appropriate for the person recording the symptom. This led to Accessible Mode: larger text and controls, simplified navigation, a small set of primary actions, and large visual tags for common contexts such as meals, exercise, sleep and medication.
The final system therefore became explicitly two-layered. The service user sees the simplest interaction possible; caregivers retain access to history, settings, curves, calibration and review tools. During the final demo, I presented it in exactly that order: first the day-to-day user experience, then the deeper caregiver toolkit. The aim was to turn individual moments into a pattern that staff could later review, without asking the primary user to manage the complexity required for that analysis.
Testing what mattered
For the final stage, I structured testing around usability and engineering validation rather than trying to claim clinical effectiveness.
The first question was basic: could someone understand what to do with minimal explanation? I also wanted to see whether light and stronger simulated inputs produced distinguishable force data, whether shorter and longer events were represented correctly, whether the hardware-to-app BLE workflow was reliable, and whether caregivers could make sense of the recorded information.
The testing process itself followed an engineering iteration loop. Day 1 was formative: observe first, explain only when necessary, and identify the problems that mattered most. Between sessions, the aim was not to respond to every suggestion by adding another feature, but to prioritise critical or major issues and make changes with a clear rationale. Day 2 then repeated the same core tasks to see whether those changes actually improved clarity or performance.
The feedback reinforced something that had been emerging throughout the placement. For primary users, large targets, few choices, physical feedback and a simple action mattered more than feature density. Staff and caregivers, meanwhile, valued history and context: when something happened, how long it lasted, how intense it appeared, and whether events formed a pattern.
It also raised questions rather than simply confirming the design. For example, repeated presses could look like inaccurate data, but they might also be a form of communication or attention-seeking that is meaningful in its own right. Designing responsibly means understanding such behaviour before deciding it is “noise.”
What changed
Project TEAL began as an exploration of assistive technology, but it gradually became a lesson in what accessibility means in practice. The symptom tracker evolved from a simple pain logger into a broader system for helping people communicate discomfort in a way that places fewer demands on memory, language and digital confidence.
The technical development mattered, but the deeper change was in how I understood the purpose of the engineering. The system grew from an LED on a breadboard into a soldered handheld device connected to a Flutter app, and from a single interface into two layers: a simple, accessible front end for the person using it, and a richer review space for caregivers and staff. That separation reflected an important principle: people should not have to adapt themselves to technology that was never designed around their needs.
This connects directly to the wider goal of reducing inequalities. Inequality is not only about whether a service exists, but whether people can realistically access, understand and benefit from it. For someone who finds it difficult to recognise, remember or describe discomfort, a conventional health-tracking workflow may already contain barriers. Human-centred engineering can help reduce those barriers by designing around differences in ability rather than treating them as exceptions.
The project also changed my understanding of integration. Sensing, power, mechanics, BLE, storage and UI can be developed separately, but the user experiences only one system. If any part creates friction, the whole interaction becomes less accessible.
I am leaving the placement with a working prototype, but also with open questions around longer-term testing, personalisation, privacy, reliability and appropriate clinical involvement. That feels like the right outcome. The aim was never simply to build a device in six weeks. It was to understand a real barrier, translate it into an engineering problem, test the response with the people affected by it, and use that process to make technology a little more inclusive.