Mobient
A replayable digital twin of a smart spacecraft floor, with a nine-tool engineering suite
Replay Viewer, Interactive Design Tool, & Engineering Suite
Year
2025-26
Tools
Design and product
Figma
Technology
Vanilla JavaScript, Chart.js, React, TypeScript, Vite
Development and delivery
GitHub, Vercel, Vitest, Claude Code
Deliverables
Audience mapping & three-door IA
Replay viewer & A/B comparison
Scenario-aware chart system
Simulation engine front end (with an electrical/M&S engineer)
RSL Forge interactive design tool
Nine-tool engineering suite
Visual system, UX copy & help layer
Product Team
My Team
1 UX/UI Designer & Front-End Developer
1 Electrical/M&S Engineer
My Role
UX/UI Designer
Front-End Developer
Tools
1 Replay viewer, 8 scenarios
1 Interactive design tool, RSL Forge
8 Build & calibration tools
Summary
I designed and built twin.mobient.org, the public digital twin for Mobient’s Agentic Gravity Synthesis (AGS): a proposed spacecraft floor whose tiles of electromagnet coils would recreate what gravity does at a surface, holding, guiding or releasing the crew and cargo on them. Before the hardware exists, my job was to make the floor’s simulated decisions legible and trustworthy to reviewers, newcomers and engineers, through a step-by-step replay and nine design and calibration tools. An electrical/M&S engineer built the simulation engine; I worked on it as the front-end developer.
Three Readers, One Twin
Before restructuring anything, I mapped the twin’s audiences, audited its homepage and navigation, and learned what each signal means in working sessions with our electrical/M&S engineer. A floor making fresh decisions many times a second is hard to judge from outside, and each reader hit a different wall:
a) Reviewers deciding whether to trust the control logic need proof, but a moving chart can’t show whether a decision was logged or just animated.
b) Newcomers without engineering backgrounds met seven equal tool cards and no obvious first click, then dozens of signals (force, heat, tipping margin, internal “prices”) where a gap or two overlapping lines could read as a failure that never happened.
c) Engineers calibrating the floor need to tell a bench measurement from an estimate at a glance.
Design Principles
I turned those findings into four rules, and reviewed each live replay scenario by scenario and fixed whatever broke them.
Key Principle Show evidence, not animation. Every line is drawn from a logged run, and the same inputs always replay the same history. An illustrative animation would have looked smoother, but no one could check it.
Key Principle Give each reader one clear way in. My audit found a homepage that read like a developer directory, not a product. Working from a navigation strategy and route map I wrote, I rebuilt it around three front doors: the Replay Viewer for reviewers, RSL Forge for hands-on exploration, and the Build & Calibration Suite for engineers. The other tools moved one click deeper, a trade I accepted so newcomers had somewhere to start.
Key Principle Explain on demand. Inline explanations crowded the charts for experts, so help comes in layers, from an info tip to a full plain-English guide.
Key Principle Label what’s estimated. Pre-calibration numbers are marked approximate and sample data stays labeled as sample, because an unlabeled estimate looks exactly like a measurement.
Designing the Replay Viewer
-
One Timeline Drives Every Chart
Reviewers need to see cause and effect in one moment. Pick a logged scenario and it plays like a video, step by step, while one scrubber moves everything together: a dot on every chart line, that step’s exact values and an animated heat map of the floor’s coils. The cargo convoy plays slower so heat visibly builds pass by pass, and the gaps between passes are labeled so they don’t read as a loss of control. -
Explained in Place
Terms like “prices” could read as dollars, so help sits where the question comes up. “How to Read This Replay” opens a rule of thumb and a color-coded card per chart family, hovering any chart shows every value at that moment, and the copy translates as it goes: those prices are internal scarcity scores.
- charts chosen per scenario- a generic six-panel dashboard kept every scenario uniform but drew flat or misleading lines for several. I traded that uniformity for charts that explain each scenario, such as alternating footstep lanes for crew walking and a braking chart for the emergency stop. Identical lines merge into one labeled line, heavy overlaps turn dashed and on/off signals get their own lanes, but real values are never nudged apart.
- requested vs. admitted- plotting only the request made a refused command look carried out. In the emergency-stop and tow replays, a faint dashed line shows what was asked and a solid line what the floor admitted, stopping where it refuses as the readout names why. When a long refusal code made that readout jump, I reserved two lines for that one cell rather than widening the whole card. The copy makes clear that refusing a command isn’t letting go of the load.
- A/B compare- reviewers shouldn’t have to take the twin’s central claim on faith: the same inputs always produce the same logged history. Two independent runs ship with the site, and “Compare A vs B” shows a green “IDENTICAL” banner with a line count or the first line that differs. A “Replay-Verified” badge links to a proof page with three copy-paste ways to repeat the check.
The Suite Behind the Twin
A replay is only as trustworthy as the numbers behind it. Engineers needed a toolchain to turn boot and sled designs and bench measurements into versioned calibration data, and the biggest risk was mistaking an estimate for a measurement.
-
Build & Calibration Suite
I designed a pipeline of nine linked tools that lets engineers: - shape the passive magnetic pad on a boot sole or sled rail in RSL (Reactive Surface Locomotion) Forge, drag it across a floor tile and press play to watch the tile grab, hold and heat it while a score panel grades the design,
- compare predictions with bench measurements and calibrate coil force and heat, shown as two parallel steps under one “Calibrate” banner after my first diagram implied one depended on the other,
- plan the tile’s packaging in a tool whose 48 tabs I regrouped into nine lifecycle groups, check sensor timing and safety-step order, and test a design across crew, missions and faults,
- publish the results as a versioned CalibrationPack,
- stay oriented as the tools multiply, with a numbered, clickable pipeline rail that scrolls sideways on phones, guarded by a 27-point navigation test.
-
Wiring the Physics Into Forge
Engineers need to watch the physics respond as they shape a pad, but our electrical/M&S engineer’s simulation engine runs in Python, which a web page can’t call directly. So Forge runs a simplified browser model that pulls many of its numbers from a file the twin exports, and a test fails if Forge’s numbers drift from that file. As the front-end developer, I integrated that physics with the Forge display: each frame of a footstep drives the coil heatmap and the live “This frame” card, and temperature builds along the path already traveled, on the twin’s temperature scale. Rerunning the full simulation mid-drag made placement feel sticky, so the boot follows the cursor with a quick one-position check and the full simulation reruns only on release. -
Honest by Default
The tools estimate; they don’t certify, and the Suite says so plainly. Evidence levels stay visibly separate, from simulated to measured to ready: sample data can never reach “ready” or show a reassuring green, and Forge stores bench results apart from its estimates so neither overwrites the other. When Forge’s sled-propulsion check passed a rail that should have failed, I tightened it so a pass means the run succeeds at its worst moment, accepting that a stricter check fails more designs.
Results
The twin is live at twin.mobient.org, labeled pre-calibration, and each audience now has a way in. A reviewer can pick any of 8 scenarios, watch the floor admit, throttle or refuse, see why at each step, then repeat a 54-file, byte-for-byte proof. A newcomer starts from three front doors, and an engineer can see whether a number is estimated or measured.
I took it from a static replay viewer in February to 15 public pages in one visual system by mid-June, across 547 commits. I designed the product end to end, from audience mapping and information architecture to visual design, naming and copy, and built its front end with AI assistance, including the nine tools and their 988 automated tests. On the simulation engine, I worked as the front-end developer alongside an electrical/M&S engineer. My own reviews of the live site, plus feedback from the team, drove the polish, from a card that broke the chart grid’s symmetry to three drag-mode flaws I found using Forge.