Case Study · 2023
Establishing Scalable Architecture for Platform-Wide transactions
I established a hybrid payment IA that balanced user mental models with technical constraints, setting foundational principles that enabled incremental rollout and supported diverse user needs as the platform scaled.
Role
Product Designer
Company
Thrivent
Timeline
[Timeline]
Tools
Figma
01 — Overview
A payments experience built to scale
Paying a bill or premium is one of the most frequently performed actions in Thrivent's authenticated client experience. At the time, only one-time payments were supported — but we were approaching a pivotal transition: introducing automatic payments, group bills, and investment transactions like buying and selling.
We needed a scalable model for continuously adding transaction capabilities — one that would grow coherently rather than accumulate as a collection of disjointed features.
02 — Problem
One architectural question that couldn't wait
As Thrivent decommissioned its legacy console, payments became a critical architectural decision. With multiple product types — insurance, investments, banking — each backed by different systems, one foundational question had to be answered before the platform scaled further:
Should payments be centralized, decentralized, or something in between?
Getting this wrong carried real consequences: users unable to find payment actions as the platform grew, inconsistent patterns across products, and missed payments leading to grace periods or policy lapses. The challenge wasn't just designing screens — it was establishing the IA principles that would govern how transaction capabilities got added over time.
03 — Process
Mapping the landscape before building anything
I audited 12 platforms — 7 direct competitors (Fidelity, Vanguard, Principal) and 5 adjacent financial services — to understand how successful products organized payments. Key patterns emerged:
- —No single “correct” model; approaches varied based on product mix
- —Most bill payments occurred at the individual contract level
- —Investment actions (buy/sell/exchange) were consistently separated from bill payments
- —Batch/multi-payment functionality was rare across the competitive set
From there, I mapped three structural models and evaluated each against technical feasibility, user mental models, and long-term scalability:
- 1.“Move Money” center — a centralized hub for both payments and investment actions. Single destination for all money movement, but high backend complexity and mixed mental models (paying a bill is fundamentally different from buying a fund).
- 2.Fully decentralized — payments and investment actions only accessible within individual contract pages. Lower engineering lift and contextually relevant, but poor discoverability and difficult to scale.
- 3.Hybrid model — a centralized payment center for bills and history, with investment actions remaining product-specific. Payments also accessible contextually on contract pages. Separates distinct mental models, supports different user preferences, and allows incremental rollout as backends become ready.
Stakeholders gravitated toward the hybrid model or the “Move Money” concept — setting up a research phase to validate which better matched user expectations.
Validating with research
I partnered with a researcher and content designer to test terminology and IA preferences with 100 participants matched to our client demographics — users with experience across insurance and investment products.
When asked what they'd expect to find on a page titled “Payment Center”:
- —99% expected payment actions
- —68% expected payment history
- —4% expected investment actions — strongly validating the separation
The results confirmed the hybrid model. The centralized page launched as “Billing and Payments” — a name chosen after business partners confirmed they wanted “bills” explicitly represented in the label.
04 — Outcome
Results
At launch:
- —9,000 additional digital transactions in the first month compared to the previous period
- —Shipped bill payments, one-time mutual fund transactions, payment history, bank account management, and autopay as part of the initial release
- —Site navigation built around the hybrid IA, establishing consistent patterns across all financial products
Longer term:
- —The architecture enabled subsequent features — annuity transactions, beneficiary updates, group bills — to be built consistently on top of established patterns
- —The product owner described the work as “a significant milestone for our team and for our clients' self-service empowerment”
“I am very happy after my previous attempts did not work this easily.”
“This is much better than in December. Thank you for updating the payment site.”