25% faster X-ray inspection, inside a fixed Windows application

The client is a large manufacturer that builds electronics and equipment. One division makes X-ray machines for non-destructive testing, used to inspect construction columns, heavy machinery and infrastructure. The division had built both the machine and the software that operators use to run scans and review images. The software was written in Visual C++.

The project head approached us with a clear complaint: the software was laggy, looked dated, and operators were not inclined to use it. It slowed them down. The stakes were real. This software helps people inspect structures where a missed flaw matters, so the interface had to get out of the operator's way.

Our first assumption was that we were about to design something complex. We were wrong. The software itself was small. The difficulty was in the thinking behind it, and in the goal.

The goal was not the best possible software. It was to make operators faster without making them relearn their process.

I was the only designer on the project. I handled communication with the client's project head, the user research, the product design and the handoff to developers. A principal designer at YUJ mentored me. A developer from the client's team guided me on Visual C++ constraints. I am also an engineer, which meant I already understood the libraries and what the toolkit would and would not allow. That let me design only what could be built.

This was a traditional Windows application, so the freedom of web design did not apply. Anything beyond these limits meant rewriting code, which the client would not do. Every idea had to survive one question: can this be built without changing the codebase?

• Operator and developer calls. Several remote calls with operators and with the client's developers, to understand what operators actually do in a session and which tools they use daily.

• Desk research. I studied tool-heavy products, including Autodesk software, Illustrator and Microsoft Word, to learn how they surface frequent tools without hiding the rest.

The software had many tools, and they were scattered under different ribbon categories. Operators could not find the ones they needed, even though the tools existed.

• I kept the ribbon, which was the platform's default, and moved the tools operators use every shift out of it into permanent positions on screen.

• Rejected. A fresh redesign with new navigation. It would have forced operators to relearn their work and the client to rewrite code.

• Why. The brief was speed without losing the current process.

• The trade-off. The interface stayed visually conventional.

I ranked the tools by how often operators use them, then placed them where the work happens.

• Top. Ribbon navigation for everything else.

• Left. The marking and measuring tools used most: square, rectangle, circle and a scale to measure the distance between two points. This follows the tool-rail pattern from graphics and 3D software.

• Bottom. Zoom in, zoom out and a magnifying glass for looking closer at the image.

• Right. The actions operators repeat: start X-ray, stop X-ray, snapshot and print.

The operator's flow runs left to right across the screen: start the machine, capture the image, mark and measure flaws on the left, inspect closer at the bottom. Everything an operator needs is visible from the first glance.

The first version was a light interface, which is my default for most platforms. But operators work in dark rooms, and a bright screen strains their eyes over a shift. I switched to a mild, low-brightness, low-contrast blue taken from the client's brand colour.

The trade-off: it looks less polished than a typical modern interface. That was a deliberate cost. It was the right choice for the people using it, even though it was not the prettiest option.

We listed 15 tasks operators perform every day, including capturing the X-ray, exporting it, annotating it and using histograms. At least three operators performed each task on a call, once with the old software and once with the redesign. We compared the times.

I delivered the font files, icons, screenshots and the Figma file. Because the client's developers were not used to Figma, I ran a tutorial on how to export assets and copy code from it.