I’m Clara. I design the hard, regulated, high-stakes flows, where clear design decides whether someone trusts a product or leaves it.

Portrait of Clara Ferreira, smiling outdoors

Projects

Subscription Management

Backup payment methods and a plan hub built to scale. Failed payments fell 82%, and accounts in dunning fell 84%.

Catalog Manager

Operations teams needed engineers every time a reward catalog changed. I designed a manager they could run on their own, and development tickets dropped 20%.

Case study coming soon

Financial Admin

I led discovery for one platform to replace scattered payment processes. Operational incidents fell 60%, and it later became a product of its own.

Case study coming soon

Work experience

NoLimit Creatives / Jul 2025 → present

Lead Product Designer

An AI brand-profiling wizard cut brand setup time by 80%, and a quality check before handoff reduced revision requests by 45%.

FazPay / May 2025 → Jun 2026

Lead Product Designer

My Pix payment flow, built from scratch under Central Bank rules, raised payment completion by 35%.

Incentive.me / Feb 2024 → Jun 2025

Product Designer / Product Manager

Turning batch payments into a self-service flow cut the operations team’s monthly workload by 86%.

Dock.tech / Jun 2021 → Nov 2022

Product Designer

Reworking Pix limits and two other core flows for Central Bank compliance reduced errors and delays by 20%.

Degrau / Mar 2021 → Mar 2022

Project Director

With a team of four designers, I ran app, brand and social projects that grew engagement by 30%.

Academic

Universidade Federal da Paraíba /
Jul 2020 → Jul 2024

Bachelor of Product Design

I like to understand the problem first, then build something real enough to test.

Clara photographing a historic brick building

I’ve been designing fintech, payments and SaaS products since 2021, from Pix checkouts to the internal tools payment teams rely on every day. I’m happiest when I can prototype with Cursor, Claude and Figma Make and put an idea in front of real users early. At Incentive.me I also took on product work, managing API partners and building the dashboards leadership used to plan the roadmap. Today I lead design at NoLimit Creatives.

Hobbies

Photography

I bought my first camera in college and haven’t put it down since. My favorite project documented the cultural heritage of the town around my campus.

View my photo album →

Historic red-brick building overgrown with plants

Digital illustration

I started painting digitally during the pandemic. It’s the one place I create without a brief, just for fun.

See my illustrations →

Digital illustration of two capoeira players on a green background

Hiking

I grew up hiking to find hidden waterfalls. It’s still my favorite way to recharge and spend time with my family.

Clara sitting on a cliff edge overlooking a green canyon

Music

Music is a big part of my life. I play the ukulele, I’m learning piano, and I’ve recently gone back to the violin.

← All projects

Fewer failed payments, and billing built to grow with every new service

Role: Design Lead
Team: Product, Engineering, Billing team
Platform: Internal console, desktop and mobile
Status: Live, with more phases rolling out

−82%

failed payments

−84%

accounts in dunning

−41%

manual billing tickets

Try the console

Open an account, check its payment methods, change its plan, or walk through a dunning case. Names and figures in the prototype are fictional.

Subscription ManagementBilling console

My role

I was the design lead, working with product, engineering and the billing team from the first discovery session to the specs engineering built from. The flows, the visual language and the decisions are mine.

The interactive prototype was built with AI, from my designs and direction.

The problem

Billing ran on Stripe’s built-in subscription logic. It could charge a card, but every failed payment and every plan that didn’t fit its rules turned into manual work for the billing team.

Stripe reports. The platform decides.

Stripe keeps the charge and the stored card. Everything else, from plans to dunning, moved into the platform.

How I built it

01 Discovery
Short working sessions with the billing team to map what they did by hand and what could run on its own.
02 Prototype
Reviewed a working console with the team early, so their feedback shaped the flows before handoff.
03 Rules
Turned each decision into a business rule, like how many payment methods an account can hold and in what order they’re charged.
04 Specs
Wrote screen-by-screen specs with acceptance criteria, so engineering built exactly what was agreed.

Two problems worth solving

Out of everything the billing team handled by hand, two problems mattered most to the business.

Payment methods tab for one account: a default card, backup method 1 as a bank account (ACH) and backup method 2 as a card, each noting when it is used — Fig. A: A default method and two backups, charged in order

One card failing shouldn’t fail the payment

Accounts can now keep up to three payment methods: a default and two backups, by card or bank account. When a charge fails, the next method is tried automatically, before the account ever reaches dunning.

−84% accounts in dunning

Plans built from parts

The business was expanding past its current plans, and the old setup couldn’t take a new service without rebuilding billing around it. In the new hub, plans, add-ons and coupons are separate building blocks, so a new service becomes a new plan instead of a new project.

Plans screen with five plan cards, each listing design types and per-slot pricing for self-managed and fully-managed support, and a New plan button — Fig. B: Plans, each with its own pricing per slot and support level

Change subscription screen: four plan cards with Full Stack selected, and a sidebar with slot stepper, management style, add-ons and the total due today — Fig. C: Changing a plan, with the total recalculated on every choice

Reusing what customers already know

To change a plan on someone’s behalf, the billing team uses the same builder customers see. The total updates with every choice, and Confirm stays off until something actually changes.

Dunning details for one account: payment failed badge, amount due, status, attempts, account health bar and a timeline of notices and retries — Fig. D: One dunning case, from first notice to next retry

When every method fails

The account enters a recovery sequence the team configures: reminders and retries, with a timeline of what happened and what comes next. Fewer accounts land here now, and the ones that do don’t need a support ticket.

A way out before cancelling

Cancelling starts with a choice: leave, or move to a lighter Maintenance plan that keeps the account alive.

Phone view of Subscription management with the accounts table shown as stacked cards — Fig. E: Accounts as cards

Phone view of an account with Change subscription as a full-width button and scrolling tabs — Fig. F: Account overview

Still usable on a phone

Tables become cards and tabs scroll instead of wrapping. Same console, real breakpoints.

Small rules that kept it consistent

Buttons
One primary action per view, labeled with exactly what it does: “Confirm subscription change”, never “Submit”.
Status
Color only ever means status. A badge is never colored for emphasis, so an account and its invoices always agree.
Proration
The unused-time credit and the new charge appear before the total, because a total on its own invites a support ticket.

End

Subscription Management