How we designed our Bank Account — NuConta Part II
In Part I, we walked through the process of understanding and defining the problem we were aiming to solve. Here, we are going to dive into how we executed the design based on that vision.
Co-design
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 is already envisioning a solution that solves the problem from that point of view. A co-design 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
Each co-design session uses a different methodology to achieve its goals. In this case, our strategy to generating a more solid set of ideas was to divide participants in groups and assign them a different Persona (which we created in Part I). Personas helped participants empathise with a different type of person and their associate hopes, challenges, and opportunities, rather than being confined to one’s own experience and perspective.
Generate better questions and surface constraints.
Besides the ideas themselves, a lot of the value of the co-design 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’re more expensive to solve.
Design exploration
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, NuConta does not fit squarely into a checking, savings or investment account “box”, so 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 best represent it on a screen. Given this potential complexity, we spent most of this time collaborating at the white-board without touching a digital design tool.
Only after extensive discussion and brainstorming we felt 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, an 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.
Designing for transparency, with transparency
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.
Mapping the whole experience
Producing a well-crafted individual screen is satisfying, but we can never forget that every touchpoint is part of a larger 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.
Prototypes
We made every kind of prototype you could imagine when exploring solutions for NuConta. 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, lower fidelity prototypes allowed us to trim the rough edges of the product 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. This 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 on the results.
We did not put so much effort into a prototype like this just because we like new tools (which we do), but 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, and align your tool choice and development budget to that goal.
But should designers…
…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 black magic ourselves, and had a team of developers willing to support us. It also helps that NuConta was being developed in React Native, which is a less threatening endeavour for those of us with frontend experience than say a native development project.
Result
Defining NuConta’s purpose, 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 the 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 NuConta is the most cohesive and friendly product for the target group we chose to aim at. In it's first months, it certainly will lack major features that are expected from a banking account. But even in this early, incomplete stage, NuConta can provide great value to our first customers, from whom we expect to receive tons of feedback that will guide our way forward.
Thanks for reading, keep following our latest design stories!
We are always looking for great designers to help us grow and fight complexity. If you have experience and want to build the future of financial services with us, look for open positions here.
