Scaling pricing to charge for diverse requirements

Airspace is a time-critical logistics company that specializes in shipping goods across various industries like aerospace and hospital/health systems.

For each order, customers are provided an instant quote based on parameters like the package weight. This quote is based on pre-agreed rates, which are configured on each customer's account by Airspace's finance team.

Another product designer and I had conducted the following activities to gain more context on what "European pricing" meant:

To think long term, we concluded the system had to handle more than European rates, since expansion beyond Europe was already planned.

Requests to add new rates to upfront quotes outpaced R&D's capacity to build them, and the gap landed on people and customers.

This created several ripple effects:

These inefficiencies ultimately hindered our revenue growth and profit margin.

With another designer and our UX strategist, I co-led synthesizing research across finance, operations, and customer-facing teams into one picture of how a new service reaches market. Seeing the whole loop turned this from a pricing project into part of a broader product strategy for launching new services.

Sessions brought together operations, finance, customer success, design, and product. I owned the finance concepts, with the theme of "scale" and "self-service" at the core our brainstorming with others. We wanted to build a system that could minimize R&D involvement with addressing new requirements and their pricing in the long term.

For the bulk of this case study, I will focus on two areas that I owned:

Using paper cutouts for each concept, input, and action, participants worked through the "system" while we simulated its responses.

Participants understood the core concepts. The one notable change: we renamed constraints (the rules that decide when a charge applies) to conditions. The concepts were then split into separate projects across product teams.

From aligning with my product team, we determined that the various service and charge configurations would still require significant development. Additionally, other product teams that would develop the other features were not yet ready to start designing and developing.

Instead, we decided to model one service to use to build the new features. Over time, we could iterate and expand by adding in more configuration options and retrofitting existing rates, providing us with a clear, future roadmap.

Through support tickets, documentation, 3 interviews, and 2 shadowing sessions, I discovered that the finance team reactively zeroed out dangerous goods rates only after customer complaints. While the system charged solely based on a "Yes" banner response during order entry, the business desired to also apply the corresponding charge based on the specific type of shipped item (such as an aircraft part or tire).

Since the logic to charge was straightforward to be widely applicable and was independent of other features, I pitched to use dangerous goods to model for launching the new pricing system.

Service "types," for example, had no clear user or business value, so we cut them. Features we couldn't validate were shelved for later iterations.

Reviewing the flows with my team, the design strategist, and our design manager, I realized:

I then re-prioritized what features would be built, shelving the ambiguous ones as opportunities for future iterations.

After narrowing down two concepts to test from four different variations (two were dropped due to technical constraints and usability concerns), I observed any user misclicks and discussed their preference to get a direction of which UI to implement.

Testing results indicated a stronger preference for the second variation, as users indicated they preferred being able to access all the editable properties at once.

Testers preferred seeing every charge property at once, but conditions would eventually be long text the accordion couldn't hold. After another round of ideation with the design team, I moved the create/edit form into a side panel.

Internal users could create services to define customer or business needs. Services could also be used in other system concepts:

The finance team could add services onto rate sheets, which also segmented any unique services and its pricing to a given customer's rate sheet.

Charges could be configured for a service. How it was charged was defined by the charge type chosen to mirror how Airspace applied different charges (as a flat amount or per piece weight).

Conditions would encompass a variety of order data over time, so that the finance team could be exact in how to charge for a service. In addition, surfacing this logic in the UI would remove any confusion around the logic for a charge, which was a common user challenge I had found early on through interviewing users.

As a result, additional iterations on Services and Rate Sheets were eventually deprioritized.

While proactively raising risks and running alignment exercises created the impression of a shared vision across teams, the true challenge emerged during the actual build phase. New constraints and shifting priorities later altered how we could execute that vision. In hindsight, rather than assuming early buy-in would hold through implementation, I would design the initial system to better accommodate a partial rollout from the start.

The adoption gaps directly shaped a follow-up project to simplify the system. The complexity that slowed adoption here, particularly around conditions and interdependent rollout, were factored into a later initiative (you can read about that project here).