Rebuilding UPS’s mission-critical document imaging system

The viewer connects to every report in the system, yet:

• a fix to an uploaded image could take days to show up, and new uploads didn’t appear for about three hours;
• moving between images was slow and tedious;
• there was no toolset, no filters by upload time, date or source, and no annotation.

Then one survey question, which other tools do you use, got an unexpected answer from a handful of people: Paint. They were exporting document images to scale, rotate and blur sensitive details: a slow workaround that moved documents outside a secure system.

• Mapped a new user flow around what auditors actually do, with the viewer at the centre.
• Gave the image the maximum screen space, and moved tools into a floating toolbox.
• Built in the Paint tasks: scale, rotate, blur and annotate, plus notes and filters by date and source.
• A/B-tested interface variants, iterated on feedback, and kept improving it after release.

I first proposed a bigger change. The team argued it would add a real learning load for thousands of daily users, and they were right. We redesigned it more carefully: new capability, familiar ground.

Nearly 40 reports, many unused, some built for specific locations or groups yet visible to everyone. Queries returned null, invalid or unrelated data. Discovery scored 3.07 out of 10, the lowest of all six measures. In one session a frustrated user questioned reports that even we couldn’t explain, and it kept happening.

• Broke every report down to each data field (index key) in a spreadsheet, column by column.
• Reviewed the purpose of each one with subject-matter experts and stakeholders: who uses it, for what decision.
• Merged near-duplicates, retired what nobody used, and reshaped each results grid around the context of its search.
• Took cues from other products and hand-picked elements that fit each flow.

It was slow, tedious work with little to show visually. But it was the only route to understanding why each report existed, and it kept us from carrying 17 years of clutter into a shiny new interface.

To change a user’s details or access, an authorised person raised a ticket with the support team, who looked the user up by ID, with no tracking. UPS had little control over its own system, and every manual change was a chance for a security mistake.

• Single sign-on through Azure Active Directory: one set of credentials across UPS apps.
• An admin view of every user, with bulk actions.
• Roles, countries, buildings and regions managed together, not one field at a time.
• Pull, sort and filter users from different paths, then change roles for a whole group at once.
• Split into sub-modules that work together or independently.

It wasn’t in the original scope, and it widened our delivery plan. But the ticket dependency touched every part of the application and left room for security mistakes. It was a control problem, not a UI gap, so we built it anyway.

Users were blunt: “Personally, I feel the website is outdated; it’s ’90s style.” In the survey, ease of use scored 3.47 out of 10. A 17-year-old interface was slowing people down before they even reached the data.

• Pitched a new visual direction to UPS, rather than reskinning the old one.
• Created the language with UPS’s internal design team, the owners of the enterprise style guides, specifically for the modernisation programme.
• Defined it as a full system, not just a look: fonts, colours and themes, buttons and communication, containers and wizards, data tables with sorting, filtering and editing, and the grid.
• Applied it across every rebuilt screen.

I expected UPS to say no, because a new look touched every internal app, not just ours. Building it with the people who own the guidelines turned a likely rejection into shared ownership.

Our teams spanned locations and time zones. Engineers, analysts and product owners each needed to understand not only how to build a feature, but why it existed. Without that, complex details would drift between handoffs.

• Documented the design journey incrementally, alongside product owners, as features took shape.
• Gave every feature the same structure: version history, brief, who it’s for, journey flows, annotated mocks, final mockups, an interactive prototype and feedback notes.
• Captured the reasoning, use cases and insights from both business and user perspectives.

Writing as we designed took time out of every sprint. The aim was to remove uncertainty and give every team a clean handoff, including the half of the team picking it up overnight.