Real-time 3D print monitoring in your pocket

01The problem

Stratasys industrial 3D printers run jobs that take hours or days and cost real money in material and machine time. Print status lived only on the panel at the machine, so operators, mechanical engineers, and industrial designers had no way to know a job had jammed, run out of material, or drifted out of tolerance until they physically walked back to it, often the next morning with a whole tray wasted.

This was workflow-heavy product work, not a status widget. A job moves through queued, printing, paused, warning, failed, and complete states, each with its own operator actions, across a fleet of printers a single engineer might be responsible for. The design had to make the right state and the right next action obvious from a phone, away from the shop floor.

02My role

I was the sole product designer on the mobile app, for iOS and Android, and I owned it end to end: the SME interviews, the job-state model and information architecture, every flow and screen, the empty, error, and loading states, and the hand-off spec to engineering. I drove scope decisions with the PM and iterated the states directly with the firmware and mobile engineers.

03The approach

I interviewed operators and engineers at customer sites and watched them work. The recurring theme wasn't "I want a dashboard," it was "tell me the moment something needs me." That reframed the app around exceptions and alerts rather than pretty live telemetry, and it changed a real decision: I cut the live layer-by-layer camera stream and fine-grained toolpath view from v1. The bandwidth and firmware work were heavy, and SMEs told me a clear "job X on printer Y hit a material fault" push meant more than a video feed. We shipped monitoring and alerting first and left the live view for later.

Because the fleet and its states drove everything, I designed the edge cases as first-class: offline printers, stale data with a clear last-updated timestamp, a job in a warning state versus a hard failure, and an empty state for an operator with no printers assigned yet. I set type sizes, contrast, and touch targets for a noisy shop floor where people wear gloves and glance at the screen for a second.

04What I built

The shipped iOS and Android app: a fleet view of every printer and its live state, a job detail view with progress and estimated completion, and push alerts that fire on faults, pauses, and completion so an operator can react from anywhere.

Scope was negotiated tightly with the PM and engineering. Firmware only reported job state on a polling interval, not a live socket, so I couldn't promise true second-by-second updates. Instead of hiding that, I designed around it, with an explicit "updated 2 min ago" timestamp and a pull-to-refresh, so the app never implied it knew more than it did. That constraint shaped the whole trust model of the screen, and it was cheaper and more honest than faking real-time.

05Outcome

The app shipped on both platforms and gave operators visibility into print jobs from anywhere instead of being tied to the machine. Early feedback was directional but consistent: engineers said they caught failed and paused jobs hours sooner, which meant fewer full trays wasted overnight, and support heard fewer "I didn't know it had stopped" complaints.

For v2 we brought back a version of the live camera view, scoped by what we learned in v1. Because operators used the app mostly to triage after an alert, not to watch prints, I designed the camera as a confirm-the-fault snapshot on the job detail screen rather than a continuous stream, which kept firmware and bandwidth cost down while answering the real question: is it actually as bad as the alert says?

06Reflectionoptional

Cutting the live view for v1 was the right call, but I under-designed the alert settings. Operators managing large fleets got too many notifications and started muting them, which is the opposite of what we wanted. If I did it again I'd design alert granularity and per-printer muting into v1 rather than bolt it on later.