Design Challenge

The legacy interface presented document properties as an undifferentiated list — version number, assignees, workflow stage, review history, metadata — each visually equivalent, none prioritised. For a quality manager opening a document, there was no way to orient quickly. Three things made this genuinely hard to solve:

1. Designing hierarchy out of a flat information model

2. Bridging paper and digital in the layout itself

3. Establishing the design language simultaneously

Designing hierarchy out of a flat information model

The design challenge was twofold. First, to determine what actually mattered most to the user at a glance, which turned out to be document versions, responsible people, and how far along in the approval process the document was. Second, to build a visual language that communicated those priorities without requiring users to read everything to find what they needed. That meant making deliberate decisions about typographic weight, grouping, colour, and layout — not as aesthetic choices, but as a way of encoding meaning into the interface itself.

Bridging paper and digital in the layout itself

Users coming from paper-based documentation needed to see the actual document, not just metadata about it, to feel confident they were reviewing and approving the right thing. The interface had to show a read-only PDF preview of the document alongside the workflow properties and actions. That's a real layout tension: two fundamentally different types of information sharing the same screen, each important enough that neither could be hidden or collapsed by default.

Editing content still opened Microsoft Word, a deliberate pragmatic choice that met users where they were, rather than asking them to learn an entirely new way of writing. The interface's job was to manage the process around the document, not replace the tool they already trusted for creating it.

Establishing the design language simultaneously

Document control was also the first major application of the new SimplerQMS visual system I was building from scratch. Every component decision here would set a precedent. The work had to solve the immediate UX problem and hold up as a scalable foundation at the same time.

Pulling the thread

When I sat down to design the interface, it wouldn't resolve. Workflow states had been documented before, but from an architectural perspective. Technically accurate, yet not organised around how a user thinks about a document's lifecycle. Approaching it from that angle surfaced ambiguities the existing documentation had missed.

I stopped designing and started there instead. Working with stakeholders, I mapped document states, the actions available at each state, and the distinction between actions a user could trigger and actions the system handled automatically — a difference that had real consequences for how the workflow behaved but had never been made explicit. That process surfaced structural ambiguities that had been causing confusion across product, engineering, and leadership, and produced a shared reference model that hadn't existed before. Only once that foundation existed did the interface design follow naturally.

Reflection

The most important move on this project wasn't a design decision — it was knowing when to stop designing. When the interface wouldn't resolve, that was a signal worth following. There's a meaningful difference between a system that's been documented for engineers and one that's been mapped for people — and closing that gap turned out to be the real design problem.

Designing for users in the middle of a paper-to-digital transition also sharpened something I've carried since: trust is a design material. An interface can be functionally correct and still fail if it doesn't give people enough confidence to let go of the process they already know. Sometimes the right answer is keeping something familiar — like Word — so the unfamiliar parts feel manageable.