Renata BenitoProduct Design Strategist

Case 04

Ongoing

Billing platform

Billing ecosystem · Client perspective

Designing the system before designing the portal

A phased billing initiative was ready to move into screens. I helped reframe it around the objects, relationships, evidence, and decisions required to build one coherent experience over time.

Laptop showing client billing portal — invoice list with highlighted row and download actions
Role
Product Designer
Focus
Discovery — Product Strategy — OOUX — Codesign
Status
Ongoing initiative
Domain
Billing and account management

01 — The request

The team was ready to visualize each release

The initial request was to conceptually prototype what the billing portal could look like after each epic was released. The exercise was intended to support hands-on collaboration—not define a final product—but the starting point was already heavily influenced by implementation phases and an inherited interface created several years earlier.

“What should the portal look like after each epic?”

A reasonable delivery question—but not yet a complete experience question.

02 — The hidden risk

Implementation phases were starting to define the experience

If each epic became a separate design exercise, the portal could gradually turn into a collection of capabilities rather than a system customers could understand. Navigation, terminology, hierarchy, and relationships would be decided release by release, without a shared model of the complete billing experience.

Epic-led design

  • Screens organized around delivery phases
  • Relationships discovered too late
  • Repeated or competing entry points
  • Short-term decisions accumulating over time
  • A portal that exposes the implementation model

System-led design

  • Releases grounded in a shared domain model
  • Objects and relationships defined early
  • Stable language and navigation
  • Progressive access to a coherent experience
  • A portal that reflects the customer’s mental model

From epics as the experience — to epics as increments of the experience.

03 — The reframe

From designing releases to modeling the billing system

Before exploring layouts, I reframed the initiative around a more foundational question:

What billing system are we progressively building, and how should its objects, relationships, information, and actions evolve across releases?

The epics determine when capabilities become available. They do not have to determine how customers understand the system.

04 — Recovering context

The evidence existed—but it was distributed across time and teams

The initiative did not begin from zero. Previous designers had explored billing concepts before the pandemic, including account information, payment setup, billing history, products, and subscriptions. Historical usability testing also existed, but its findings still needed to be recovered and assessed against the current product context.

Research performed early this year added a sharper, current signal: invoices—now accessed through the reporting space—were very difficult for customers to find. That finding connected legacy explorations to what customers experience in the product today.

Validating findability in the live experience

We are running usability testing to check whether customers can locate invoices in the new structure and what helps redirect attention away from old entry points. In parallel, the team is pairing research with in-product guidance and billing-center changes so orientation keeps pace with phased releases.

  • Usability testing

    Testing invoice findability in the reporting space and learning what navigation, language, and cues restore confidence.

  • In-product guidance (Pendo)

    Introducing the reporting space and steering customers toward invoice-related tasks while habits migrate from earlier patterns.

  • Release announcements in the billing center

    Surfacing what is coming next where customers already manage billing, so new capability does not arrive without context.

  • Editing billing information

    Improving how customers update billing details—with quick links into the connected areas (payment setup, address, and related account context) so changes stay tied to the underlying relationships.

Evidence inventory

Five buckets keep the team honest: confirmed domain rules, historical explorations, early 2026 findability research, assumptions still pending validation, and open questions tied to releases and dependencies. Confirmed and current research anchor the model; assumptions and open items define what codesign and the November track must still prove.

  • Confirmed domain constraints

    Confirmed
    • Billing payments currently rely on bank accounts
    • Payment setup is connected to an address
    • The address also supports physical billing documentation
    • Billing information spans accounts, products, history, payments, and documents

  • Historical evidence

    Historical
    • Previous billing portal concepts
    • Earlier usability testing
    • Product and subscription explorations
    • Billing history and product-detail patterns

  • Early 2026 findability research

    Confirmed
    • Invoices in the reporting space were difficult for customers to find
    • The problem is orientation and migration—not only a missing screen

  • Current assumptions

    Assumption — not fact
    • Historical findings may still reflect important customer needs
    • Customers require a unified view across billing objects
    • Release-by-release concepts need a shared information architecture
    • Progressive delivery should not create fragmented navigation

  • Open questions

    Open
    • Which historical findings remain valid?
    • Which objects and actions belong in each release?
    • How do customers understand products, charges, invoices, and payments?
    • What information must remain accessible across releases?
    • Which dependencies constrain the future-state experience?

