Three clicks: carrying the expertise so the operator does not have to

Designing without a single persona

The common denominator fits in one sentence: produce effective signage, quickly, without knowing how to draw it. Anything that calls for a designer's judgment therefore has to leave the flow rather than be explained inside it.

The context of use is as varied as the jobs. The software gets opened on a tablet during a maintenance call, on a 13-inch laptop, on a fixed control station. The old interface was frozen at a desktop resolution. The rebuild introduced a responsive display for that precise reason, which seems secondary until you observe where the tool is actually used.

Three clicks, and why that was not true

The three-click promise had been around since version 3. It was mostly marketing: interface aberrations and software defects made it impossible to keep.

It is now roughly accurate, and it rests on a cascade rather than on simplification. A left-hand panel taking up a quarter to a third of the screen chains three decisions in order. Pick a product category, which already narrows things down to the job of whoever is editing. Pick a layout, which determines the consumable to load into the machine. Then open a library of pictograms and legal statements, filtered by both previous choices.

That is where the expertise gets transferred. The software does not guide the operator through a catalog, it removes by construction the options that do not concern them. Each decision shrinks the space of the next, and by the end the library on offer contains only what applies.

That build-on-demand was not possible before. The old version rested on 4,500 label templates maintained one by one, which ruled out any change made across the board: correcting a regulatory statement meant reopening every file concerned. We broke them down into reusable components, assembled at the moment of need. The code base dedicated to template creation shrank by roughly 60% in volume, measured on source size.

The rest of the screen is taken up by the live preview, larger than in previous versions, and by the manual editing options. The print bar sits bottom right, with an orange button. The interface is deliberately spare: adding buttons and settings moves the mental load around instead of removing it.

The standard written into the code

The business constraints, applicable standards, mandatory pictograms and legal statements were translated into logic classes that validate and calibrate the label before it is sent to the print engine. Modeling the rule in the code rather than restating it in documentation moves the compliance burden from the operator to the software.

The label is built on the fly by combining what the user needs with the consumable actually loaded, which makes the notion of a fixed catalog obsolete. That dependence on the consumable has a flip side: the software can only calibrate what stays inside its tolerances, which made it necessary to break QA out of its silo, from software code to the factory floor.

Producing a signage label does in fact call for two unrelated skills: composing a legible document, and knowing the applicable standards. Expecting both from an operator amounts to asking them to be a graphic designer and a regulatory specialist at once. So the software carries both areas of expertise, instead of leaving them to the user's own judgment.

What the tickets dictated

With no user research budget, the qualification of support tickets served as the source of decisions. The tool that logs them was built to prioritize the rebuild; it also pointed at the journeys that needed reworking.

The first was license activation, systematically manual and awkward. The software now displays an activation form automatically, asking only for the strict minimum: license number, email address, password. The license is a single one and the user chooses whether to activate it online or locally, which lets them deactivate their old version on their own to move across to the new one.

That left the case of workstations with no internet access. Their only recourse had been to call support and copy a key by hand. I built a dedicated page reachable from a phone on 5G: the user activates from the device that does have a connection, and receives their key by email. The constraint was not worked around, it was moved onto the only connected device the person already has to hand.

The tickets also supplied the material for the first tutorials, delivered as an in-app tour and searchable by keyword. I prioritized them on two criteria: the highest recurrences of training requests, and the features with high perceived value whose workings resist understanding.

Most of that effort went into getting started, and it is not an aesthetic choice. Quick setup shortens the delay between purchase and first print, which improves satisfaction and feeds the consumable use that carries the margin sooner.

Making the machine legible

An operator who does not understand what the printer is doing calls support. So I reworked the whole communication logic between the workstation and the machine, which a long stretch of work on the SDK made possible by opening a two-way exchange where there had only been a send.

The effects show up one by one. Print errors produce an explicit message rather than a silent failure. The confirmation message, until then displayed systematically on send, now appears only once printing has actually finished. A detection screen lists the drivers present on the machine, the printers online and offline, and the connection modes, USB or Ethernet with an IP address or a network name for DHCP. A log file records every request and payload exchanged, and the user downloads it in a few clicks to pass on to support.

Three seemingly minor details do the rest. An arrow shows which way the print comes out, which is enough to convey the layout rules and the finished product to expect. An interactive diagram accompanies the fine positioning settings on the consumable, because nobody orients themselves in two dimensions from numeric values. And the print rotates automatically to whichever direction wastes least material, which customers experience as a reduction in their cost rather than as a technical feature.

The floating panel, ruled out

I had considered handling the tools as floating panels. The appeal was real: it maximizes the drawing surface, and it is the convention in creative software.

That is exactly the problem. The convention assumes an expert audience, one that knows where it put its tools. Ours would spend its time hunting for them. So I kept a tool area in the same place as in the earlier versions, but organized into collapsible groups.

The bar manages itself according to available room: when too many groups are open for the size of the container, the one opened longest ago closes in favor of the newest. Users can pin the groups they reach for regularly, and those never close. It is a compromise between the space saved by a floating panel and the stability a non-expert audience needs.

Improving without disorienting

The old interface was austere and hard to approach, which produced friction from the very first launch. The graphic treatment was chosen to reduce that friction, and for nothing else. The constraint came from the users themselves: an installed base used to the earlier versions, whose bearings would have collapsed had we rethought the interface from top to bottom.

So the new version stays close to the third. I ruled out the visual break, which would have been more satisfying to design and more expensive to absorb for the people who use the tool every day. Simplification was done in stages, keeping the landmarks that structure the screen.

A usability debt does not get paid off in one iteration once it has settled into habits. The gain is only worth having if it is not paid for in disorientation, and you have to accept leaving some of it for the next version.

What makes iteration possible

Designing without user research means correcting often, and therefore being able to ship often. That is what the split adopted during the rebuild allows: a thick client written in React and Node wrapped in Electron, handling the print drivers and local resources and not meant to move again, with everything else served from a remote front end. We call that split "Zero Update": the client is installed once, and from then on the interface evolves online, with no further installation and no ticket raised with the IT department. Eighteen features have been delivered that way since going live.

The interface system is atomic, tokens included, typefaces, colors and borders: that is what keeps screens designed months apart consistent, and what allows a component to change everywhere at once. Integration goes through Tailwind, for low-level conventions that read immediately. I took the UX role on this project, but it is not my main job: being pragmatic was the condition.

A Matomo instance, configured to French data protection guidance, measures anonymized journeys and fills part of the research debt. It only covers the online version, since it assumes an outbound connection and our server being whitelisted: part of the installed base therefore escapes measurement, which lines up with the commercial goal of migrating users onto that version.

What eighty-five migrations said

I personally accompanied the first migrations, sixty-five on the customer side and twenty on the distributor side, where I stepped in as a technical member of their team. It was the only direct observation setup available to me, and it served to gather as much as to deploy.

In 40% of those sessions, users spontaneously said they were satisfied with how simple setup had become, with the new interface, or with both. After a week of use and an explicit question from me, the proportion rises to 85%. The first figure is the more interesting of the two: satisfaction you did not ask for is worth more than satisfaction you did.

The most tangible result does not come from there. Two new regions have been signed through our distributor since the rebuild. Their technical teams had been waiting for this version, which they had identified during the roadmap presentation given at the start of the work: they were waiting for a professional interface translation, responsive display and improved experience. The usability work did not only cut support calls, it removed a commercial objection.