Ansel (formerly Brella)
B2B payments · Fintech · Multi-brand design system · Web and iOS
Ansel (formerly Brella)
B2B payments · Fintech · Multi-brand design system · Web and iOS
COMPANY
Ansel (formerly Brella)
Role
Senior Product Designer
COMPANY
Ansel (formerly Brella)
Role
Senior Product Designer
COMPANY
Ansel (formerly Brella)
Role
Senior Product Designer
Discovery & problem
Context
Ansel offers supplemental health insurance that pays members directly when they're diagnosed with a covered condition. Employers offer it as a benefit, and members manage coverage and claims on the web and on iOS. I joined when the company was still called Brella; it later rebranded as Ansel, so the screens here show the Brella brand as it was when I designed them.
As Senior Product Designer I worked across both sides of the platform: the employer billing and payments portal, which this case focuses on, and the member claims experience. Insurance carriers Symetra and Nationwide also offered the product to their customers through partnerships, co-branded with Brella, so everything I designed had to work for three brands.
Discovery
Employers received their monthly invoice as an email with a PDF, and many paid by mailed check. To understand where that broke down, we ran interviews with employer admins, reviewed billing-related Concierge tickets, and walked through the invoice email and PDF process with admins and the Billing Ops team.
Two users, one invoice
The HR or benefits admin runs benefits for a small or mid-size company alongside many other duties. Their goal is to confirm the invoice matches who is actually enrolled, then get it paid or routed to Finance.
The finance or AP specialist pays dozens of vendors, and Ansel is one line in that process. They care about due dates, invoice numbers, the right payment method and a clean record for reconciliation.
Key insight: the person who understands the invoice is often not the person who pays it. The portal had to serve both, and make the handoff between them clean.
Pain points
No visibility. Admins only learned about an invoice when an email arrived. There was no preview, no status and no clear signal of "am I late?".
Unexplained changes. New hires, terminations and partial months changed the total every month, and admins called Concierge to ask why.
Paper checks. Slow, hard to match to invoices, and a key driver of past-due accounts and manual follow-up for Billing Ops.
No self-service setup. There was no way to add or verify a bank account, and no way for an AP colleague to do it without sharing a login.
Ideation and definition
We framed the problem as: how might we make every invoice self-explanatory, and every payment a two-click action, for whoever at the company is responsible for it?
Billing rules (prorations, adjustments, payment statuses) lived in the backend and in Billing Ops' heads, so before drawing screens I mapped every combination of invoice status with the PM and Billing Ops. Each scenario defines what the three overview modules show, which gave design, engineering and QA one source of truth and settled most "what shows here?" debates before they started.
A few rules came out of it: Make a payment only exists when a final invoice exists, every payment goes through a confirmation step, e-payment setup is always available even before the first bill, and the preview only appears when the backend has one. We also decided early to support two bank-linking paths from day one: instant linking through Plaid, and micro-deposits as the fallback.
Design, build & impact
Design and development
An overview for every billing state
The account overview adapts to where the employer is in the billing cycle, so the next action is always obvious: from a preview of upcoming charges, to an invoice that's ready to pay, to a calm steady state, to a persistent past-due banner.
Invoices that explain themselves
Invoice details break the total down to each employee. Partial-month coverage is flagged and explained, credits and corrections are listed separately with a memo, and "Reach out to Concierge" sits right where questions come up. Admins can reconcile on their own instead of calling.
Making ACH the easy default
Payment settings offer a path for every situation: instant bank linking with Plaid, micro-deposit verification for banks Plaid can't reach, and a clear default method.
To solve the "admin isn't the payer" problem, the admin can send a secure link so someone in Finance adds the bank account themselves, without sharing credentials.
Designing for what goes wrong
Money flows need guardrails. Every destructive or failing state was designed explicitly and reviewed with Billing Ops: the default method can't be removed while others exist, removing the last e-payment method warns that future payments will need a check, and a failed payment explains what happened while the invoice stays payable.
One product, three brands
Symetra and Nationwide offered Brella to their customers through partnerships. Instead of designing separate products, the same components were themed with each partner's logo, colors and carrier copy, co-branded with Brella. One system shipped three branded employer portals, and their billing emails.
The member side: claims on web and iOS
On the member side, I redesigned how people submit and track claims, one of the most critical and high-friction moments of the experience. Users didn't want to manage insurance; they wanted a fast, clear way to finish a task with confidence. The result was a three-step flow (what happened, upload, review and submit) with document guidance, a real-time tracking dashboard, and a choice of how to get paid.
Desktop and mobile. The complete journey lives side by side in Figma, from an empty claims list to tracking, including the in-between moments that usually get skipped, like guidance, processing and confirmation.
AI that checks documents as you upload
The biggest delay in claims wasn’t submitting, it was the back-and-forth afterwards: a missing diagnosis code or an unsigned page meant a request for more information and days of waiting. With this flow, AI reads each document the moment it’s uploaded, compares it with what the claims team needs, and tells the member exactly what’s missing and where to find it, before they submit. This flow was designed as part of the roadmap for future integrations, the next step for the claims experience.
Design system. The claims work sits on four linked libraries (Foundations, Patterns, Screens and Claims), with the claim card designed in every lifecycle state.
Implementation and handoff
States mapped 1:1 to the backend. Every UI state corresponds to an invoice or payment status, so engineering and QA tested against the same matrix.
Short loops with the whole team. Flows, wireframes and high fidelity in weekly syncs with the PM, Engineering and Billing Ops, plus async Figma reviews for copy and edge cases.
Ship with fallbacks. Implementation notes and copy fallbacks lived on the canvas, like a simpler toast if the custom success toast couldn't ship yet, which kept the release unblocked.
I owned the copy for banners, toasts and destructive confirmations, and partnered with engineering through build and QA.
AI in my process today
This work was done in 2021 and 2022, before today's AI tools. To present it, I rebuilt the billing journey as the interactive walkthrough at the top of this page with Claude Code, working from the original Figma files. It's how I prototype now: in code, with real interactions and states, in hours instead of days.
Impact
60%+ of claims were submitted through the mobile experience.
One system, three brands. The same billing portal and emails shipped for Brella, Symetra and Nationwide.
From email and paper checks to self-service. Employers can see what they owe and why, and pay by ACH in two clicks.
Billing targets set with Product: ACH share of invoices paid, fewer accounts reaching past due, fewer "why did my invoice change?" contacts, and payment-setup completion. Results: [add].
What I learned
Design the handoff, not just the screen. The admin and the payer are often different people.
A state model first, screens second. The scenario matrix prevented most debates later.
Guardrails are content design. The copy in destructive modals did most of the work.
Discovery & problem
Context
Ansel offers supplemental health insurance that pays members directly when they're diagnosed with a covered condition. Employers offer it as a benefit, and members manage coverage and claims on the web and on iOS. I joined when the company was still called Brella; it later rebranded as Ansel, so the screens here show the Brella brand as it was when I designed them.
As Senior Product Designer I worked across both sides of the platform: the employer billing and payments portal, which this case focuses on, and the member claims experience. Insurance carriers Symetra and Nationwide also offered the product to their customers through partnerships, co-branded with Brella, so everything I designed had to work for three brands.
Discovery
Employers received their monthly invoice as an email with a PDF, and many paid by mailed check. To understand where that broke down, we ran interviews with employer admins, reviewed billing-related Concierge tickets, and walked through the invoice email and PDF process with admins and the Billing Ops team.
Two users, one invoice
The HR or benefits admin runs benefits for a small or mid-size company alongside many other duties. Their goal is to confirm the invoice matches who is actually enrolled, then get it paid or routed to Finance.
The finance or AP specialist pays dozens of vendors, and Ansel is one line in that process. They care about due dates, invoice numbers, the right payment method and a clean record for reconciliation.
Key insight: the person who understands the invoice is often not the person who pays it. The portal had to serve both, and make the handoff between them clean.
Pain points
No visibility. Admins only learned about an invoice when an email arrived. There was no preview, no status and no clear signal of "am I late?".
Unexplained changes. New hires, terminations and partial months changed the total every month, and admins called Concierge to ask why.
Paper checks. Slow, hard to match to invoices, and a key driver of past-due accounts and manual follow-up for Billing Ops.
No self-service setup. There was no way to add or verify a bank account, and no way for an AP colleague to do it without sharing a login.
Ideation and definition
We framed the problem as: how might we make every invoice self-explanatory, and every payment a two-click action, for whoever at the company is responsible for it?
Billing rules (prorations, adjustments, payment statuses) lived in the backend and in Billing Ops' heads, so before drawing screens I mapped every combination of invoice status with the PM and Billing Ops. Each scenario defines what the three overview modules show, which gave design, engineering and QA one source of truth and settled most "what shows here?" debates before they started.
A few rules came out of it: Make a payment only exists when a final invoice exists, every payment goes through a confirmation step, e-payment setup is always available even before the first bill, and the preview only appears when the backend has one. We also decided early to support two bank-linking paths from day one: instant linking through Plaid, and micro-deposits as the fallback.
Design, build & impact
Design and development
An overview for every billing state
The account overview adapts to where the employer is in the billing cycle, so the next action is always obvious: from a preview of upcoming charges, to an invoice that's ready to pay, to a calm steady state, to a persistent past-due banner.
Invoices that explain themselves
Invoice details break the total down to each employee. Partial-month coverage is flagged and explained, credits and corrections are listed separately with a memo, and "Reach out to Concierge" sits right where questions come up. Admins can reconcile on their own instead of calling.
Making ACH the easy default
Payment settings offer a path for every situation: instant bank linking with Plaid, micro-deposit verification for banks Plaid can't reach, and a clear default method.
To solve the "admin isn't the payer" problem, the admin can send a secure link so someone in Finance adds the bank account themselves, without sharing credentials.
Designing for what goes wrong
Money flows need guardrails. Every destructive or failing state was designed explicitly and reviewed with Billing Ops: the default method can't be removed while others exist, removing the last e-payment method warns that future payments will need a check, and a failed payment explains what happened while the invoice stays payable.
One product, three brands
Symetra and Nationwide offered Brella to their customers through partnerships. Instead of designing separate products, the same components were themed with each partner's logo, colors and carrier copy, co-branded with Brella. One system shipped three branded employer portals, and their billing emails.
The member side: claims on web and iOS
On the member side, I redesigned how people submit and track claims, one of the most critical and high-friction moments of the experience. Users didn't want to manage insurance; they wanted a fast, clear way to finish a task with confidence. The result was a three-step flow (what happened, upload, review and submit) with document guidance, a real-time tracking dashboard, and a choice of how to get paid.
Desktop and mobile. The complete journey lives side by side in Figma, from an empty claims list to tracking, including the in-between moments that usually get skipped, like guidance, processing and confirmation.
AI that checks documents as you upload
The biggest delay in claims wasn’t submitting, it was the back-and-forth afterwards: a missing diagnosis code or an unsigned page meant a request for more information and days of waiting. With this flow, AI reads each document the moment it’s uploaded, compares it with what the claims team needs, and tells the member exactly what’s missing and where to find it, before they submit. This flow was designed as part of the roadmap for future integrations, the next step for the claims experience.
Design system. The claims work sits on four linked libraries (Foundations, Patterns, Screens and Claims), with the claim card designed in every lifecycle state.
Implementation and handoff
States mapped 1:1 to the backend. Every UI state corresponds to an invoice or payment status, so engineering and QA tested against the same matrix.
Short loops with the whole team. Flows, wireframes and high fidelity in weekly syncs with the PM, Engineering and Billing Ops, plus async Figma reviews for copy and edge cases.
Ship with fallbacks. Implementation notes and copy fallbacks lived on the canvas, like a simpler toast if the custom success toast couldn't ship yet, which kept the release unblocked.
I owned the copy for banners, toasts and destructive confirmations, and partnered with engineering through build and QA.
AI in my process today
This work was done in 2021 and 2022, before today's AI tools. To present it, I rebuilt the billing journey as the interactive walkthrough at the top of this page with Claude Code, working from the original Figma files. It's how I prototype now: in code, with real interactions and states, in hours instead of days.
Impact
60%+ of claims were submitted through the mobile experience.
One system, three brands. The same billing portal and emails shipped for Brella, Symetra and Nationwide.
From email and paper checks to self-service. Employers can see what they owe and why, and pay by ACH in two clicks.
Billing targets set with Product: ACH share of invoices paid, fewer accounts reaching past due, fewer "why did my invoice change?" contacts, and payment-setup completion. Results: [add].
What I learned
Design the handoff, not just the screen. The admin and the payer are often different people.
A state model first, screens second. The scenario matrix prevented most debates later.
Guardrails are content design. The copy in destructive modals did most of the work.
Open enrollment starts Dec 1.
Discovery & problem
Context
Ansel offers supplemental health insurance that pays members directly when they're diagnosed with a covered condition. Employers offer it as a benefit, and members manage coverage and claims on the web and on iOS. I joined when the company was still called Brella; it later rebranded as Ansel, so the screens here show the Brella brand as it was when I designed them.
As Senior Product Designer I worked across both sides of the platform: the employer billing and payments portal, which this case focuses on, and the member claims experience. Insurance carriers Symetra and Nationwide also offered the product to their customers through partnerships, co-branded with Brella, so everything I designed had to work for three brands.
Discovery
Employers received their monthly invoice as an email with a PDF, and many paid by mailed check. To understand where that broke down, we ran interviews with employer admins, reviewed billing-related Concierge tickets, and walked through the invoice email and PDF process with admins and the Billing Ops team.
Two users, one invoice
The HR or benefits admin runs benefits for a small or mid-size company alongside many other duties. Their goal is to confirm the invoice matches who is actually enrolled, then get it paid or routed to Finance.
The finance or AP specialist pays dozens of vendors, and Ansel is one line in that process. They care about due dates, invoice numbers, the right payment method and a clean record for reconciliation.
Key insight: the person who understands the invoice is often not the person who pays it. The portal had to serve both, and make the handoff between them clean.
Pain points
No visibility. Admins only learned about an invoice when an email arrived. There was no preview, no status and no clear signal of "am I late?".
Unexplained changes. New hires, terminations and partial months changed the total every month, and admins called Concierge to ask why.
Paper checks. Slow, hard to match to invoices, and a key driver of past-due accounts and manual follow-up for Billing Ops.
No self-service setup. There was no way to add or verify a bank account, and no way for an AP colleague to do it without sharing a login.
Ideation and definition
We framed the problem as: how might we make every invoice self-explanatory, and every payment a two-click action, for whoever at the company is responsible for it?
Billing rules (prorations, adjustments, payment statuses) lived in the backend and in Billing Ops' heads, so before drawing screens I mapped every combination of invoice status with the PM and Billing Ops. Each scenario defines what the three overview modules show, which gave design, engineering and QA one source of truth and settled most "what shows here?" debates before they started.
A few rules came out of it: Make a payment only exists when a final invoice exists, every payment goes through a confirmation step, e-payment setup is always available even before the first bill, and the preview only appears when the backend has one. We also decided early to support two bank-linking paths from day one: instant linking through Plaid, and micro-deposits as the fallback.
Design, build & impact
Design and development
An overview for every billing state
The account overview adapts to where the employer is in the billing cycle, so the next action is always obvious: from a preview of upcoming charges, to an invoice that's ready to pay, to a calm steady state, to a persistent past-due banner.
Invoices that explain themselves
Invoice details break the total down to each employee. Partial-month coverage is flagged and explained, credits and corrections are listed separately with a memo, and "Reach out to Concierge" sits right where questions come up. Admins can reconcile on their own instead of calling.
Making ACH the easy default
Payment settings offer a path for every situation: instant bank linking with Plaid, micro-deposit verification for banks Plaid can't reach, and a clear default method.
To solve the "admin isn't the payer" problem, the admin can send a secure link so someone in Finance adds the bank account themselves, without sharing credentials.
Designing for what goes wrong
Money flows need guardrails. Every destructive or failing state was designed explicitly and reviewed with Billing Ops: the default method can't be removed while others exist, removing the last e-payment method warns that future payments will need a check, and a failed payment explains what happened while the invoice stays payable.
One product, three brands
Symetra and Nationwide offered Brella to their customers through partnerships. Instead of designing separate products, the same components were themed with each partner's logo, colors and carrier copy, co-branded with Brella. One system shipped three branded employer portals, and their billing emails.
The member side: claims on web and iOS
On the member side, I redesigned how people submit and track claims, one of the most critical and high-friction moments of the experience. Users didn't want to manage insurance; they wanted a fast, clear way to finish a task with confidence. The result was a three-step flow (what happened, upload, review and submit) with document guidance, a real-time tracking dashboard, and a choice of how to get paid.
Desktop and mobile. The complete journey lives side by side in Figma, from an empty claims list to tracking, including the in-between moments that usually get skipped, like guidance, processing and confirmation.
AI that checks documents as you upload
The biggest delay in claims wasn’t submitting, it was the back-and-forth afterwards: a missing diagnosis code or an unsigned page meant a request for more information and days of waiting. With this flow, AI reads each document the moment it’s uploaded, compares it with what the claims team needs, and tells the member exactly what’s missing and where to find it, before they submit. This flow was designed as part of the roadmap for future integrations, the next step for the claims experience.
Design system. The claims work sits on four linked libraries (Foundations, Patterns, Screens and Claims), with the claim card designed in every lifecycle state.
Implementation and handoff
States mapped 1:1 to the backend. Every UI state corresponds to an invoice or payment status, so engineering and QA tested against the same matrix.
Short loops with the whole team. Flows, wireframes and high fidelity in weekly syncs with the PM, Engineering and Billing Ops, plus async Figma reviews for copy and edge cases.
Ship with fallbacks. Implementation notes and copy fallbacks lived on the canvas, like a simpler toast if the custom success toast couldn't ship yet, which kept the release unblocked.
I owned the copy for banners, toasts and destructive confirmations, and partnered with engineering through build and QA.
AI in my process today
This work was done in 2021 and 2022, before today's AI tools. To present it, I rebuilt the billing journey as the interactive walkthrough at the top of this page with Claude Code, working from the original Figma files. It's how I prototype now: in code, with real interactions and states, in hours instead of days.
Impact
60%+ of claims were submitted through the mobile experience.
One system, three brands. The same billing portal and emails shipped for Brella, Symetra and Nationwide.
From email and paper checks to self-service. Employers can see what they owe and why, and pay by ACH in two clicks.
Billing targets set with Product: ACH share of invoices paid, fewer accounts reaching past due, fewer "why did my invoice change?" contacts, and payment-setup completion. Results: [add].
What I learned
Design the handoff, not just the screen. The admin and the payer are often different people.
A state model first, screens second. The scenario matrix prevented most debates later.
Guardrails are content design. The copy in destructive modals did most of the work.