Designing order intelligence for a LiDAR scanning network at scale.
A scanning network had outgrown the tool that ran it. The fix was not more features. It was giving each operator exactly what they needed to act, and nothing else.
InsideMaps deploys LiDAR operators across dozens of markets every week. Each order moves through a multi-party lifecycle: a client orders, operations assigns a scanner, the scanner accepts and schedules, the scan happens, QA reviews, delivery is confirmed. Before this system, every step of that coordination ran on spreadsheets and email chains, with no single source of truth.
Managers could not see at-risk orders until they had already failed.
Scanner assignment and scheduling happened outside the system with no committed dates.
Order creation was error-prone with no validation, no drafts, and no bulk import.
The original module tracked orders in one generic view: no role differentiation, no structured scanner workflow, no status language operators could act on. Every field was editable inline, creating version-control problems. It had no clear mental model for the people using it.
The original order-tracking module. One generic table, inline-editable fields, no role-based access, no status taxonomy, the same view for every operator.
A 3-week engagement is not long enough for formal usability testing. It is long enough to map the real workflow before touching any UI, list every action each role performs, and separate the old system’s design-gap failures from its process gaps. These four moments shaped every decision that followed.
Before touching any UI, I mapped the full scanning lifecycle: ordered, defined (scanner accepts a date), scheduled, in QA, submitted, finished. Then the ways it breaks: a scan fails, a job slips past due, a scanner declines after accepting. Six healthy states, three failure states. The 9 states came out of the map, not a design decision: operational reality in one visual language.
I listed every action each role performs. Admins: create orders, assign scanners, bulk update, export, track delivery, manage access. Scanners: view assigned jobs, accept with a date, decline, mark complete. Clients: track status, see a delivery ETA, open and download the finished model. The three lists share almost nothing. Separate dashboards were not a preference, they were the action map’s conclusion: putting one role in front of another’s surface would add noise, never capability.
The original system let scanners accept jobs without committing to a date. The failure mode: accepted jobs went silent until after the due date, and operations found out only once the deadline passed. The calendar confirmation is not friction for its own sake. It forces the one fact, when the scanner will actually show up, that prevented the most common failure in the old workflow.
I mapped which fields operations needed visible at a glance versus which they only looked up when troubleshooting an order. At a glance: status, due date, scanner email, market. Everything else (access codes, contact details, coordinates, special instructions) belongs in the detail panel. That split drove the column configuration in both the admin and scanner views.
The most consequential architectural decision was role-based access. Admins get full CRUD, bulk operations, CSV import, and scanner assignment. Scanners get just enough to accept, schedule, and execute a job. Clients, who are external, get only their own orders and finished models. The same order appears in all three views, stripped to exactly what that operator needs to act on and nothing else.
Operations sees the whole network: a live dispatch map, the nine-state pipeline, and every at-risk order surfaced before it slips. Full control, because this is the operator who has to act on all of it.
The scanner carries one job at a time: today's route, the current capture, and a single decision, commit an arrival window. Everything the ops surface holds is stripped away.
The external client sees only their orders and finished models: status in plain language, a delivery ETA, and one button to open the 3D scan. None of the assignment, QA, or scheduling the ops team lives in. Same order data, a third lens.
Every order passes through a defined lifecycle. The taxonomy covers both the success path and every failure mode, so operations can triage exceptions at a glance instead of opening each order individually.
Every order is a card in exactly one state. Operations reads the whole network at a glance and pulls the at-risk column first, triage by exception instead of opening orders one by one.
Accepting a job introduces one deliberate friction point: before confirming, the scanner must pick an approximate scan date from a calendar. That single step forces them to check their schedule before committing, creates a visible delivery expectation for operations, and moves the order to Defined, signaling a human has taken ownership.
A new order captures five categories: project metadata, property address with autocomplete, contact person, access credentials, and special instructions. Buildings use different access methods (mechanical lockbox, Rently lockbox, smartlock, gate access, host at home), so each has its own code field. Save as Draft covers operators who do not have every code yet, inline validation catches errors before they become fulfillment failures, and bulk CSV import creates a hundred orders at once, each row validated on the way in.
Good operational software does not show everyone everything. It shows each person exactly what they need to act on.
Nine states, three roles, one shared language, rendered across the operations desktop and the scanner's phone.
One order, its state timeline, the assigned scanner and committed window, live capture progress, and every action the coordinator can take, in one place.
The captured 3D scan, coverage and point-density checks, and flagged defects, approve and deliver, or send it back for a rescan.
Where time goes and where scans fail, broken down by market, so the network improves instead of just running.
Utilization, coverage by market, and availability across the whole roster, the supply side of the operation.
Three weeks of design work. Same underlying data. Completely different operational clarity.
Same order data. The before: generic table, inline editing, no role logic, no status language. The after: role-calibrated views, a defined status taxonomy, and structured workflows for every user type.
Admin, scanner, and client views each surface only what that operator needs to act, nothing more.
A complete lifecycle taxonomy covering every success path and failure mode.
Rescans dropped 31% after the calendar confirmation shipped, the deliberate friction that made a scanner commit to a slot before rolling a truck.
The order tracking module became the operational backbone for managing hundreds of weekly LiDAR scan assignments across multiple U.S. markets.
InsideMaps Inc. · 2021
InsideMaps was not an AI product, but the instincts it demanded are the ones I bring to every interface I design and build. Three held up.
Every decision traced to the workflow map or a specific failure mode, not to taste. When you can show the origin of a choice, review stops being a debate about preference.
The same data, calibrated per role, so each person sees only what they need to act. Reducing what is shown was the feature, not the limitation.
The calendar step added deliberate friction to create accountability. Removing friction is the default instinct; knowing when to add it is the senior one.
The same instincts carry to AI products. An interface earns trust when it gives people control over a system they cannot fully predict, and surfaces only what they need to act on. Evidence, mental models, and deliberate friction are how you get there.
From enterprise teams to growing startups.