LifeLens — Chris Karnes

A hardware company that needed a product.

LifeLens had built a wearable ECG monitor that actually worked. Small, microprocessor-powered, capable of capturing real-time physiological data in the field. Good enough to win a government contract on hardware alone.

The problem was there was nothing around it. No app, no dashboard, no product strategy. Just raw sensor data going into a database with nobody reading it. We had a presentation booked with military leadership and about four months to build something worth showing them. The users weren't test subjects in a lab — they were Servicemen, and the data we were tracking (heat stroke, cardiac distress, combat readiness) wasn't abstract.

How I worked through it.

With no existing users and not much time, we couldn't run a standard discovery process. Instead we started from what we knew — the data itself — and moved fast toward what we could test.

Understand the data

We catalogued every signal the device could output — heart rate, respiration, core temperature, geolocation — and mapped what each meant operationally. Understanding the data deeply let us make design decisions with confidence instead of guessing.

Talk to stakeholders

Quick sessions with senior leaders surfaced a consistent vocabulary: "command center," "leaderboard," "heads-up display." That told us how leaders think about monitoring their people — and we let it shape the product architecture before touching screens.

Sketch early, sketch fast

A lot of hand sketching at this stage. Getting rough concepts in front of people early was more useful than polished work nobody had reacted to yet.

Build the system first

Once we understood the data flow — wearable to phone to server to tablet dashboard — we built a shared component system before designing either app. That single decision is what made it possible to ship two products in the same timeline.

Test on myself

I wore the device on my own runs and watched my data stream into the database in real time. It was the fastest way to find problems that wouldn't have shown up any other way — and honestly kind of a strange way to spend a Tuesday.

Early hand sketches of the mobile app and command card layouts

Early sketches — data card layout, individual health view, and status list

Two apps. One system.

The product was really two things: an Android mobile app for individual Servicemen to pair their device and track their own data, and a tablet-based command dashboard for unit leaders watching their whole team at once. Different contexts, same underlying component system.

Command dashboard — real-time monitoring across the full unit

Individual mobile app — device pairing, onboarding, and personal health view

Early onboarding design — Connect your Ascent and Bluetooth pairing screens

Mobile and command views side by side, built on shared components

The two calls that mattered most.

Build the design system before building the screens

We were building two apps that needed to feel like one product. Rather than designing them separately and hoping they'd match, I spent a week upfront on a shared component library — health metric cards, status indicators, geolocation views. It felt slow at the time. It saved a lot of time later.

Componentize everything, including things we didn't need yet

I wanted every piece of data to exist as a reusable, self-contained component. The practical result: a user's geolocation looked exactly the same on their personal device as it did on the command dashboard. In situations where people are making quick decisions, that kind of consistency matters.

Early component system and wireframe explorations

Demoed in the field. Deployed in the Armed Forces.

The first real test wasn't a usability session or a stakeholder review. It was a live training exhibition outside Atlanta. I was on the ground helping Servicemen set up their devices and showing unit leaders how to use the dashboard while their teams ran drills.

It went well. The demo led to continued development and real deployment within the Armed Forces — a pretty good outcome for a product that didn't exist four months earlier.

4

Months

From zero to live military deployment. Two applications designed, prototyped, and shipped for a real field exercise with the US Army, leading to continued use and further development within the Armed Forces.

LifeLens deployed during a live training exercise

Designing for high-stakes decisions in the field.

A hardware company that needed a product.

How I worked through it.

Two apps. One system.

The two calls that mattered most.

Demoed in the field. Deployed in the Armed Forces.