Score
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.
Role and Organization
Lead UX Designer at Pitney Bowes
​
Timeline
January 2022 - April 2022
Team
Product management, engineering
​
Tools
Figma, FigJam
​
Background
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
Strategy
Changing the information architecture was key to improving the usability of Score. My strategy consisted of four phases:
1. DISCOVER
Understand the current solution
2. DEFINE
Identify user pain points
3. DESIGN
Propose a solution
4. DISCOVER
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.
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:
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.
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:
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
“It’s hard to jump around and see all the data [for a client].”
"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."
“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.”
“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.”
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.
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:
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
“It’s so much easier now because I can see everything. I don’t have to waste time navigating between things.”
“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.”
“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.