| Role | UI/UX Design · Competitive Research · Working Prototypes · Cross-functional Collaboration |
|---|---|
| Project Type | Feature Expansion |
| Platform | Web App · Mobile App · iPad App |
| Users | Architecture and civil engineering professionals involved in earthwork planning |
| Team | 5 people: Designer ×1, PM ×2, Web Engineer ×1, App Engineer ×1 |
| Timeline | Jan – Jun 2026 |
| My Contribution | 1. Designed two interaction models and validated them with working prototypes; |
<aside>
</aside>
A construction client wanted to calculate earthwork volumes such as pits and soil piles directly in Scanat, instead of relying on manual estimation or switching to specialized software. We turned this need into a production measurement feature across Web, Mobile, and iPad, allowing users to calculate volume from existing 3D terrain scans and inspect the result in spatial context.
My contribution: I researched the professional workflow, designed and prototyped two interaction models, explored 3D visualization for the calculated volume and reference plane, and followed through implementation and post-test iteration.
https://res.cloudinary.com/v7b2p5ho/video/upload/v1786514878/etlrsnrta1cmilgesacd.mov
Customers could already capture real-world sites as 3D models in Scanat, but earthwork volume calculation still required manual estimation or separate professional tools. The opportunity was not simply to add a volume number, but to bring range definition, reference elevation, calculation results, and 3D spatial context into one measurement workflow so users could make decisions directly from existing scan data.
1. How could we translate professional earthwork logic into an interaction that works directly in a 3D model?
Earthwork measurement involves concepts such as measurement range, reference plane, cut / fill, and target elevation. I first had to define what users needed to specify, in what order, and which feedback should appear in real time during the interaction.
2. When the ideal solution was too costly to implement, how could we simplify it without losing the core value?
The initial concept used a polygon to define a local area and project the calculation onto it. It was more complete, but engineering estimated that the implementation time and edge cases were beyond the scope of V1. We needed to revalidate the client's immediate use case and find a model that could ship faster while preserving room for later expansion.
3. How could we make an abstract volume result readable on real 3D terrain?
A number alone was not enough to help users understand the relationship between a pit or pile and the surrounding terrain. At the same time, an overly heavy volume visualization could obscure the original model. The design needed to balance a sense of mass, boundary clarity, terrain visibility, and overlap when multiple measurements coexist.
Earthwork measurement was a relatively new professional use case for Scanat. To frame the problem, I reviewed relevant industry tools and common practices, focusing on three areas:
The project moved through six stages, alternating between design work and working prototypes:
Requirement: Users needed to define an area on a 3D terrain model, calculate earthwork volume within it, and distinguish between cut and fill.
Key decisions:
Role of the prototype: After the static design, I built an interactive prototype to test interaction feel and edge cases. It helped resolve three issues:
https://res.cloudinary.com/v7b2p5ho/video/upload/v1786611085/brrx9gbgjzsfcwolwcbt.mov
Why the scope changed: Engineering estimated that polygon projection would take too long to implement and introduce too many edge cases for V1.
Simplified approach: After rechecking the near-term use case with the client, we found that one model usually contained only one pit or pile to measure. We therefore switched V1 to a simpler model: choose an elevation and generate a reference plane. This covered the primary scenario while keeping polygon-based measurement as a future extension.
Key decisions:
Role of the prototype: The second prototype validated reference-plane interaction and real-time area feedback. Testing was largely successful, but it exposed a clear issue: when several volumes existed in the same model, reference planes shared the same footprint and differed only in elevation, creating heavy visual overlap. We addressed this in two steps:
https://res.cloudinary.com/v7b2p5ho/video/upload/v1786611083/o2evvis9uyn49pewbthz.mov
Requirement: The volume needed to read clearly against the terrain, communicate a sense of mass, remain legible on uneven surfaces, and stay compatible with the existing measurement color system.
Key decisions:
I tested multiple visual treatments directly in the prototype. Together with Product and QA, we selected an enhanced translucent polyhedron because it preserved the spatial relationship between the reference plane and terrain while adapting well to irregular surfaces;
Volume visualization: four tested options
| Option | Result |
|---|---|
| A — Translucent cylinders | The terrain remained visible in some cases, but larger volumes still felt visually solid. The cylinder boundaries were also too obvious, making the result look like stacked tubes. |
| B — Surface overlay | It followed the terrain well, but read more like a surface treatment than a volume. Both boundary clarity and sense of mass were weak. |
| C — Translucent polyhedron | Close to the target: it communicated mass well without the stacked-cylinder effect, but the boundaries were too subtle and the overall color was too light. |
| D — Enhanced translucent polyhedron | ✅ Final direction. Stronger boundaries and color contrast improved readability while preserving the sense of volume. |
Internal testing showed that a single flat color made it difficult to distinguish the top and bottom of the volume. I continued tuning the effect in the engineering demo and introduced a gradient: the closer the geometry is to the reference plane, the lighter the color becomes.
