top of page


The client support team at a mail sorting service provider was using an internal web application called Score to manage client data. Score had been scaling poorly with the growing number and complexity of clients.

The support team needed a tool that could keep up with their fast paced work. This is how I transformed the information architecture of Score to better align with their needs.


Score Header.png

Role and Organization

Lead UX Designer at Pitney Bowes


January 2022 - April 2022



Product management, engineering


Figma, FigJam


This project was my first venture into service design. Score is an internal product that affects the client experience: the support team uses it when interacting with clients, and Score is the source of the data that is posted to the Finance Portal, a tool clients can access directly.

Improving Score is an act of streamlining internal operations, which in turn supports clients better in their journeys with Pitney Bowes.

Key Contributions

  • Led user interviews and observations

  • Produced information architecture diagrams

  • Designed interactive wireframes in Figma

  • Transformed complex technical topics into understandable concepts


Changing the information architecture was key to improving the usability of Score. My strategy consisted of four phases:


Understand the current solution


Identify user pain points


Propose a solution


Get user feedback


Understanding the Current Solution

When a new client joins the mail sorting service provider’s network, profile data is stored about them in Score. This data includes their contact information, types of mail they send, and pricing agreements.

The client support team is the main user of Score. It is the source of truth for client data. They reference it when providing support to clients and keep it updated as information changes.

Current solution wireframe.png

A wireframe of the current design of Score.

Data Constraints

Before I jumped into evaluating Score, the team informed me that I should understand how data about clients is collected and stored within the internal databases. This structure existed as a constraint - the design of Score’s information architecture must follow it.

This is what I learned:

Client profile data structure.png

Each facility contains unique profile data about Acme because they sort different mail types.

Acme Corporation sends a lot of mail to their customers.

Acme hires a Mail Sorting Service Provider (MSSP) to help them process the mail by pre-sorting it.
(Acme is now a client of the MSSP).

The MSSP has sorting facilities across the USA that process Acme’s mail.

Score's Current Information Architecture

After building domain knowledge around the business processes, I examined Score and visualized the current information architecture.

Score existing information architecture.png

The key takeaway is that the entire experience is shaped by the user needing to choose one sorting facility to view data under.


I demonstrated this attribute in a user flow, informed by observations and interviews with the client support team. This flow describes a common task: the user wants to see data for a client (Acme Corporation) at multiple facility locations:

Existing user flow.png
Current Solution

Pain Points

The observations and interviews with users uncovered their chief concerns.

Facility Location Filter

Users can’t see all facility locations for a client

It’s inefficient to navigate between locations

Data is stored in multiple places, making support and maintenance difficult

Client Profile

Too many pages leads to high cognitive load

Users have to remember where to find certain data

No hierarchy to the information

Page load times of up to 5 minutes

Client Support Team Quotes

Avatar 88

“It’s hard to jump around and see all the data [for a client].”

Avatar 109

"Data is repeated [for each facility]. When there's a change, we have to go in and make sure it's changed for all facilities."

Avatar 106

“I never even use some of these pages [on the client profile] because I don’t know what’s in them and I’ve never needed it.”

Avatar 103

“The load times are so terrible that whenever I click on something, I go and get a coffee. It’s usually up by the time I get back.”

Pain Points

Designing a Solution

I understood that the pain points called out efficiency and cognitive load. I proposed an information architecture that provides a top-down view of the client: the user can see all clients, all of their facility locations, and easily navigate between them.

This way, a user can spend less time looking for information and more time using it.

Score proposed information architecture.png

In a user flow, the user is able to view data for Acme Corporation and their multiple facilities much more quickly and in multiple ways:

Proposed user flow.png

In addition, I condensed the number of pages within the client profile from 9 to 5. I grouped data based on similarity:


The grouping made it easier for users to the find data. The names of the groups became the tabs on the profile page.


User Feedback

The users tested the wireframes and gave their feedback on the solution.

Initial Pain Point

Users can’t see all facility locations for a client

It’s inefficient to navigate between locations

Too many pages leads to high cognitive load

Users have to remember where to find certain data

No hierarchy to the information

Page load times of up to 5 minutes

Design Improvement

Users have a single view of a client and all their facility locations

Navigating between locations is easier

The client profile has fewer pages with improved names

Like data is grouped together

Data is hierarchical, with most used data near the top of the page

Updating the site to design system fixes performance issues

Client Support Team Quotes

Avatar 85

“It’s so much easier now because I can see everything. I don’t have to waste time navigating between things.”

Avatar 105

“I like that what I need to see is right on top [of the page]. It’ll make it faster to find what I need.”

Avatar 108

“This is going to be great for new employees who need to learn the system. Stuff isn’t so hidden anymore.”

Opportunity Areas

Though the improvement of the information architecture solved some problems, opportunities remain to make Score even more useful.

Remaining pain points

  • Duplicate data and its maintenance problems will continue to exist as long as there’s discrete facility location profiles

  • The UI remains complex with many nested pages

Opportunities to make it better

  • Make it more scalable: try one profile page for a client that displays all data, and allow the user to filter it by facility location

  • Improve the data entry method: instead of going to each facility location and adding the same address, try entering the address once and choosing locations it applies to

Next Steps

Through my work on the information architecture, I was able to take a complex data structure and make it more human-centered. The clarity provided by my diagrams sold the project team on my proposal, and is being used to align the business on the possibilities for further improvement in how client data is collected and maintained.

These efforts are true to the values of service design, as these improvements to internal operations ultimately affect the client experience. I aim to continue to think broadly outside of single products and consider the network of systems that work together to support the user’s journey.

User Feedback
Next Steps
bottom of page