Shipped to military and EMS partners in June 2026, validated in summative human factors testing, and supporting a 510(k) submission: Spectral MD’s FDA-cleared AI burn assessment, rebuilt as a 4-lb handheld for the point of injury without touching the cleared imaging core.
From requirements to a validated, delivered product, as the only designer in the room.
The Problem
The cart’s AI flags burn areas unlikely to heal without grafting, and stitches multiple scans into one TBSA% (Total Body Surface Area burned) figure. My brief: re-platform it into an iPad-sized handheld, and make one build serve two customers: a field-deployment program at ROC1–2, forward of any hospital, and the company’s expansion from burn centers and ERs into EMS.
The last row mattered most. At the point of injury, nobody is deciding whether to graft. They’re deciding who gets evacuated first, and how fast. That’s Decision 01.
Constraints
Every decision below runs into at least one of these, tagged C1 to C3. On a regulated product, the scarce skill isn’t proposing the ideal design. It’s finding the best available one after the ideal gets rejected.
0
changes allowed to the imaging principle, five-camera array, or prediction algorithm
The handheld goes through FDA 510(k) with the cleared cart as its predicate device. That path only holds if the two are substantially equivalent, so everything the device does, down to its body-map region system, was fixed on day one. I could only redesign how a user gets there, which made this an interaction-design project end to end.
~4lbs
five cameras, a battery, and thermal management in one handheld
Light for a cart, heavy for one gloved hand. The camera array images at a fixed distance, so the field of view is fixed too, and the sensor stack and GPU leave little headroom for live image analysis or heavier models.
ROC1–2
point-of-injury care, in a tent, a field, or an ambulance
Unpredictable light and power, gloved hands, and users who may see a severe burn only rarely. Training is measured in minutes and fades between uses, the triage call is made in seconds, and one build has to serve both military and EMS.
Timeline
Where each decision landed, from requirements to delivery. Each marker links to its decision.
Requirements, workflows, and the URRA, with BME, engineering, RA, and PM
Flows and screens, reviewed for optics feasibility and regulatory equivalence
Two rounds, each followed by a design iteration
15 burn-care RNs, 9 clinical scenarios, simulated bedside
June 2026
Military and EMS partners; finished-device demo for military stakeholders
Decision 01
What I decided
Make TBSA% the handheld’s headline number instead of the cart’s non-healing area, and give each build its own patient-list order on the same frozen core: by TBSA% for military evacuation triage, by last scan date for ongoing commercial care.
Why
The cart answered a burn surgeon’s question: which areas won’t heal without grafting. At ROC1–2 nobody is deciding whether to graft. A medic is deciding who gets evacuated, and how fast, and TBSA% is the number that drives that call. Leading with non-healing area would have put the right answer to the wrong question on the first screen.
Options & constraints
Changing what the AI produces was off the table (C1): both builds run the same cleared core and show the same outputs, so the lever was hierarchy, not capability. The alternatives each fell short. Keeping non-healing area as the headline, with TBSA alongside it, puts two co-equal numbers in front of a medic with minutes of training (C3) and asks them to pick. A single patient list for both customers forces one order on two different jobs: severity-first triage and recency-first caseload management. So neither build removes anything; each reorders it for its mission.
Evidence
The clinicians in our summative study estimate TBSA at least four different ways today: the rule of nines, the Lund–Browder chart, the palm method, and in one case an iPhone photo. That inconsistency is the gap a TBSA-first device closes. 7 of 15 participants volunteered that the device would improve efficiency and consistency, especially at institutions without dedicated TBSA experience.
Result
One build opened two markets: military field care and EMS. The same rule carried to every screen: the fewest possible options per screen, with complex tasks (TBSA tracing, photo brightness and rotation) split onto dedicated screens so a user under pressure can finish by hitting “next”. When formative participants called a report-version picker actively unpleasant in an emergency, the picker went: results now open on the latest report, with history one scroll away.
Military build
Commercial build
Same rule, results screen
Decision 02
What I decided
Move capture feedback from after the photo to before it. When the ideal version, live image-quality analysis, proved infeasible on this hardware, ship the feasible approximation and say plainly that it is one.
Why
The AI is only as good as the photo it receives. The cart’s flow is reactive: shoot, then learn the photo was too close, too far, or failed processing. In a controlled room a retake costs seconds. At the point of injury, every failed capture is time not spent on the patient, or on cover.
Options & constraints
The ideal was for the device to judge its own image quality live, catching exposure, motion blur, and underexposure before the shot. After repeated rounds with the optics team, that wasn’t feasible: the sensor stack can’t analyze a live frame that closely before capture (C2). Instead of dropping the idea, I broke it into the signals the hardware could produce in real time:
It isn’t the device reading its own image, but together the three cover most of what that would have caught.
Evidence
Formative testing showed the same after-the-fact pattern one step earlier in the flow. Because the field of view is fixed (C2), participants often found out only after capturing that they’d missed a wound on the far side of a limb, or selected one that needed removing, and the only fix was going back to the body map and starting over.
Result
Shipped: real-time distance, motion, and lighting guidance during capture. The same principle then extended to the wound list: add and delete controls now sit on the pre-capture overview, so a missed or extra wound is fixed in place without a restart. The user’s judgment was never the problem. The workflow assumed a foresight the fixed field of view doesn’t allow.
Same principle, wound list
Decision 03
What I decided
Keep the cart’s body-map regions exactly as cleared, and fix its most frequent error in the interaction instead: suffix selection moves from a separate, skippable step to an in-place choice beside the highlighted region.
Why
The most frequent error we’d observed on the cart was clinicians forgetting to select a suffix at all. For a medic with minutes of training (C3), a finely subdivided Lund–Browder-style map followed by a separate suffix step is a lot of load at exactly the moment attention is scarcest.
Options & constraints
My first proposal went further: collapse the map into broad rule-of-nines regions and remove the suffix step entirely, for real cognitive-load savings. Regulatory Affairs rejected it. Simplifying the body map risked the substantial-equivalence argument the 510(k) depends on, and the region system was frozen with the rest of the predicate (C1). That left one lever: change how users reach the data, not the data itself.
Evidence
In summative validation, participants completed every critical task without a use error. They also flagged that the suffix terminology doesn’t match how they chart clinically, confirming what the rejected proposal was reaching for.
Result
Shipped, after a rejection. In-place suffix selection addressed the cart’s highest-frequency error without touching the predicate. The terminology gap is now on the roadmap for the next hardware generation, a quiet vindication of the original simplification.
Decision 04
What I decided
Replace the two continuous overlay-transparency sliders with two plain on/off toggles.
Why
The sliders were meant to fade the AI’s non-healing and TBSA markup so a clinician could see the photo underneath. In formative testing, participants read the color intensity as meaningful, as confidence or healing probability, and some believed dragging the slider changed the algorithm’s output. A user who thinks they’ve “adjusted” the result may act on an assessment the AI never produced.
Options & trade-offs
Relabeling the sliders or captioning them “display only” wouldn’t have been enough. Either way, a draggable control would still sit on top of an AI result, and the misreading came from the control itself, not its label.
The toggle gives up something real. With a slider, a clinician could fade the markup halfway and see the AI’s boundary and the wound bed at once; with a toggle, they flip between the two. I judged the cost worth it because the core need survives: switching the overlay off still shows the full, unmarked photo. What’s lost is a side-by-side convenience. What’s removed is a way to misread a cleared AI output (C1). A lost convenience carries no clinical hazard; a misread assessment can. A visualization that can be mistaken for a control is a safety risk, not a UX preference.
Evidence
By summative validation, participants completed all 22 critical tasks without a single use error.
Result
Shipped as display, not control. It became a rule for every AI output on the product: the visualization has to be legible and impossible to misread as a control.
Also shipped, in brief
Outcome
The handheld shipped in June 2026 and took the company into two markets the cart could never reach: military field care and EMS.
Delivered
June 2026, to military and EMS partners
Validated
Summative human factors validation passed
Regulatory
Supports a 510(k) submission, predicated on the cleared cart
Market
One build, two new markets: military field care and EMS
I led the finished-device demo for military stakeholders.
From the summative human factors validation: 15 practicing burn-care RNs, in a simulated bedside environment.
22/22
critical tasks completed without a use error
0
use errors across all critical tasks
15
Burn-care RNs completed the full task set across 9 clinical scenarios, after 30–45 minutes of training and a 1-hour decay period
0
Device drops, across every session
14/15
Participants rated the device user-friendly
7/15
Volunteered that it would improve efficiency and consistency in burn care, especially for institutions without dedicated TBSA experience
Within a couple of scans I stopped thinking about the device and just thought about the patient. That’s exactly what you want when you’re triaging.
Reflection
Passing summative wasn’t the end of the list. Three things I’d do differently, and one call I’d make again.
Clinicians described a label-first habit: with an x-ray or a phone camera, they mark the wound location before capturing it. The handheld inherited that order from the cart. But its field of view is fixed, and most first-time users can’t judge how much a single shot covers, so a region labeled up front may not match what the camera can frame. Capture first, label from the photo, may genuinely fit this hardware better. I’d put both orders in front of users in the first formative round instead of leaving it as a next-generation question.
Four pounds is light for a cart and heavy for one gloved hand. Under real conditions (gloves, a hot ward, an extended exam) it produces grip fatigue and real drop risk, and touchscreen response under gloves or long nails needs its own pass. I’d bring gloved, extended-hold sessions into formative testing so ergonomics shapes the design rather than the roadmap.
The summative study confirmed that the body-map suffix language doesn’t match how clinicians chart, the gap my rejected rule-of-nines proposal was trying to close. That evidence arrived after the decision. Next time I’d pair the proposal with clinician charting evidence from the start; it might have made the case for a regulatory pathway that doesn’t risk equivalence.
An in-development algorithm could auto-trace TBSA regions, removing one of the most error-prone, attention-heavy steps in the workflow. GPU headroom on the handheld (C2) and the algorithm’s own validation timeline didn’t line up with the delivery date. Shipping it would have meant underpowered auto-trace or a schedule slip neither funder could absorb.
I recommended holding it for a future release. Design decisions on a product like this sit where design value, engineering readiness, regulatory risk, and a fixed delivery date meet, and part of the job is recognizing when the right call is not yet.
Designing inside a regulated, life-critical product taught me to build an evidence chain for every decision, not just a rationale, and to speak RA, BME, and optics engineering well enough to keep pushing for the better version after a first proposal is turned down, while telling apart a fight worth having from a timeline worth protecting.
