Billing Simplified

Redesigning a regulated billing experience for 10M+ customers across three operating companies and five jurisdictions

A Fortune 200 utility serves more than 10 million residential and institutional customers across three operating companies and five regulated jurisdictions, each with its own rate structures, legal requirements, and disclosure rules.

Over time, the bill had accumulated layers of regulatory content, billing logic, customer messaging, and jurisdiction-specific requirements. The result was a long, information-dense experience that made it difficult for customers to answer three basic questions:

What do I owe? When is it due? Why is this the amount?

The redesign needed to create a clearer, more accessible billing system that could maintain a consistent experience while adapting to different customer conditions, jurisdictions, regulatory requirements, and technical constraints.

50% shorter bills
75–80% easier to understand in customer testing
WCAG AA compliant
~25% reduction in related call-center volume

My Role

I served as Design Lead, leading a team of three designers while remaining hands-on in the work. I owned the design direction, information architecture, and modular system strategy; delegated work across the team; led stakeholder working sessions; drove alignment across four cross-functional teams, stakeholders, and executive leadership; and partnered in sprint planning to keep design, compliance, and implementation moving together.

I worked closely with product, content, legal/regulatory, accessibility, and SAP/OpenText engineering teams to resolve tradeoffs and translate complex requirements into a scalable billing experience. I also established a shared design model the teams could use to evaluate bill scenarios, resolve tradeoffs, and make decisions consistently across jurisdictions.

The Challenge

Simplifying the experience without simplifying the system behind it

The bill needed to support a wide range of conditions.

Some customers had a straightforward single-service bill. Others had multiple services, charges spanning multiple billing periods, third-party suppliers, multiple suppliers, credits, no current charges, or dual billing.

Jurisdictional requirements introduced another layer of complexity. Some sections were required only for specific operating companies or regions, while other modules appeared only when a qualifying billing event was present.

At the same time, much of the underlying system could not change freely. Billing logic, legal terminology, required disclosures, placement rules, accessibility requirements, print output, and SAP/OpenText constraints all shaped what was possible.

The challenge wasn’t redesigning one bill.

It was creating a structure that could flex across many billing scenarios without breaking hierarchy, compliance, accessibility, or readability.

Designing One System for Many Bills

Rather than creating a different bill layout for every possible scenario, I focused on a stable underlying structure with conditional modules layered on top.

The system worked across three levels:

Core bill structure
↓
Scenario modifiers
↓
Jurisdiction + event-driven modules
↓
Generated customer bill

Core Structure

The bill maintained a recognizable hierarchy around recurring information such as:

• Account summary

• Amount due and due date

• Payment information

• Monthly Average Graph

• Charges

• Usage and service details

• Required customer messaging and disclosures

Scenario Modifiers

The structure then expanded or repeated depending on the customer’s billing condition:

• Single service

• Multi-service

• Multi-month

• Multi-service / multi-month

• Third-party supplier

• Multiple third-party suppliers

• Dual billing

• No current charges

• Credit state

Jurisdiction and event-driven modules

Additional content could appear only when specific jurisdictional or billing conditions were met.

For example:

NJ Bill Watch was required for Atlantic City Electric customers in New Jersey and provided a comparison between the current bill and the previous month.

Community Solar was jurisdiction-specific and appeared only when the associated billing event was present.

This meant the final bill was not simply a static template. It was the result of a consistent structure responding to customer state, billing conditions, jurisdictional rules, and triggered events.

What Could Change — and What Couldn’t

A large part of the design work involved separating the parts of the experience we could improve from the parts constrained by the system.

That distinction became central to the redesign.

Instead of trying to remove complexity that the business and regulatory system required, the goal became deciding where that complexity needed to remain visible and where the interface could absorb it for the customer.

Prioritizing the Big Three

One of the most important design decisions was strengthening the hierarchy around the questions customers were trying to answer first:

Amount Due

Due Date

How It’s Calculated

The redesign made those elements easier to locate and understand before introducing supporting detail.

Restructuring the bill around a bento-inspired information hierarchy

Instead of treating the bill as one long linear document, I reorganized the experience into distinct information zones with clear visual priority.

The layout used a bento-inspired information architecture to group related content into modular sections that could expand, repeat, or change based on the customer’s billing scenario.

The highest-priority information—Amount Due, Due Date, and How It’s Calculated—was given the strongest visual emphasis, while supporting content such as usage, supplier details, service information, and regulatory messaging was organized into secondary modules.

This helped customers scan the bill in layers rather than having to read it from top to bottom.

• High-priority summary modules for amount due and due date

• Grouped charge and usage sections

• Clear separation of delivery and third-party supplier charges

• Modular service and supplier details

• Jurisdiction-specific modules inserted without disrupting the overall hierarchy

• Consistent spacing, typography, and labeling across bill variants

Other improvements included:

• Improved usage visualization

• Larger, more accessible typography

• Plain-language messaging where legal requirements allowed it

• More predictable placement of recurring content

  
  

Designing Across Real Billing Scenarios

The redesign was evaluated against increasingly complex billing conditions rather than a single idealized bill.

Billing scenario matrix

Legend:
● standard section
Varies = depends on billing or jurisdictional rules
Repeated / By service / By period = structure expands based on the scenario

The matrix became a way to pressure-test whether the system could handle complexity without losing its underlying hierarchy.

Working Within Technical and Regulatory Constraints

The bill-generation environment introduced constraints that shaped both the visual design and the underlying structure.

Some concepts that worked well in Figma did not translate directly into generated output. Typography had to be recalibrated to maintain accessibility requirements, and some layouts could not be implemented because of SAP/OpenText limitations.

Certain disclosures also had fixed legal placement requirements, while complex rate calculations and underlying billing logic could not simply be rewritten for the redesign.

These constraints pushed the work toward a modular system rather than a collection of highly customized layouts.

Validation

The redesigned bill was evaluated through customer testing, surveys, accessibility reviews, and ongoing stakeholder validation.

Across testing, approximately 75–80% of participants rated the redesigned experience easier to understand.

Accessibility was reviewed throughout the process, including typography, contrast, reading order, and generated document output.

Impact

The final system reduced bill length by approximately 50% while preserving required regulatory and billing content.

The redesign also helped move the broader product direction toward a structure grounded in actual system constraints rather than a single idealized bill.

It gave teams a shared foundation for evaluating future billing requirements rather than solving each jurisdiction or scenario independently.

What I Learned

This project changed the way I thought about simplification.

We could not remove the complexity of the billing system, regulation, jurisdictional rules, or legacy technology.

The design challenge was deciding which complexity customers needed to see, which could be absorbed by the system, and where consistency mattered more than customization.

The result was not simply a shorter bill. It was a more resilient information system designed to make a complicated service easier to understand.