Lumina
statement
Banks turn one-line product requests into dozens of hidden pricing decisions, and copying old pricing quietly drags in fees that don’t fit.
I designed Lumina, a workbench where an AI assistant reads the request, suggests what to reuse and why, and proposes what’s missing. The manager stays in charge.
What made it work: start from the request, give every suggestion a reason, make broken selections impossible, and label where everything came from.
details
- 01RoleUX designer, owned Pricing end to end
- 02Duration1.5 years, ongoing
- 03Scope0→1 · manual → AI-assisted → agentic
- 04StatusWorking prototype, not launched
- 05PlatformEnterprise web
- 06NDANames changed, every screen redrawn with fictional data
gallery
four screens, redrawndrag →
part 1
The context
A one-line request hides dozens of pricing decisions
Create pricing for a student checking account. Waive the monthly fee for verified students aged 18–25, support digital and ATM, and charge $3 for out-of-network ATM withdrawals.
what the manager has to answer
- can an old model be reused?
- which fee schedules belong?
- will copying sneak in branch fees?
- where does the waiver sit?
- which rule checks eligibility?
- is the verification data even there?
Pricing logic is layered five deep, and finding the right piece depends on memory.
Copying a model quietly brings along fees and rules that don’t fit.
Every request is rebuilt by hand before it can even go for approval.
The question wasn’t how to fix a tool, but what it should be with AI
This wasn’t a redesign. It started from a blank page.
Built for the pricing manager, and the people around them: product managers, pricing specialists, approvers, and the data and rule owners. The plan ran in three stages: get the manual flow right, then add AI assistance (where the prototype is now), then explore agentic flows.
half one
ProductWhat the bank offers: products, bundles, features, eligibility.
half two
PricingWhat each offer costs or earns. I owned it, end to end.
The complexity didn’t need hiding. It needed to be understandable
Banking pricing is invisible to most people, designers included. So I learned it from three angles.
What surprised you most in those first walkthroughs? One or two lines, the way you’d say it to a friend.
- Walkthroughs with product owners
- How fees, interest and waivers are calculated, and how one small change ripples through linked rules.
- Existing pricing tools
- Strong at configuration, weak at showing what a change means while you make it.
- The entity diagrams
- Worked through with product and engineering, so the design matched how the system really behaves.
fig.
One five-level hierarchy became the backbone of everything
Before any AI, the structure itself had to be readable. The libraries, the navigation and the assistant all follow it.
two kinds of model
A Base Price Model answers what a product or bundle costs or earns.
A Relationship Pricing Model answers what a customer’s wider relationship with the bank earns, like a mortgage discount for qualifying deposits.
fig.
the pricing hierarchytap a level to fold what’s beneath it
A $0 fee hides the rule. Keeping the standard fee and the waiver separate shows reviewers what’s standard, what’s the exception, and who qualifies.
The moment this principle clicked for you, or the conversation where you had to defend it.
part 2
The decisions
Checking plus savings for students and gig workers, live Dec 1 to Jan 31, on digital and branch. Keep savings interest, add a festive bonus, simplify servicing. Follow it through all four decisions.
When AI explains its match, managers can judge instead of trust
The manager opens the request and Lumina Assist already has the context. It suggests where to start, and says why.
why
Nobody re-types what’s already in the request. The bundle, audience, channels and dates arrive with it.
Two models can share a name and differ in exactly the behavior that matters. A score would ask for blind trust; a reason lets the manager judge.
fig.
request + ranked matchespick a match
Christmas Flex Banking Bundle
Reviewing schedule by schedule caught a double charge before customers did
So instead of all or nothing, the manager reviews the source in a drawer that mirrors the hierarchy.
Copy the whole model, and every customer pays the maintenance fee twice.
fig.
the review drawerclear a schedule: its children follow
one row per schedule
Checkbox, AI badge, reason and count sit together in the header.
depth you can see
Indentation shows depth, and reasons line up in one column for scanning.
selection follows dependencies
Clear a parent and its children clear too. Broken selections can’t be built.
before / after
Being in a bundle isn’t the same as copying its pricing. Separating those two ideas was the clearest win of the whole design.
Which round of feedback changed the drawer most, and what did someone say?
AI earns trust with specific edits, not vague advice
A close match isn’t a finished one. So instead of “this model needs adjustment”, every proposal spells out the change.
every proposal names
- 01Operationadd, update or remove
- 02Recordshown inside its parent, so you see where it lands
- 03Reasonwhy this change, for this request
- 04Detailsthe exact values proposed
fig.
a proposed change, landing in the draftapply or skip
help inside the record
In a schedule, the manager can ask for relevant definitions: the assistant recommends what fits, explains what doesn’t, and flags missing data. A nested drawer keeps the draft in view.
Every item shows its origin, because copied doesn’t mean approved
In banking, a wrong price means wrong charges to real customers. So nothing in a draft is anonymous.
three checks, never merged
- 01ProvenanceWhere did it come from?
- 02ValidationIs it complete and consistent?
- 03ApprovalIs the business authorized to use it?
fig.
a labeled draftfilter by origin
Missing data stays visible instead of being assumed: no verification data means unresolved, never “probably fine”.
Saving a draft is never the same as submitting it. The AI recommends; the manager decides.
part 3
The outcome
Today’s guardrails are what will make an agent safe
Next is relationship pricing: rewarding a whole customer, not one product. I designed the flow beyond the current prototype.
after that, agentic
Hand over the whole request, and the agent drafts and stops at checkpoints for review. Hierarchy-aware selection, reasoned proposals and origin labels are what make that safe.
flow
- Choose the contextcustomer, household or segment
- Give products rolesdeposits qualify, the mortgage gets the discount
- Score and tierPlatinum, Gold, or a direct benefit
- Resolve conflictspriority, best benefit, stacking, caps
- Apply guardrailsnever break the minimum profit margin
fig.
People still decide. They just start from an explained draft
Pricing managers start from the request instead of a blank form, and reuse pricing without inheriting fees that don’t fit. Approvers see what was cloned, generated, edited or left unresolved, so they review decisions instead of rebuilding them.
Customers are protected from mistakes like double charges, and the bank gets new products and seasonal offers to approval-ready pricing faster, with every configuration traceable for compliance.
one review of the Christmas bundle
Five source schedules in, four kept, one stopped with the risk explained, then two missing pieces proposed.
compare
same work. who does the digging?
- {{c.stage}}
{{c.text}}
you
- {{c.stage}}
{{c.text}}
{{c.who}}
how we’ll know it’s working
Time to an approval-ready draft, how often AI proposals are accepted or rejected, how many configurations need correcting, and how often missing dependencies are caught before approval.
next step
Formal usability testing and timed comparisons.
Four things I’d carry into any AI product
Show the reasoning. A score asks for trust; a reason gives people something to judge.
Enterprise UX is rarely a UI problem. The hard part was making the structure make sense.
Constraints can be kind. Make the wrong choice impossible, instead of warning about it later.
Where a value came from is part of what it means.
— M.