05 — Modeling the domain

Defining what the portal is actually made of

I began organizing the initiative around the objects customers manage—not around pages or epics. This exposed the relationships that navigation and interface concepts would eventually need to preserve.

Initial object map

Objects customers manage

  • The customer’s top-level billing context—what they subscribe to and what they owe.

    Core content

    • Account name and identifier
    • Active products or subscriptions
    • Open and recent invoices

    Metadata

    • Account status
    • Primary billing contact
    • Preferred currency or region

    Relationships

    • Contains products or subscriptions
    • Has invoices

    Actions

    • View account
    • Navigate to related payment setup
Initial domain model — subject to validation as research and technical dependencies are confirmed.

06 — Designing across releases

One experience, progressively revealed

Instead of treating every epic as a new destination, the experience vision can show how the same system becomes more capable over time. Each release introduces or expands objects, information, and actions while preserving a coherent foundation.

Release planning matrix

  • Available now
  • Introduced in this phase
  • Future capability
  • Requires validation

Select a phase · use arrow keys to move between tabs

Foundation

Requires validation
Objects introduced
To be mapped with the product and engineering teams.
Information available
To be mapped with the product and engineering teams.
Actions enabled
To be mapped with the product and engineering teams.
Cross-object relationships
To be mapped with the product and engineering teams.
Questions to validate
To be mapped with the product and engineering teams.
The matrix is a planning artifact, not a commitment to a final release sequence.

07 — Codesign with structure

Creating guardrails for collaborative exploration

The goal is not to delay ideation. It is to give the team enough shared structure to explore meaningfully. The object model, evidence inventory, and release matrix create a common language for codesign sessions and help the team identify when a screen-level decision depends on a larger product question.

  1. 01

    Align

    Review evidence, constraints, and open questions

  2. 02

    Model

    Agree on objects, relationships, and actions

  3. 03

    Explore

    Prototype how the experience grows across releases

Structure makes collaborative exploration faster because the team can see which decisions are local—and which affect the entire portal.

08 — Current output

What this work is enabling now

Design and decision-making outcomes — not shipped business results

  • A shared view of the billing domain

  • Clear separation between evidence and assumptions

  • Earlier visibility into cross-epic dependencies

  • A foundation for evaluating inherited designs

  • More focused codesign conversations

  • A way to prototype releases without losing the future-state experience

09 — What comes next

November release, buffer time, and validation in flight

The next major billing release remains planned for November 2026. The schedule intentionally keeps buffer before and after launch so new capabilities can be introduced without skipping orientation work—findability, in-product guidance, and cross-area connections.

  • Deliver the November 2026 release as scoped, using buffer time to land incremental capabilities without fragmenting the billing-center experience
  • Connect the platform to help ticket submission via Salesforce so customers can escalate from billing tasks into support with context preserved
  • Run usability testing to address findability gaps (especially invoices in the reporting space) and to test Pendo content, placement, and format before scaling guidance
  • Continue mapping confirmed objects and actions to delivery phases and billing-center announcements
  • Validate the object model with domain experts and document deltas as epics converge on the shared map
  • Use scenario-based codesign for net-new surfaces while the release train and research run in parallel

Evidence to collect

Release, integration, and research signals tracked against the shared domain model.

  • November 2026 release

    On track as planned, with schedule buffer to introduce capabilities and stabilize navigation after launch.

    Planned

  • Help ticket path (Salesforce)

    Connection from the billing platform into help ticket submission so support receives billing context.

    Planned

  • Findability UT + Pendo validation

    Usability testing to clear findability issues; evaluate Pendo messaging, format, and whether customers reach invoices in the reporting space.

    In progress

  • Epic-to-object mapping

    How confirmed objects, quick links, and announcements land across release phases.

    In progress

  • Object model validation

    Which objects and relationships domain experts confirm before the November scope locks.

    Open

Reflection

Designing before the screens does not mean designing more slowly

The most important contribution at this stage was not a new interface. It was preventing the delivery plan from silently becoming the information architecture.

By making the domain visible first, the team can explore individual releases while still designing toward one understandable billing experience.

“The epics determine when capabilities become available. They should not determine how customers understand the system.”