An Interface That Speaks the Operator's Language

When Technologists Redesigned the Interface: How One Feedback Session Changed Everything

The scada-coating project—a system controlling zinc electrocoating lines—had a problem nobody saw coming until someone actually tried to use it. The operator interface looked polished in theory. In practice, people kept confusing tech cards with rectifier programs, fumbling through tabs that made sense to developers but felt random to someone running production equipment.

That’s when the technologist team sat down with the designer and said: “This isn’t working.”

What started as a routine design review became something unexpected: a complete architectural rethinking, right there in the planning session. The core insight was brutally simple—the interface was treating information by how it was stored rather than how people actually think about manufacturing. Tech cards, processing programs, operation steps, and rectifier settings were scattered across tabs like loose papers on a desk. But in the technologist’s mind, they’re connected—they’re part of a single workflow.

The team made the radical decision to split what everyone had lumped together. The tech card—the actual manufacturing instruction—became the centerpiece. Everything else became satellites orbiting around it. Processing programs stopped being a secondary tab and got their own focus, tagged by coating type instead of buried in naming schemes. Suddenly, the operator could instantly distinguish between a zinc 10-micrometer program and a nickel variant.

Then came the operation steps editing. The existing interface had a beautiful graph—utterly useless for rapid modifications. Users had to click on graph lines like archaeologists carefully excavating buried treasure. The solution was counterintuitive: demote the graph. Make it a detail view, an optional tool. Put a clean table front and center instead, where each step parameter gets its own column. Simple, scannable, exactly how technologists already think in spreadsheets.

But here’s what made this process different from typical redesigns: they didn’t just accept feedback. They stress-tested it. Four distinct perspectives—designer, architect, technologist, developer—scrutinized every proposal. When someone suggested the “Line” tab was redundant, that triggered a real conversation about role-based access and whether a technologist even needs that view. When the multi-bath routing logic came up, they recognized it was complex enough to need its own UX investigation.

The real lesson? When you bring the right people to the same table and force them to think critically about each other’s domains, you don’t get a prettier interface. You get a system people will actually use.

The output now isn’t just a redesigned prototype—it’s a structured document splitting the original feedback from implementation instructions. Raw observations on one side, detailed prototyping guidelines on the other. No ambiguity. No interpretation games.

Two database tables walk into a bar. A JOIN request comes in asking “Can I sit here?” The tables reply, “Sorry, this conversation is foreign keyed.” 😄