Bringing an FDA‑cleared
burn assessment device
cart to battlefield
Spectral MD’s AI burn assessment technology is moving from a hospital cart to a combat medic’s handheld, sponsored by the U.S. Army Medical Materiel Development Activity (USAMMDA). As the sole designer on the effort, I rebuilt the experience around a device 4 lbs, iPad-sized, carried at the point of injury, without touching the FDA-cleared imaging core the new device inherits its clearance path from.
Overview
The 30-second version
What the product does, what I was asked to do with it, and why two very different stakeholders wanted the same redesign.
What it does
AI-assisted burn assessment, from a photo
- A clinician or medic photographs a burn wound; the AI identifies non-healing areas that likely need surgical intervention (grafting).
- Multiple scans are stitched together into a single TBSA% (Total Body Surface Area burned) figure, used to gauge overall severity.
- The same underlying prediction model already carries an FDA clearance on the cart-based product line.
What I was asked to do
Rebuild the cart into a handheld, without retraining the model
- The task: re-platform the FDA-cleared cart device into an iPad-sized handheld.
- Two funders, one build: USAMMDA required a device usable at ROC1–2 (point-of-injury aid stations, forward of any hospital); the company’s commercial strategy needed the same device to extend from burn centers and ERs into EMS.
- My role: the only designer on the project, owning everything from requirements definition through validated, delivered product.
Context
We had to make the device dramatically easier to use, without touching what it actually does.
The regulatory strategy set the shape of the whole project before I designed a single screen: the handheld would go through FDA 510(k) clearance using the existing cart system as its predicate device. That path only holds if the two devices are substantially equivalent, which meant the imaging principle, the five-camera capture system, and the core prediction algorithm were all frozen on day one.
That constraint defined my entire design space. I couldn’t change what the device does. I could only redesign how a user gets there, which turned this from a features project into an interaction-design project, end to end.
The hardware reality made that harder, not easier: five cameras, a battery, and thermal management still add up to roughly 4 lbs in the final handheld. That is a dramatic reduction from a full cart, but it is still a real object someone has to hold one-handed, in a glove, under a tent light, and it created interaction consequences that show up throughout this case study.
The clinical baseline made the stakes concrete. Looking at who showed up for validation, the field’s current TBSA tools are wildly inconsistent: the rule of nines, the Lund–Browder chart, palm-sized estimation, and at least one clinician who told us they just photograph the wound on an iPhone. Consistency and accuracy in that assessment is exactly the value this product is supposed to lock in.
0
changes allowed to imaging principle, camera array, or core algorithm
~4lbs
final handheld weight, down from a full hospital cart
4+
inconsistent TBSA methods observed in the field (rule of nines, Lund–Browder, palm method, phone photos)
1
predicate device the entire 510(k) pathway depends on
Scene Shift
From the burn center to the battlefield
Every design decision that follows traces back to one of these five rows. The last one matters most: it’s the reason I rebuilt the information architecture around a different hero metric.
Deep Dive 01
From “told after” to “guided before”
The AI is only as good as the photo it receives. Moving quality control from after the shutter to before it is the single interaction change that most defines this handheld.
Capture quality, moved upstream
The cart could afford a retake. A medic under fire cannot.
The cart’s capture flow is reactive: take the photo, then get told it was too close, too far, or that processing failed. In a controlled room, a retake costs a few seconds. At the point of injury, every failed capture is time not spent on the patient, or on cover.
We moved that feedback loop upstream, into three pieces of real-time, on-screen guidance during capture:
- Live distance guidance: the UI continuously shows the target imaging distance against the medic’s current distance, prompting them to move closer or farther before they shoot.
- Motion detection: using the device’s IMU (inertial motion sensor), a real-time “stay still” prompt appears the moment handshake would blur the shot.
- One-tap fill light: an on-screen LED button gives an immediate lighting boost in dark environments, no menu diving required.
The honest tradeoff
After repeated rounds with the optics team, real-time feedback on actual image quality — exposure, motion blur, underexposure — turned out not to be feasible on this hardware; the sensor stack can’t analyze a live frame that closely before the shot. The shipped alternative approximates it from three narrower signals instead: automatic white-balance and exposure correction applied at capture, the one-tap LED fill light for dark environments, and the motion sensor’s real-time “hold still” prompt. It’s not the same as the device actually reading its own image quality, but together the three cover most of what that would have caught. We didn’t land the ideal solution. We found the engineering-feasible one, and said so.
Deep Dive 02
Designing inside a frozen core
The scarcest skill on a regulated product isn’t proposing the ideal design. It’s finding the best available design once the ideal one gets rejected, and knowing when to shelve a good idea yourself.
Story A: The body map that couldn’t be simplified
Rejected for equivalency risk. Fixed anyway, in place.
My first proposal simplified the cart’s finely subdivided, Lund–Browder-style body map down to broad rule-of-nines regions, and removed the separate “suffix” sub-selection step entirely. For a user with minutes of training, fewer regions and one less decision meant real cognitive-load savings.
Regulatory Affairs rejected it: simplifying the body map risked breaking the substantial-equivalency argument the 510(k) submission depends on. The region system itself was frozen along with everything else in the predicate.
So I kept the original region structure and moved the fix into the interaction instead of the data model. Suffix selection is now contextual: highlight a body region, and its suffix options appear right next to it, in place, instead of on a separate step users could skip past. That alone addressed the highest-frequency error we’d observed on the cart: clinicians forgetting to select a suffix at all.
One postscript worth including honestly: participants in the later summative study still flagged that the suffix terminology doesn’t quite match how they chart clinically. That’s a quiet vindication of the original simplification direction, and it’s now on the roadmap for the next hardware generation.
Story B: The feature we chose not to ship
Knowing what should happen, and knowing when it shouldn’t, yet
The team already had an algorithm in development that could auto-trace TBSA regions, removing the need for a user to manually outline burned areas by hand. I knew exactly how large a leap that would be: it removes one of the most error-prone, attention-heavy steps in the whole workflow.
It didn’t make this generation. GPU compute constraints on the handheld and the algorithm’s own validation timeline didn’t line up with the project’s delivery date. Shipping it would have meant either underpowered auto-trace or a schedule slip neither funder could absorb.
I recommended holding it for a future release rather than shipping a compromised version. Design decisions on a product like this aren’t single-objective: they sit at the intersection of design value, engineering readiness, regulatory risk, and a fixed delivery date, and part of the job is recognizing when the right call is not yet.
Deep Dive 03
Learning from users, twice over
Two rounds of formative testing, one summative validation. I set the focus for both, moderated and observed every session, and owned the design response.
Methodology
Built on a URRA, run under IEC 62366 and FDA HF Guidance
Two formative rounds let us test direction cheaply before anything was locked: I defined what each round needed to answer, sat in on every session, and turned what we saw directly into the next iteration.
The summative validation that followed was formal: 15 practicing burn-care registered nurses, each given 30–45 minutes of training followed by a 1-hour decay period, then asked to independently complete every critical task in a simulated bedside environment. The full task set was built from our URRA (Use-Related Risk Analysis) and ran against the critical-task framework it defines, consistent with IEC 62366 and FDA Human Factors guidance.
01: Overlay controls, mistaken for AI controls
Users thought dragging a slider changed the AI’s answer
The original design used two continuous sliders to adjust the transparency of the non-healing and TBSA overlays, letting a clinician see the underlying photo beneath the AI’s markup. In testing, participants read the color intensity as something meaningful: confidence, or healing probability, and some believed dragging the slider itself could change the algorithm’s output.
On an AI-driven medical device, that kind of misread isn’t a cosmetic problem. It can directly shape a clinical judgment. We removed the continuous sliders and replaced them with two plain on/off toggles, trading flexibility for a visualization that can’t be mistaken for a control surface.
For AI output, visualization has to be legible and impossible to misread as control.
02: Wound list, fixed from use-error backward
The user wasn’t wrong. The workflow assumed something false.
Because capture distance is fixed, the camera’s field of view is effectively constant, which makes it hard to know what a scan will cover before shooting. Participants routinely discovered only after capturing that they’d missed a wound on the far side of a limb, or selected one that needed to be removed, and the original flow had no fix for that except returning all the way to the body map and starting over.
We added add/delete controls directly on the pre-capture wound overview screen, so a missed or extra wound gets corrected in place, without breaking the flow. The root cause was never the user’s judgment; it was a workflow that assumed a level of foresight the fixed field of view doesn’t actually allow.
03: History reports, and not making users choose
Under pressure, a forced choice is friction, not flexibility
The original flow opened every scan session with a modal asking the user to pick which report version they wanted to view. In an emergency context, participants found that actively unpleasant: they wanted the newest result immediately, not a decision to make first.
We now route straight to the latest report by default. Historical versions still exist, moved to the bottom of the results screen, visible only once a user scrolls all the way down looking for them. Cognitive load under stress became the first design principle behind every information hierarchy decision on this product, not an afterthought applied to one screen.
No forced decisions between the user and the result they came for
Also shipped, in brief
- Height and weight input moved from a scrolling wheel selector to a numeric keypad, a clear and consistent user preference in testing.
- The PDF report was cut from 4 pages to 2 and gained a TBSA image, so a physician can grasp patient info, TBSA, and the photo itself in one glance.
- Alert copy went through repeated rounds of plain-language editing until it could be understood at a glance under stress.
- The military build adds dog-tag scanning to auto-fill patient identity, cutting manual data entry when hands and time are both scarce.
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.
Strategy
One core, two missions
Same underlying product, same frozen AI core, but the information hierarchy had to bend around two very different definitions of urgent.
Military build
Sorted by TBSA%, for evacuation triage
- The patient list sorts by TBSA%, surfacing the most severely burned patients first when resources and transport are constrained.
- TBSA sits front and center on the results screen: it’s the number that drives the “evacuate or not, and how fast” decision at ROC1–2.
- Dog-tag scanning auto-fills patient identity, a feature with no equivalent need in the commercial build.
Commercial build
Sorted by last scan date, for ongoing care
- The patient list sorts by last scan date, so a physician managing an active caseload finds recently seen patients quickly.
- Non-healing area, the metric that drives a surgical decision, is retained but demoted; it belongs to the ROC3–4 hospital stage of care, not the point of injury.
- The cart era’s headline feature doesn’t disappear here. It simply steps aside for the metric that matters more in this context.
One design principle held across both: the fewest possible options per screen, with complex tasks (TBSA tracing, photo brightness and rotation) split onto their own dedicated screens, so a user under pressure can complete the workflow by hitting “next” without having to think.
Validation
What the summative study showed
Every number below reflects the aggregate summative human factors validation, run with practicing burn-care nurses in a simulated bedside environment.
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
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
0
Device drops, across every session
Reflection
What the study validated, and what it exposed
The summative study passing wasn’t the end of the list. It also surfaced the next generation’s open problems, which I think is a more honest way to close this out than pretending the device is finished.
Clinical habit says label first; a fixed field of view complicates that
In pre-design interviews, clinicians described their habitual workflow as label-first: with an x-ray or a phone camera, either a physician directs them to the spot or the camera itself can move freely to reframe, so they mark the wound location before ever capturing it. This device’s field of view is fixed, and most first-time users don’t have an intuitive sense of how much area a single shot actually covers. Labeling a region before capturing risks a mismatch between what got marked and what the fixed FOV can actually frame, so capturing first and labeling from the photo afterward may genuinely be the better fit for this hardware. It’s an open question for the next generation, not a settled one.
4 lbs is light for a cart, heavy for a glove
Under real conditions, gloved hands, a hot ward, holding the device for an extended exam, the weight produces grip fatigue and real drop risk. Touchscreen responsiveness under gloves or long nails needs its own pass.
Terminology still needs to meet clinicians where they chart
The body-map suffix language doesn’t yet match clinical charting conventions, the same gap my original rule-of-nines proposal was trying to close. Two knowingly deferred items sit alongside it: the auto-trace algorithm, waiting on GPU headroom and its own validation cycle, and further body-map simplification, waiting on a regulatory pathway that doesn’t risk equivalency. I know what the better version of both looks like, and why they have to wait.
Designing inside a regulated, life-critical product taught me to build an evidence chain for every decision, back it with a URRA, formative rounds, and a summative study, not just a rationale. It also taught me to speak a shared language with RA, BME, and optics engineering well enough to keep pushing for the better version of a feature even after the first proposal gets turned down, and to recognize the difference between a fight worth having and a timeline worth protecting.
My Role
Who did what
The question every reviewer of a case study like this asks first. Here’s the honest breakdown.
Owned end to end
- All UX/UI design deliverables, from early flows to final screens
- Workflow construction and requirements refinement, in direct collaboration with BME, engineering, RA, and PM
- Design handoff and specification for the software team
Set direction and drove response
- Defined the test focus for both formative rounds
- Moderated and observed every usability session personally
- Owned the design iteration that followed each round’s findings
- Led the finished-device demo for military stakeholders
Contributed alongside specialists
- Root-cause analysis of use errors from the summative study (protocol and report authored by an external human factors consultant)
- Software QA and V&V testing, in collaboration with BME
From requirements to a validated, delivered product, as the only designer in the room.