UX for Ops: turning a logistics proof of concept into a change management tool

The cost of a chain you cannot walk back up

Between the moment I decided to treat the subject as urgent and the point where it was actually implemented, the company faced suspected quality defects.

With no traceability, none of those suspicions could be investigated. No way to identify a batch, a material, a production run. The only available answer was to ship a new product free of charge, without ever establishing the cause. The loss is twofold: you pay for the replacement, and you pay a second time by giving up on correcting whatever caused it.

That is the kind of situation that makes a decision easy to carry. I imposed this traceability requirement on the authority of my role, in a company that had never seen the point of taking it on.

Trello makes things visible, the application collects

This project extends a method I have been applying since Bollé Safety, but it changes its nature, and the difference lies in who has to fill in what.

Asking a marketing manager for a structured brief or an analytical summary is not always straightforward, but it is part of what the role is expected to deliver. Asking the same of a production operator or a support technician is not. It is neither a question of competence nor of goodwill, it is a question of fit between the tool and the job.

The organizational difficulties I have run into throughout my career are always multi-factor: company culture, governance and ownership of subjects, individual organization, command of the tools, capacity for abstraction, time available, motivation. Some of those factors can be moved, others mostly call for resilience.

Choosing the right tool and the right configuration therefore comes down to settling four questions: where to place governance, how to make the tool accessible to whoever has to fill it in, what level of data to expect from each person, and how to fit it into the way they actually work. Time and motivation generally sort themselves out once the first three are properly set. Culture, after that, shifts gradually.

A Trello board records a decision someone has declared. This application captures the data at the moment of the action, without the operator having to produce it separately. That is the only way to get reliable data out of someone whose job is not to produce data.

Designing for the operator before designing for the company

The application initially targeted three uses: stock management, order picking and production tracking. I chose to think of it as an aid to operators rather than as a monitoring device.

It obviously plays both roles, and it would be dishonest to pretend otherwise. But the order in which you address them changes everything. The tool was designed together with the operators; some functions with no value for company data were prioritized because they lightened the operators' mental load; and the interface, deliberately minimal though it is, was drawn so as not to feel austere.

The first level of buy-in is settled on perception, before any argument: is the tool experienced as one more constraint to put up with, or as an accessible solution that hands back some autonomy?

The question was all the sharper because a newly hired operations director is instinctively seen as the arm of top-down control. Building this application was the pretext for spending time on the floor, listening to the real difficulties, and occasionally spotting the blinkers produced by the fear of changing what has always been done a certain way. It is the best change management exercise I have had to run.

What the system records

The initial scope, delivered as a proof of concept to answer the urgency, rests on three capture points.

At **receiving**, the batch numbers of the raw materials, the quantities taken in, the operator and the date. In **production**, the material batches actually consumed, the references of the tools used so as to guarantee the manufacturing recipe, the quantities consumed and produced, the operator and the date. At **shipping**, the order number, the customer or distributor, the products and quantities declared, the total weight per package and therefore the number of packages, the operator and the date.

Every completed production run automatically triggers the stock update, the creation of the unique batch number and the printing of the traceability labels.

From those three points follows a stock management that needs no data entry of its own: raw materials, finished goods and buy-resell items adjust on every receipt, production run and shipment, with a timestamp on each movement. Stock data is no longer declared, it is derived.

Build rather than buy, and why

ERP and production software cover this scope. I did not go for them, for a reason that has to be named plainly: there was no budget allocated to process work, no budget visibility either, no annual or quarterly framing.

The contradiction is worth stating. Hiring an operations director presupposes that a need for improvement has been identified; giving him neither means nor horizon amounts to expecting the result without funding the cause. Building was the only option that depended on nobody else.

Two deliberate reasons were added to that. I chose the same stack as Markprint, the software we publish, in order to build skills on the technologies we make our revenue with. That produced a benefit I had not anticipated to this extent: a far better mutual understanding with our external developer, and therefore a real ability to size projects and challenge technical decisions rather than simply absorb them.

The second reason is AI assistance, which put within reach of one person what previously was not. With a working base in JavaScript, in operations and in UX, producing a fully bespoke internal tool became realistic.

What AI changed, concretely

I started with Bolt on the free tier for a first iteration, then tried Jules. Those ways of working felt constraining to me: they produce code, but leave architecture at the door.

The shift happened when agents arrived inside the development environment. Under Visual Studio Code, the pace changed by an order of magnitude, to the point where I rebuilt the application entirely: reorganizing the server so it could hold up under load, and moving to a pared-down atomic structure of atoms, components, layouts and pages.

That complete rework is the real marker. An assistant that speeds up writing saves hours; an assistant that makes an architecture rebuild conceivable for one person changes the nature of what that person can take on.

Bin-packing, or the favor that drives adoption

The bin-packing algorithm works out the optimal packaging format for a given order. It is a genuinely implemented function, and its value is not first of all economic.

Without it, an operator tries several boxes, or systematically picks the largest one and stuffs it with void fill. With it, the application gives the answer. The material saving is real, but the gain in buy-in is greater: it is the kind of function that moves a tool from the status of constraint to that of service.

These small things cost little time thanks to AI assistance, and they carry a disproportionate share of adoption.

What is running today

The scope in production goes well beyond the initial proof of concept: receiving, shipping, production runs and stock management, a proofing module serving as the interface between the design studio and customers, a support module that collects the help desk tickets, and a product marketing module that stands in for a PIM.

On top of those sit the dashboards, which are the whole point of all this collection. On stock: availability thresholds, detection of slow-moving items, activity volume measured in references moved. On support: average handling time, first-call resolution rate, ranking of issues by category and by product version. On logistics: inbound and outbound movement volumes, overall activity and breakdown by period.

This is where the loop closes. Every indicator exists because a work action produced it with no additional data entry effort, and not because someone filled in a spreadsheet.

The dependency, and what it says

I am currently alone on this development, which is the setup's main fragility and deserves to be said plainly.

Two routes are now open, since the project is recognized within the organization as worth having. The stack being shared with Markprint, our developer can take the application over and professionalize it. The other option is to hire an apprentice: the material exists, so does the domain expertise and the project management support, and the setting would be both empowering and supervised.

In its current version, the application is functional and in service. If I left tomorrow, its fragility would come not from its design but from the absence of resources granted to sustain it. Building a working proof of concept with no budget and no backing is not recklessness, it is what an operational function is expected to do when the decision to invest does not come.