InsideMaps.
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 runs a national LiDAR scanning network. Its order-tracking module had to coordinate clients, operations, and field scanners through every scan, with no shared source of truth.
Sole designer, end to end. Workflow architecture, role-based information design, interaction design, and production-ready UI specs built alongside engineering.
A role-calibrated dashboard and a 9-state status language that became the operational backbone for hundreds of weekly scans across U.S. markets. Shipped in three weeks.
A company at scale. A system built for one.
InsideMaps deploys LiDAR scanning operators across dozens of markets every week. Each scan order moves through a multi-party lifecycle: a client places an order, operations assigns a scanner, the scanner accepts and schedules, the scan happens, QA reviews, delivery confirmed. Before this system, every step of that coordination happened manually: spreadsheets, email chains, no single source of truth.
No pipeline visibility
Managers could not see at-risk orders until they had already failed.
Coordination by email
Scanner assignment and scheduling happened outside the system with no committed dates.
Manual data entry
Order creation was error-prone with no validation, no drafts, and no bulk import.
What we were working with.
The original module handled order tracking in a single 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. The system had no clear mental model for the people using it.
The original order tracking module. Generic table view, inline editable fields, no role-based access, no status taxonomy.
Design decisions have origins.
A 3-week engagement is not long enough for formal usability testing. It is long enough to map the actual workflow before touching any UI, to list every action each user type needs to perform, and to understand which failures in the old system were caused by design gaps versus process gaps. These four moments shaped every decision that followed.
The 9 status states were discovered, not invented.
Before touching any UI, I mapped the full end-to-end scanning lifecycle: order placed, scanner assigned, scanner accepts with a date, scan performed, QA review, delivery confirmed. Then I mapped every failure mode: no-show, late scan, scan rejected by QA, scanner declines after accepting. The 9 status states are what that map produced. They were not a design decision, they were the operational reality translated into a visual language.
The role split was proved, not assumed.
I listed every action each user type needed to perform. Admins: create orders, assign scanners, bulk update, export data, track delivery, manage access credentials. Scanners: view assigned jobs, accept with a date, decline, mark complete. The two lists shared almost nothing. Separate dashboards were not a design preference, they were the inevitable conclusion from that action map. Showing a scanner the admin view would add noise without adding capability.
The calendar step addresses one specific failure.
The original system let scanners accept jobs without committing to a date. The resulting failure mode: accepted jobs going silent until after the due date, with operations only finding out when the deadline passed. The calendar confirmation is not friction for its own sake. It forces the one piece of information, when the scanner will actually show up, that prevents the most common operational failure in the old workflow.
Column selection came from watching, not guessing.
Before finalizing which columns appeared in the main table versus the detail panel, I mapped which fields operations actually needed visible at a glance versus which ones they only looked up when troubleshooting a specific order. Fields needed at a glance: status, due date, scanner email, market. Everything else (access codes, contact details, coordinates, special instructions) belongs in the detail panel. That distinction directly informed the column configuration in both the admin and scanner views.
Same data. Radically different views.
The most consequential architectural decision was role-based access. Admins see 9 columns, full CRUD, bulk operations, CSV import, and scanner assignment controls. Scanners see 5 columns, just what they need to accept, schedule, and execute a job. The same scanning order appears in both views, stripped to what each operator actually needs to act on.
9 states. One language.
Every scanning order passes through a defined lifecycle. The status taxonomy covers both the success path and every failure mode. Getting this right meant operations could triage exceptions at a glance rather than opening each order individually.
Deliberate friction creates commitment.
When a scanner accepts a job, one deliberate friction point is introduced: before confirming, they must select an approximate scan date from a calendar. This single step forces the scanner to check their schedule before committing, creates a visible delivery expectation for operations, and moves the order to Defined status, signaling a human has taken ownership of the job.
Complex information, graceful structure.
A new scan order captures five categories: project metadata, property address with autocomplete lookup, contact person, access credentials, and special instructions. Scanners arrive at buildings secured by multiple access methods (mechanical lockbox, Rently lockbox, smartlock, gate access, host at home), so every access type has its own code field. Save as Draft supports operators who do not have all access codes immediately. Inline ZIP validation catches errors before they become fulfillment failures.
- Save as Draft, complex forms need multiple sessions
- 5 access types, structured around real building entry scenarios
- Inline validation, real-time error prevention at field level
Good operational software does not show everyone everything. It shows each person exactly what they need to act on.
Every screen designed for its operator.
Admin dashboard · Full pipeline view
Bulk operations · Assign scanner, export CSV
CSV import · Bulk order creation at scale
Order detail panel · Full context per order
Action bar · Request revisit, assign, edit
Scanner dashboard · Simplified field view
The original module. The redesigned system.
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.
Shipped in 3 weeks. Deployed across markets.
User roles. Zero redundant information.
Admin, client, and scanner views each surface only what their operator needs to act.
Status states. One shared language.
A complete lifecycle taxonomy covering every success path and failure mode.
Concept to deployed SaaS.
From problem brief to shipped enterprise dashboard in a focused three-week engagement.
The order tracking module became the operational backbone for managing hundreds of weekly LiDAR scan assignments across multiple U.S. markets.
InsideMaps Inc. · 2021
What carries over.
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.
Evidence over opinion.
Every decision traced back to the workflow map or a specific failure mode, not to taste. When a designer can show the origin of a choice, review stops being a debate about preference.
Design for the operator's mental model.
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.
Friction is a design material.
The calendar step added deliberate friction to create accountability. Removing friction is the default instinct; knowing when to add it is the senior one.
These are the same instincts I bring 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.