What We Heard
We visited installation sites and observed technicians directly.
One technician told us: "I can do my job without destroying my back." Not "this is more efficient." Not "this saves time." But "my body doesn't hurt."
That's the quote that stuck.
The physical barrier—climbing, contorting, balancing equipment at height—was so painful that technicians tolerated cryptic parameter names. "DEC Rollover Value" was annoying, but not annoying enough to complain about when your knees were already killing you.
Once we made it easy to reach the controller, people suddenly cared whether it was easy to understand the controller.
The Problem
Twenty feet up a conveyor system. Laptop in one hand. USB cable in the other. Trying to change one parameter value while your lower back screams.
This was the job.
We visited a Dematic installation site—one of those massive warehouse automation facilities with conveyor systems running everywhere. Technicians climbing into equipment bays to configure motor controllers. Each xMC controller had hundreds of parameters with names like "DEC Rollover Value." To change any of them: physical connection. Laptop. Cable. Height. Contortion.
They'd do this dozens of times per shift. Up the ladder. Plug in. Change one value. Down the ladder. Move to the next motor. Repeat.
By end of shift, bodies were wrecked. Chronic back strain. Knee pain. Safety incidents from working at height. One guy showed us his trick for reaching an awkward controller—he'd jam a broom handle in to hold a panel open while he twisted sideways. Resourceful. Also, you know, a pain in the ass.
Someone asked: what if they didn't have to climb?
The Solution
Wireless configuration system with Bluetooth dongle (wPCM) enabling parameter changes from the ground. No more ladder climbs.
Parameter-as-object architecture treating each setting as an entity with display name, validation rules, category, documentation, and change history.
Organization layers—categories, filters, search—making 200+ cryptic parameters navigable instead of overwhelming.
Validation guardrails preventing invalid values and incompatible firmware combinations. Technicians could trust they wouldn't break anything.
Change history and audit trail showing who changed what when, building confidence and enabling troubleshooting.
Mobile-first interface supporting both novices (guided flows, clear organization) and experts (fast paths, bulk operations).
The Method
Simple ask—wireless configuration tool. Bluetooth dongle. Mobile app. Change parameters from the ground.
But removing the physical barrier exposed the cognitive one.
This is where object thinking kicked in. Same approach as VermeerOne—ask what exists, map the relationships, let the structure reveal the interface.
PARAMETER became an object, not an attribute. Each one carries: system name, display name, valid range, data type, category, documentation, change history. Once you treat parameters as objects, you can search them. Filter them. Validate them. Show change history.
wPCM (the wireless dongle) — firmware version, battery status, connection state. Not just a pipe. An entity with its own lifecycle that users need to understand.
xMC (the motor controller) — model, firmware, installation location. The thing that owns the parameters.
PARAMETER CHANGE — previous value, new value, timestamp, who did it. This is the audit trail that enables trust. When a technician changes something and walks away, someone else can see what happened.
We weren't building a parameter editor. We were building a system that understood motor types, validation rules, firmware compatibility, and user permissions—all through object relationships.
What We Learned
Physical pain hides cognitive pain. Solve the first, the second becomes visible. Organization is the feature when you have 200+ cryptic options. Validation builds trust.