Fintech design is mostly about removing doubt

Nobody opens a banking app for fun. People open it to check something, pay something or fix something, and they usually arrive a little worried. Most of the work we've done in financial services comes back to that worry: find where it comes from, then design it out.

This note pulls together five projects: a credit card issuer, a group of regional banks, a crypto platform, a payments app and an insurer. Different products in different countries, and the same few lessons kept coming up.

Faster load times on Naranja's new platform

3x

Running on one design system at Grupo Petersen

4 banks

Automated test coverage bar on Fpay

80%

Speed reads as competence

Naranja is Argentina's largest credit card issuer. The numbers from its new platform are business numbers: 21% more visits on mobile, load times three times faster and an architecture about 60% smaller. Google featured the platform in its Mobile First report.

Grupo Petersen saw the same pattern. Server-side rendering and a round of optimization made loading and navigation up to 50% faster across its banks.

I don't think users file this under performance. A slow financial site feels like a site that might fail halfway through a payment, and people hesitate before they tap. A fast one feels like it knows what it's doing.

The design system is how the bank keeps shipping

Financial companies have many business units, and all of them want to publish. At Naranja we built a design system and brought in the Contentful CMS early, so each business unit could own its user-facing content. The component library was designed around the editorial workflow too: drafting, editing, proofreading and publishing.

The client's need for scalability and change-tolerance meant we needed to come up with solid, versatile components that make it straightforward to constantly add content and make adjustments.

Grupo Petersen took the idea further: one design system and one CMS for four banks, Banco Santa Fe, Banco Entre Ríos, Banco San Juan and Banco Santa Cruz. The components had to cover every product and service the banks offer, and new landing pages had to be possible without technical knowledge. Nine people built it over eight months with Next.js, Storybook and Contentful.

In both cases the design system is what let the bank keep shipping after our team moved on.

Lower the intimidation

Ripio is one of the pioneers of crypto in Latin America. When we worked with them, crypto was far from mainstream and the learning curve was steep. Our discovery work concluded that Ripio needed to be more than a wallet. It needed to be a way into the crypto world.

I was the project manager on that one. We focused on onboarding and offboarding, so buying or selling crypto for the first time felt less intimidating and people could use new tools without being tech-savvy. We rebuilt the navigation and sitemap for people with and without an account, and improved the KYC flow together with the business requirements, which increased its conversion rate. A custom illustration and icon system made sure Ripio didn't look like every other exchange.

Sura, one of Latin America's largest insurers, is the same problem under more pressure. The flows that matter most get used on bad days: reporting a claim, or asking for help when your car breaks down. Clients had done this by phone for years. Our designers made the status of every process visible, used illustration to lower the effort of each step and explained technical insurance terms along the way. The more people could handle on their own, the less weight fell on customer service.

Trust needs engineering underneath

A payments app has very little room for error. Fpay's teams were spread across Argentina and Chile and split by layer, from backend to frontend. We defined the structure and requirements of the repository at kickoff, to avoid refactors later, and held an 80% automated test coverage bar from the start.

Backend and frontend development started at the same time, so the frontend team built mocked integrations from scratch to keep its work from stalling. A Bitrise pipeline compiled versions of the app for iOS and Android with minimal effort. With so many teams to keep in sync, we moved to one-week sprints with planning every Monday, and the app got new features and fixes every week.

How long these projects took

For anyone planning a similar project, here is what each one took:

What carries across

A few rules held up in every one of these projects:

• Treat speed as part of the product. People read a slow screen as a risky one.
• Give business teams ownership of their content, with a design system and a CMS they can use without developers.
• Find the moment of doubt in each flow, like a first crypto purchase, an identity check or a car accident, and design for that moment first.
• Set engineering guardrails at kickoff: test coverage, a delivery pipeline and a sprint rhythm. They cost less then than after the first incident.