(2026)
B2B SaaS · WebWhen billing is more than money
I designed a billing module from scratch inside a modular admin platform — where every setting had downstream consequences for features, access, and user trust.
My focus: Designing for system transparency — making sure every billing configuration communicated its consequences clearly, so admins could make decisions with confidence rather than anxiety.
Timeline
(2026)
Role
Sole UI/UX Designer
Team
1x CEO
1x Senior Developer
Overview & Research
Overview
The Billing Module is a configuration-heavy admin tool within a modular B2B platform. It allows platform administrators to set up pricing plans, manage subscriptions, configure feature access by tier, and handle payment workflows for end clients.
Unlike consumer billing, every setting in this module had operational consequences — changing a plan could restrict features for active users, trigger payment failures, or alter access permissions across the platform.
4
Admin user types mapped
12+
Interconnected configuration settings
1
Sole designer on the project
What I found in the field
Invisible consequences
Admins had no way of knowing what downstream effects a billing change would trigger. A plan update could silently restrict features for active users — with no warning in the interface.
Configuration anxiety
Admins avoided making changes unless absolutely necessary — not because the task was hard, but because they weren't confident about what would break.
No system feedback
After making a change, admins had no confirmation of what had actually updated, what had been affected, or whether the configuration was valid. The system gave no feedback.
"I'm never sure if changing this will break something else. So I just leave it."
— Platform Admin, discovery interview
Constraints
Why this was so hard
This was not a form design problem. Several constraints made the challenge inherently complex.
High stakes configurations
Every billing setting had real operational consequences — incorrect configurations could restrict access, trigger failed payments, or break features for active clients.
Deeply interconnected system
Billing settings were entangled with feature flags, user roles, and access permissions. A change in one place cascaded unpredictably through the rest of the platform.
Non-technical admins
Billing changes could have immediate financial consequences for clients and users. The design had to minimize the risk of errors and build confidence in making necessary updates.
No existing patterns
There were no internal design patterns for this module. Every component — plan configurator, tier manager, payment workflow — had to be designed from scratch.
Design Decisions
How I decided what to build — and why.
Every decision was made against one question: does this help the admin act with confidence — or add to their anxiety?
01. Decision
Made downstream consequences visible before changes were made
Why
Admins were paralysed by uncertainty — not by complexity. Showing the impact of a configuration change before it was confirmed gave admins the information they needed to act decisively rather than avoid the system.
Observed during design walkthroughs — admins who previously avoided configuration tasks completed them confidently once consequence previews were introduced
02. Decision
Separated configuration from activation
Why
Admins needed to set up billing plans without immediately pushing them live. A clear draft → review → activate flow gave admins control over when changes took effect — removing the fear of accidental activation.
Validated through admin walkthroughs — separating draft and live states removed the fear of accidental activation
03. Decision
Designed confirmation and feedback into every action
Why
The previous system gave no feedback after changes were made. Every configuration action now surfaces a clear confirmation — what changed, what was affected, and what the admin should check next. The system closes the loop.
Consistent feedback from walkthroughs — admins described the confirmation system as something the old system never had
Outcome & Reflection
What changed — and what it taught me.
Three decisions. One question: does this help the admin act with confidence?
Reduced configuration anxiety
Admins who previously avoided billing configurations engaged with the module confidently — completing tasks they had previously escalated to developers.
Fewer unintended changes
Consequence previews and draft states gave admins the control and visibility needed to make deliberate, informed configuration decisions.
Closed the feedback loop
Every action now surfaces a clear confirmation — what changed, what was affected, what to check next. The system finally communicates back.
Reflection
This project was the clearest example in my career of how trust is built — or broken — through interface design. The admins weren't struggling with the task. They were struggling with uncertainty. Designing systems that communicate their own behaviour — that tell users what will happen, what did happen, and what to do next — is what I mean when I talk about accountability in digital systems. It is also what draws me toward studying human-computer interaction at a deeper level.