How we designed Nubank’s Bank Account — Part II

(See Part I here)

The first thing we do at Nubank once we have a solid problem definition is what we call a co-design session. We invite people from different squads and chapters to work together, aiming to accomplish the following things:

Let everyone’s bad ideas out

After weeks of research, it is inevitable that people dream up and fall in love with their own pet ideas. Each stakeholder, at this point, has partially understood the problem and already envisions a solution that solves the problem from that perspective. Co-designing is a way to let those thoughts circulate, be put in perspective, and get feedback in a safe environment. Solutions that seemed excellent in the shower at home will inevitably find shortcomings when engineers, designers, PMs, analysts and other experts help to challenge them logically.

Generate more ideas

Every co-design session uses a different methodology to achieve its goals. In this case, our strategy for generating a more substantial set of ideas was to divide participants into groups and assign them a different Persona (which we created in Part I). Personas helped participants empathize with a different type of person and their associated hopes, challenges, and opportunities, rather than being confined to their own experience and perspective.

Generate better questions and surface constraints

Besides the ideas themselves, a lot of the value of co-designing is in exposing unknown unknowns, hidden constraints, and stakeholders’ concerns about each alternative way forward. By bringing together different disciplines and encouraging debate, co-design maximizes the possibilities of finding problems that would appear later, when they would be more expensive to solve.

Based on the ideas generated by the team, we started the deepest dive I’ve ever taken on product design exploration. In many ways, both from a technical and a product perspective, Nubank’s account does not fit squarely into a checking, savings, or investment account “box”. Therefore, we found it a real challenge to align the interface with a user’s pre-existing mental models about money management. A new paradigm for how the money was going to be kept and used required a lot of hard thinking about accounting and how to represent it on a screen best. Given this potential complexity, we spent most of this time collaborating at the whiteboard without touching a single digital design tool.

Only after extensive discussion and brainstorming did we feel ready to start wireframes and pixel-pushing. We tried dozens of versions of the UI of onboarding flows, empty states, investment simulators, charts (OMG, so many charts), financial goals, investment streaks, etc. We allowed ourselves to go quite crazy in the beginning, bypassing many rules of our current design system, and then adjusted as we got closer to the final result.

It was quite a journey until we felt we had reached a sweet spot of information architecture, visuals, and flows that could communicate the mechanics of the product without exposing the user to unnecessary jargon and complexity.

One key component of the speed and quality of our workflow in this project was to use Figma in the early stages of the UI design process, because of the high level of collaboration and transparency it allows. Just like our live-streamed user tests, Figma makes it frictionless for stakeholders to watch, participate, and gain empathy for the design process in real-time.

Producing a well-crafted single screen is satisfying, but we can never forget that every touchpoint is part of a broader ecosystem. Below is an example of how we kept track of every App screen, push notification, email, website page, and social media posts that first-time users would encounter.

Figma, again, thrives for communication assets like this in a way that a 15MB PDF never could. Everyone pitched in with questions and ideas based on their expertise: copywriting, engineering, legal, and UX.

We made every kind of prototype you could imagine when exploring solutions for Nubank’s account. We made cheap paper prototypes to test copywriting and general information architecture. We made quick Keynote animations to show engineers the vision for a specific interaction. We built screens and flows on Principle to test signup flows and empty states. Some prototypes even had fake branding and visuals, so we could go outside the building and show it around in stealth mode.

Starting with simpler low-fidelity prototypes allowed us to trim the rough edges of the product’s overall concept until we eventually hit a level of complexity in the tests that required a more high-fidelity, versatile prototype. So we decided to invest in a month-long project to create a full-blown Framer + Javascript prototype that passed variables around, reacted to the user’s financial data, and let them simulate deposits. It was, of course, not just the work of our design team but a coordinated effort with the technical team to support us not only in programming the prototype but also in user-testing it and iterating the results. 

We did not put so much effort into a prototype like this just because we like new tools (which we do). We did it out of necessity: “dumber” prototypes are helpful in many contexts, but we learned that making savings simulations with static data can feel weird and skew test results. People with lower incomes might freeze when they look at monthly R$1.000 deposits, and people with higher salaries will find those numbers underwhelming and foolish.

The key, on any project and at any company, is to agree on a clear definition of what the team wants to learn with each prototype. Then, align your tool choice and development budget to that goal.

…code? It depends. At Nubank, some of us do, some don’t. In this project, it made sense that designers could lend a helping hand to the development team. We were willing to dive into this magic ourselves and had a team of developers ready to support us. It also helps that we were developing Nubank’s account in React Native, which is a less intimidating endeavor for those of us with front-end experience than, say, a native development project.

Defining the purpose of Nubank’s account, in Part I, took a lot of work, and we’re happy to see our initial product meets these goals.

• It sits outside any account category that customers previously knew of, merging the best of current, savings, and investment products.
• It is a product anyone aged 18 or older in Brazil can acquire with a few taps, no credit analysis, or other bureaucracy involved.
• It is 100% free of jargon and acronyms.
• It automatically invests all of the user’s money in low-risk assets with daily liquidity, without requiring complex onboarding or learning how this kind of investment works.
• It is 100% transparent about your money and tells you in real-time how much value you are getting by using the product.
• The UI progressively displays information in a way that it is there when you need it, but only when and if you need it. It feels accessible to less savvy users and transparent to people who need more information.

By combining the tools, processes, and team dynamics described in these two posts, we are confident that the shipped version of Nubank’s account is the most cohesive and friendly product for the target group we chose to aim at. In its first months, it certainly will lack the major features that we expect from a banking account. But even at this early, incomplete stage, Nubank’s account can provide great value to our first customers, from whom we expect to receive tons of feedback that will guide our way forward.

(Thanks to Hugh Strange and Erick Mazer Yamashita.)