Modernising instrument software without losing its operators or its integrations.

Why instrument UIs age badly, and why that's survivable

Instrument software outlives consumer fashion by decades: built against stable hardware, validated into workflows, sometimes frozen by compliance. The result is interfaces that look ancient and work, because the operators have absorbed the awkwardness into skill. That's the asset a modernisation can destroy: not the pixels, the fluency. Trained hands find buttons without looking; a rearranged screen taxes every run until new memory forms, and in a busy lab that tax is real money and real errors.

Modernise the model, respect the memory

The discipline: separate what's genuinely broken (workflow dead-ends, mode confusion, data trapped in the box) from what's merely old (styling, widgets), and spend change budget on the former. Of the three, data trapped in the box is ageing fastest: labs increasingly expect results to flow straight into their own systems, and to be read by software rather than retyped. Preserve the spatial and sequential skeleton where operators' hands already live; when a flow must move, move it for a reason you can defend in front of the lab manager. Watch real runs before touching anything. Field research earns its keep double here, because operators can't tell you what their hands know.

The migration path is part of the design

Ship the transition, not just the destination: side-by-side familiar modes where the installed base demands it, staged rollouts that let a lab validate before it commits, and release notes written for the person who runs four hundred samples on a Tuesday. Where instruments feed regulated workflows, the change process carries evidence obligations too: validation and training records that the rollout plan should produce by design, the same philosophy as usability evidence elsewhere. Integrations have muscle memory too. An export column renamed or a command retired without warning breaks a lab's automation the way a moved button breaks a trained hand, so version the interface, announce what's changing, and keep the old format alive alongside the new for as long as the familiar mode lasts.

The agent-native lens: reading results, asking before a run

When the buyer sends an assistant. A lab manager comparing instruments may ask an assistant to check what a brochure glosses over: which formats results export in, whether there's a documented interface for the lab's own systems, how long the software will be supported, whether an update comes with validation documentation. A modernised instrument answers all of that in published, current documentation; an assistant can only treat an undocumented interface as no interface. Once installed, the instrument gains callers of its own: an assistant asked for last night's results, an agent lining up the morning's queue. Expose those functions deliberately (as a versioned API, or as MCP tools an agent finds through tools/list) and keep reading apart from acting. Fetching a result for someone entitled to see it is low-risk. Starting a run that consumes samples waits for a person to confirm.

When the business runs on agents. The homework that keeps a modernisation honest suits agents. They can step through recorded runs on the old and new interface and list every place the sequence changed, so each move is one somebody chose; sort support tickets into what's broken and what's merely old; check which installed sites still depend on an export format before it's retired; and draft release notes per configuration. Validation isn't theirs to close. The lab's quality team accepts the change, the maker's engineer signs the impact assessment, and the training record names the people actually trained.

The prize

Done right, modernisation converts an interface liability into a moat: data that finally leaves the box cleanly, to the lab's own systems and to the software working for its people; workflows that new hires learn in days instead of months; and an installed base that upgrades willingly because the update respects them, hands and scripts alike. As more of the lab runs through software, that respect becomes a published contract as much as a screen layout. It's the exact brief our software practice runs inside the instruments sector, and the reason "don't break the lab" appears in our requirement sets as a first-class constraint.