Problem Space

Luminary Cloud is a browser-based physics simulation platform. Early adopters needed to test rotating parts (like EVTOL propellers) and moving geometries (like airflow across cars).

The issue:

• Engineers had to write custom scripts to define motion.

• Non-coders struggled, leading to frustration, errors, and long setup times.

• Without motion setup, simulations didn’t reflect real-world performance — a critical blocker to adoption.

Research & Insights

I interviewed our primary users (CFD engineers) and target users (mechanical engineers) to understand their workflow:

• They thought in terms of physical parameters (RPM, axis of rotation, velocity) rather than code.

• They wanted precise control but also fast iteration when testing multiple scenarios.

• CFD engineers' mental model: “I should be able to create hierarchical reference frames, then assign geometries, and motion properties."

• Mechanical engineers' mental model: “I should be able to tell the system what moves, how it moves."

Key takeaway: Both groups framed motion in real-world physics terms rather than code, but with different levels of abstraction. CFD engineers needed hierarchical reference frames and precise parameterization to match simulation accuracy, while mechanical engineers sought a more direct, intuitive way to describe motion. The design challenge was to bridge these mental models into a single workflow—powerful enough for experts, yet simple enough for fast iteration.

Design Process

1. Mapping User Needs → UI Controls

• Rotational motion → center of rotation (coordinates), rotation vector

• Static vs dynamic problem → moving reference frame method, moving grid method

• Precision vs speed → mixing plane boundary condition, frozen rorer boundary condition

Constraint: The backend could not yet auto-bind geometry volumes to their corresponding surfaces.
Paradox: Motion is applied to volumes (e.g., air volume around a propeller), but mechanical engineers naturally think in parts (e.g., “this propeller spins”).

2. Explorations

• Worked with physicists to validate terminology and workflows.

• Explored allowing users to set up motion directly on geometry parts (made up of surfaces), and link those to volumes.

• Designed with the backend team toward eventual auto-linkage to reduce manual setup.

3. User Testing

• Tested a variety of use cases and edge cases with solution engineers and physicists.

• Conducted sessions with 3 primary users (CFD engineers) and 3 target users (mechanical engineers) in EVTOL and turbo-machinery contexts.

Insights:

• Users wanted flexible control over geometry surface groups without breaking associated motion.

• The interim step of manually linking surfaces to volumes created avoidable friction and was often overlooked.

4. Iterations

• Designed dynamic workflows, allowing motion setup through three paths:

  1. Add motion to surfaces

  2. Add motion to volumes

  3. Create a reference frame as a central motion hub

• A reference frame consolidated: geometry surfaces, volumes, hierarchy, and motion properties.

• Inserted a confirmation dialog when users added motion, to reduce errors (e.g., applying motion to surfaces without volumes, as in a moving wall).

• Introduced defaults and contextual tips, balancing manual precision with automation.

Solution

The final Motion Setup Workflow featured:

• Part or volume selection in 3D (choose propeller, wing, air, etc).

• Reference frame as a central motion hub

• Rotational motion inputs (center of rotation ((coordinates)), rotation vector).

• Timeline preview to visualize motion over time.

Visually, it combined clean numeric inputs with 3D preview feedback, so users instantly saw the motion they defined.

Impact / Results

• Reduced setup time from hours → minutes.

• Empowered non-coders to configure motion without scripts.

• Improved accuracy of simulations, unlocking use cases, such as: rotating machinery (propellers, turbines), moving walls (conveyor belts, moving walls).

• Drove adoption with early aerospace customers (motion was a top-requested feature).

Over 10 months, we shipped the feature to production. It laid the foundation for broader adoption, improved user activation, and a scalable pathway toward automation-driven engineering design.

Task completion rate:

• 75% of target users completed set up motion for their use case independently

• 95% of primary users completed set up motion for their use case independently

Reflection / Learnings

• Bridging physics rigor with intuitive UX required deep domain collaboration.

• Engineers value trust + precision — so clarity of terminology mattered as much as visuals.

• Next time, I’d integrate interactive presets (e.g., “Standard Propeller Motion”) to speed up onboarding even further.