Field OperationsMobile Platform

Field Operations Platform

A mobile platform that guides Starlink installation technicians through scheduling, on-site workflows, and job completion under real field conditions.

Role

UX/UI Designer

Period

2024 - Present

Scope

Technician mobile app: scheduling, installs, job completion

01/12·Overview

The challenge

Technicians ran installs from memory, paper, and phone calls. Every gap in guidance turned into a longer visit, a callback, or a failed install.

My role

Product design end to end: field workflows, mobile UI, and the pattern system engineering builds against.

The outcome

A field-ready operating tool: one legible next action in every job state, workflows that survive dead zones, and patterns engineering reuses without new design cycles.

Context

Install Pros runs Starlink internet installations across residential, commercial, and mobile sectors. The unit economics are unforgiving: a truck roll costs the same whether the install succeeds or fails, and every clarification call routes through a small dispatch team.

The business needed technicians to complete more installs per day with fewer escalations. Not a portal, but an operating tool that holds the job's state so the technician doesn't have to.

Users & operating conditions

The interface is used standing, outdoors, often one-handed, in direct sunlight, between a ladder and a customer conversation. Sessions last seconds, not minutes: a technician checks the next action, then puts the phone away.

Connectivity is unreliable by definition: the customer is buying satellite internet because coverage there is poor. The product has to assume a dead zone at the exact moment of work.

Constraints

Connectivity

Workflows had to survive offline moments without losing state or trust. A spinner in a dead zone reads as a broken product.

Attention

Field attention is the scarcest resource in the system. Anything that requires reading a paragraph on-site is a design failure.

Delivery

A small engineering team meant every pattern had to be reusable. Bespoke screens were a budget we didn't have.

Key decisions

Decision 01 · What does the home screen owe a technician?

One next action, not a dashboard.

Early layouts surfaced everything: schedule, job list, statuses, messages. Walking the flows against real install scenarios showed none of it mattered at the moment of use; the only question in the field is "what now?". The home surface was rebuilt around the current job and its single next step, with everything else one level down.

Trade-off accepted: Managers wanted richer overview data on the first screen. That visibility moved into the job list, accepting an extra tap for the office in exchange for zero ambiguity in the field.

Field Operations Platform home and overview screens — The home surface answers one question. Status, schedule, and history exist, but nothing competes with the current job's next action.

Decision 02 · How should an installation flow handle reality going off-script?

A step sequence with explicit, recoverable states.

Installs rarely fail at step one; they fail in the middle: a blocked roof, a missing part, no signal. The workflow models progress as discrete states a technician can pause, annotate, and resume, so a deviation becomes structured data instead of a phone call to dispatch.

Trade-off accepted: Modeled states cost more design and engineering than a free-form checklist, and they constrain edge cases the team hasn't mapped yet. We accepted that rigidity because recoverability was worth more than flexibility.

Installation workflow screens showing step states — Installation as a state machine: each step can be completed, paused, or flagged, and the flow knows how to resume from any of them.

Decision 03 · How much job management belongs in a technician's pocket?

Status, schedule, and proof of work. Nothing that belongs to dispatch.

Job views were stripped to what a technician acts on: today's sequence, each job's state, and completion evidence. Assignment logic and exception handling stayed with dispatch, which kept the mobile scope shippable by a small team.

Trade-off accepted: Some technician autonomy, like reordering jobs and self-assignment, was deliberately left out of the first release to protect operational consistency.

Job management screens with status hierarchy — Job management reduced to action: today's sequence and each job's state, scannable between tasks without re-reading.

System & workflows

Screen patterns like status chips, action rows, and step headers were defined once and reused across scheduling, installation, and job views. The intent was economic: engineering builds from rules rather than mockups, and a technician never has to relearn what a color or a position means.

Designing with implementation in mind is what kept the product buildable: every new screen since has been assembled from the existing pattern set rather than designed from scratch.

Outcome & reflection

Technicians get a single legible next action in every state of a job. The scanning effort the old process demanded is gone from the workflow itself.

Off-script situations became structured states instead of dispatch calls, which is the difference between a tool and a phone tree.

Engineering ships new screens from the established pattern set without a design cycle per screen.

Reflection

The open question is measurement: install duration and callback rate are the metrics this design should answer to, and instrumenting them is the next thing I'd push for. I'd also revisit keeping job reordering away from technicians; the consistency argument may not survive contact with experienced crews.

View Full Case Study (PDF) →

Next project

AgencyHub