Product design / A large German postal service provider / Current work
Turning complex postal logic into a product people can actually navigate
I joined the project after a short initial research phase had stalled, brought in to help turn two long-standing expert tools into one new B2B product. The hard part wasn’t giving old software a new interface. It was understanding how the two systems actually worked before I could decide what a user needed to see of that complexity.
As the only product designer on the project, covering both UX and UI, my work ran from domain reconstruction and information architecture through interaction design, detailed interfaces, and Figma components.
02 Reconstructing the domain
Understanding the system
before designing the product
My starting point was a detailed walkthrough of the two existing tools: one built for regular letter shipping, the other for more specialized formats like advertising mail and brochures. There was enough to take in that I recorded the session and went through it again afterward.
From there I worked through both applications on my own, clicking through screens and states, documenting functions, variants, and dependencies. I needed to understand what each tool actually did, why two separate tools existed for a related goal, and where their processes overlapped or genuinely diverged.
03 From postal logic to user logic
Separating postal logic
from user logic
Both legacy tools grew directly out of internal postal and production processes. Settings were named after internal categories, and the terminology assumed the reader already worked in the domain.
None of that was really about the software looking dated. Users had to understand the system before they could get their actual task done.
The interface does not
have to expose the way
the postal backend thinks.
01 / Legacy logic
My question for the new product was simpler: which of that internal logic does the interface actually need to expose? An internal delivery-time code like E+1 is perfectly clear to someone who works with it every day, but that doesn’t make it the right way to talk to a user who doesn’t.
02 / Translation
03 / Product structure
An internal delivery-time code like E+1 stays exactly that in the backend. The interface leads with the plain-language choice instead.
The new product also had to work for very different levels of expertise: specialists who plan shipments daily, and people who use it only occasionally.
04 A pattern that assumed the wrong workflow
A workflow too non-linear
for a stepper
Once I had a working model of the domain, I checked it against the existing pattern library. It offered a horizontal stepper for multi-step flows, but the real workflow wasn’t a sequence. Users needed to jump ahead, come back to an earlier step, add files later, or skip configuration almost entirely.
05 Navigation as a product decision
A navigation model built
for the actual workflow
That wasn’t a cosmetic problem. The stepper had no way to represent optional steps, no way to jump around, and no lasting orientation on long pages. So instead of adapting it, I designed a new navigation component from the ground up.
01 / Early exploration
02 / Developed sidebar
06 Product proof
What was created
What came out of this is one shared product model instead of two separate specialist tools, with the sidebar as its backbone. Shipment details, validation, and the rest of the operational screens sit on top of that same model.
Logistics and handover
The same model also carries the remaining operational decisions into the final handover.
07 How the work moved
Working through the logic
with domain experts
Requirements never arrived as a finished spec. I worked through the logic in a recurring session with domain experts, technical stakeholders, and other project stakeholders, regularly showing my current understanding, explaining my reasoning, and being upfront about where I was still unsure.
08 Early validation
Early validation
We tested an early version of the product with real users, including sessions I joined myself.The reaction was broadly positive. People generally found their way through the structure and could locate much of what they expected.
09 Looking back
Looking back
The biggest shift in how I think about product work: an existing process isn’t automatically a requirement for the new one. The better question is why it works that way, and whether that reason still holds.
Leave a Reply