Progressive disclosure
Show one step at a time. Billing and stationing details wait until they matter.
Automated Survey Request
A guided command-bar flow that lets surveyors request Mach9’s automated feature extraction without having to understand its billing or stationing logic.
IMPACT
One guided line replaced seven overloaded stages. A request no longer depends on knowing how Mach9 bills or stations data.
0
ENTRY POINT
0
COMMAND BAR, START TO SUBMIT
0
STEPS PRESET
0
BILLING DEAD ENDS
PROBLEM
Automated survey requests are Mach9’s main source of revenue. Every request that fails, or needs Customer Success to step in, costs both revenue and trust.
PROBLEM
Requesting an automated survey was so complex that users couldn’t find where to start, their KMZ and KML boundaries from other apps failed to upload, and the ones that did couldn’t be edited in the editor.
HOW MIGHT WE
How might we make requesting an automated survey simple enough that users get it right the first time?
RESEARCH
User profile
Walter
Project manager at a civil engineering firm
“I run multiple automated survey requests for the same dataset.”
- ROLE
- Owns projects end to end: field collection, data registration and QA/QC, then delivers a database that clients load into ArcGIS.
- GOALS
- Turn large mobile datasets into client-ready features with as little rework as possible.
- BEHAVIORS
- Runs several requests on one dataset: to split it into projects with different templates, or to catch objects the first pass missed.
- TOOLS
- Buffers the trajectory centerline at 15 m and trims against KMZ overlays. Draws polygons only for targeted edits like road widening.
- PAIN POINTS
- Settings that don’t match how the firm works. Stationing tools go unused, and Task Manager doesn’t fit its project structure.
- NEEDS
- Extraction areas that can be reused across requests, and defaults that trust the trajectory centerline.
User flow
- 01One step does too much, and its tools mix shapes and lines behind unclear icons.
- 02Nobody knew what the orange “billing centerline” was.
- 03Users had to understand internal billing logic, and some picked the cheaper option, not the right one.
- 04“Billing centerline” appears again, so users assumed stationing changes cost. It doesn’t.
- 05Station spacing sits two stages away from the stationing source it belongs to.
- 06After drawing a polygon, users jumped straight to Submit and skipped the rest.
DESIGN PRINCIPLES
Consistent mental model
An extraction area is drawn, selected and edited like any other line in the app.
Fitts’s Law
Work primarily in the command bar, so the cursor and attention stay in one place.
PROCESS
9 design rounds
3 design reviews with 5+ engineers to align on design decisions and settle the technical dependencies.
ROUND 01
Step-specific workspace
ROUND 02
Entry point and panel options
ROUND 03
Dedicated toolbar test
ROUND 04
Sketches and a subpage panel
ROUND 05
Tools in the default toolbar
ROUND 06
Before vs. during extraction
ROUND 07
The full step sequence
ROUND 08
Mobile and aerial datasets
ROUND 09
Final flow
Key decisions
D1
Where does the workflow live?
EXPLORED
One panel with every setting. The old overload, just moved.
EXPLORED
Inside the survey panel. Familiar, but already full, and extraction got lost in it.
CHOSEN
Extract features, next to Task Manager. A short step panel opens only once an area is picked.
D2
Which toolbar draws the boundary?
EXPLORED
A dedicated extraction toolbar. Five-plus tools users would only ever see here.
CHOSEN
The default app toolbar. Define area sits with the other editor tools, with buffer, polygon and KMZ in a popover, the same way TINs draw boundaries.
D3
When do users define the area?
EXPLORED · WORKFLOW B
During extraction. Two jobs in one step, and the area is gone once the request is sent.
CHOSEN · WORKFLOW A
Before extraction. Areas stay in the document, so a project manager can reuse them across several requests on one dataset.
D4
What does billing ask of users?
EXPLORED
Infer billing from the datasets in view. No question at all, but nothing showed users what set the cost.
CHOSEN
Billing type in the command bar, preset to a sensible default. Users confirm it in one step and change it only when needed.
Mid-fi prototype
High-fi prototype
VALIDATION
Every open question was settled with engineering before it reached high fidelity.
DESIGN REVIEWS
Three reviews with 5+ engineers decided where boundaries are saved, how billing is set, and where results land.
IN-APP TESTING
The high-fi flow runs end to end in the app on a real mobile dataset, from selecting areas to submitting the request.
RELEASE
- JUL 3First workflow explorations
- JUL 20Design review with engineering
- AUG 7Storyboard shared at the company all-hands
- SEP 8Final mid-fi flow
- OCT 24High-fi flow running in the app
- DECPlanned release
TAKEAWAYS
- 01Defaults are a design decision. Presetting billing, stationing and postprocessing lets most users finish without learning the system behind them.
- 02I’d put the billing step in front of customers sooner. It changed the most across rounds and was the last decision to settle.
- 03Next: let users review results before they merge into the file, so rerunning an area never duplicates features.