Case study · Strategy
From shipping features to shipping a system.
An intent-based interaction model: people say what they want in their own words, and the experience adapts to who they are and what they're doing. Approved as the design principle for a commercial banking platform.
Check it, then continue. Nothing is applied yet.
One thing to sort out. Payroll Reserve can't send yet. Fix it on the next screen.
Check this over. You can change anything.
Where each part came from. Everything stays editable.
Same step, three modes. Example data is fictional.
After the company was acquired by another fintech, two platforms ran on separate cores, and the gaps between them were everywhere. The roadmap turned into a list of gaps to close. A competitor shipped something, a client asked for something, and the answer was another feature with its own rules for how much to guide people, when to confirm and what to do when something went wrong. Clients met a different product on every screen.
Meanwhile, leadership had set an aggressive five-year goal to grow revenue and EBITDA. Closing gaps could keep clients from leaving, but it was never going to be the kind of innovation that grows a business. So I stepped back and assessed where the product needed to go.
The signs showed up everywhere: people typed into search far more than they used filters, frustration clustered on finding a transaction, and one of the most-visited admin screens was one sales avoided demoing. Each of those could have become its own fix.
Underneath it all, the product spoke the bank's language, not the client's. To block a type of ACH payment, a business had to know the right SEC code, like WEB, TEL or RCK, and find it in a list. People don't think in codes. They think in tasks: "stop payments that come in over the phone."
AI made the problem bigger. Without a shared model, every team would bolt AI on its own way, and the gap-closing would never end.
The question I brought to leadership wasn't "What should we build next?" It was "What product model will get us to the business we're trying to become?"
What the research showed
Six sources pointed the same way: one experience couldn't serve everyone, and banking jargon was getting in the way.
SME interviews
Interviews with subject-matter experts showed retail and commercial users need different things. A consumer payment-hub initiative hadn't accounted for high-volume, experienced users doing bulk actions, and it didn't scale. Someone sending a quick transfer doesn't need the same steps as a business sending a complex international wire before the cutoff. That's where the adaptive modes came from.
User testing
People spent more time hunting for codes in small, hard-to-find filters with long lists than they did typing what they needed into a single entry.
Product analytics
The ACH search box was used more than all three ACH filters combined, and it drew more rage clicks too. Transaction search drew rage clicks at roughly 6 to 12 times the rate of other search features.
Sales losses
In lost deals, client-driven requests were a repeated source of frustration, and the specific requests were for customization.
Competitive review
Competitors offered separation of roles and account limits for each payment rail. That shaped the Sub-User Admin design.
Market trend
versus 70% across all ages, in a 2025 survey of 2,000 banking customers. It's a consumer study, but it shows where expectations are heading, and the people running business accounts are consumers too.
Source: Personetics, "Understanding Consumer Demand in the AI-Banking Era," 2025 (a personalization vendor; consumer survey).Internal research and analytics are summarized and generalized for confidentiality.
Instead of patching gaps one feature at a time, build one adaptive experience that works across the whole platform: quick for experts, guided for newcomers, in plain language instead of banking codes. Every new feature plugs into the same system, so the company builds something it can sell, not just something to catch up.
I didn't pitch North Star as a nicer screen. I tied it, and Sub-User Admin as its first big application, to the three priorities company leadership had set out, and showed what it would do for each one.
Company priority
Banks were asking for more control and configurable access, and each request became a custom change for one client. One configurable model replaces client-by-client changes.
Company priority
Commercial clients need to separate who creates a payment from who approves it. Competitors offered finer controls, and missing per-account payment limits had come up in lost deals.
Company priority
Rules first, with a person approving every change. Typed AI requests come later, and only once the company has settled how AI may use customer data.
I mapped three revenue levers: winning and keeping commercial deals, closing part of the new-client gap with a faster-growing competitor, and cutting the cost of one-off client requests. I labeled each one as an argument, not a measured result, and named what finance, sales and professional services still needed to confirm before anyone should rely on the numbers.
People act on the task, and the product does the translating. North Star rests on two ideas:
The design shift · adaptive workflows
Complete familiar work with the fewest possible interactions.
Progressive guidance for high-risk or unfamiliar tasks.
Understand, track or resolve what happened.
Three guardrails
The same pattern that replaces a code list works for a search bar, a report, a permission change or a fraud decision. Under the hood, every moment runs in one of three modes, and five checks decide which one fits this person and this task. It runs on rules today, and AI can make the same calls later without anyone redesigning what clients see.
Same intent-first pattern, same three modes. The stakes rise from left to right, and the pattern holds.
It starts small, with one jargon-heavy list in a feature being built today, and scales to some of the hardest screens on the platform.
Before · Speak the bank's language
You have to know that "TEL" means payments authorized over the phone.
After · Say what you mean
The code is still there. People just don't need to know it.
Example · finding a payment, today
Filtering means building the query by hand, one menu at a time.
Task 1 · table search · illustrative
The bar doesn't change. One line of interpretation beneath it does.
Results apply on Enter. Tap a chip to adjust.
Applies what it understood and asks one question. Never a blank screen.
Explains what happened and offers a way forward.
Same pattern, two very different jobs · proposed designs
Example data is fictional.
Business admins set up their team's access one person at a time, with no reusable roles, no per-account payment limits and no way to check permissions before saving. Sales avoided demoing it, and the missing per-account limits had come up in competitive deals.
The work started as an assigned visual refresh. I added Bulk Apply, which nobody had asked for, then plain-language input, and then rebuilt the whole flow on North Star principles with a staged plan the business could fund one step at a time.
Task 2 · Sub-User Admin: the setup
That's Sub-User Admin: how a business gives its team access to accounts and payments.
What the product calls it
Organized by banking service.
What the person is trying to do
Organized by the job.
Same task. North Star asks in the person's terms, not the product's.
Used by thousands of business users every quarter (product analytics, generalized).
Sub-User Admin · now
Sub-User Admin · walk
Sub-User Admin · run (North Star)
On Payroll Operating, Freya can view activity and see incoming money. No payment access.
On Payroll Reserve, Freya can view activity and send payments. Payments over $25,000 need a second approver.
On Payroll Tax, Freya can view activity.
Same flow in Speed, Guided and Investigation. The mode decides how much of each step you see.
Proposed designs. Example data is fictional.
Winning over leadership and product was as big a job as winning over engineering. Each group needed a different reason to say yes, so I built a different case for each one.
Engineering pushed back on the AI piece, and the concern was fair. Banking data is sensitive, and a model guessing at intent is a hard thing to put in front of a business that's moving money. I didn't treat that as an obstacle to argue past. I changed the plan so the first version earned trust on its own.
How it's built
Rules-based or AI, the person sees the same readback. So the design doesn't change if the engine does.
Rules-based keeps everything inside the company's systems, and every phrase can be tested.
The engine · swappable
The readback · identical either way
The modes · same rules either way
Decision 1
The first version runs on rules, using data the platform already has. No data leaves the company. AI can be added later behind the same experience.
Decision 2
Everything is built from the current design system, so there are no new components to maintain and the change is cheap to adopt.
Decision 3
I wrote technical specs for the engineers. Each page lists its checks in order and stops at the first match, so behavior is predictable and easy to test.
Decision 4
Positive Pay became the pilot, so the model would be judged on a real release, not a deck.
Those four decisions answered engineering. For leadership and product, I named the risks up front and made a clear ask.
I closed with an invitation to the other product teams in the room: the three modes are meant to be reused anywhere people and permissions show up.
Proposed phasing · dates follow engineering sizing
Status: slotted for Q4 2027 after my pitch, with engineering sizing milestone one in Q1 2027. Roadmap space had been lost after the company was acquired, so getting it back in line took a business case, not just a design.
How success would be measured (a plan, not results): time to complete setup, wrong permission grants, the catch rate when a mistake is planted in a setup, and support contacts.
I learned not to wait to be handed a project. I looked for the gaps and brought the idea to the table myself. I also learned that one idea needs more than one pitch: what I showed product leadership was different from what I showed engineering, because each needed a different reason to say yes.