Project overview
I joined Namu in 2022 as the company's first designer. There were fewer than ten of us and the goal was to build Brazil's first 360° wellness super-app. I left three and a half years later, with four products live, and here is what I built.
The Context
Namu wanted to build Brazil's first 360° wellness super-app. The product already existed, but only just, it was essentially a blog with a few classes and not many features. An agency had just delivered a redesign the stakeholders hadn't liked, and the roadmap grew every week with new commercial demands.
It was that chaotic startup scenario we all know.
The goal was clear: Namu wanted to stop being only a B2C app and become a B2B2C service. A SaaS to serve the B2B demand (Namu Business) had already been sketched out, but it was still very raw.
There was a marketplace inside the app offering wellness consultations, and a separate app (Namu PRO) where any professional could sign up and take appointments. The idea was to change that and bring an in-house team of professionals into the role, doing away with the open marketplace.
That is where the core business model comes in: the company buys the Namu App as a benefit for its employees, and gets back a reading of the workforce's wellbeing. The whitelabel version of the app would come later.
That defined who I had to design for. Every screen answers to three people with different interests at the same time: the regular user who downloads the app from the store and pays for the plan, the employee whose plan is paid for by the company, and the HR team that has to justify renewing the contract. And Namu PRO had to serve the in-house wellness professionals.
The Challenge
There was no design system. Every new feature was born from scratch. A developer would open Figma, find one component inside a card, find a different component inside a modal, not know which to follow, and create a third.
The inconsistency didn't stop at the main app either. It ran through every other product the company sold alongside it.
And nobody was going to pause the roadmap so I could put the house in order.
Process
When I arrived there was no budget and no time for formal research, so I started with what was already there: the Google Analytics data, benchmarks, tests, user feedback that had been filed away with nobody acting on it, and the agency's redesign as a starting point.
I worked on three fronts at the same time during those first months. Adapting what existed, designing what the roadmap asked for, and feeding a new design system with everything that passed through the other two.
None of those fronts waited for the others to be ready, and there was a lot of engineering debt. Had I stopped to build the system in isolation before touching the product, development would have stalled.
My approach drew from Design Thinking and an adapted Double Diamond: understand the problem space before jumping to solutions, but compress the timelines to match a startup's pace. I used Jobs to Be Done to frame what each user type was actually trying to accomplish, which kept the design grounded in real needs rather than feature requests.
In practice, every feature started with rough sketches and moved quickly into iterative prototyping. I would sketch flows by hand, validate the logic with product and engineering, then jump to high-fidelity prototypes in Figma. Each round of feedback shortened the next one.
I worked inside the technology team, operating in Scrum alongside the developers every day. That proximity changed everything. I wasn't handing off specs from a distance, I was in the dailies, adjusting scope in real time, catching implementation issues before they became debt. Design decisions happened at the speed the sprint demanded.
System
The design system was the main pillar for scaling the product and delivering on the roadmap we had projected.
Colours, components, spacing, interaction states, behaviour rules, entire flows, all documented.
The system also had to adapt to the whitelabel and run with a completely different identity for enterprise partners.
We defined rules for how each component would behave in a whitelabel version: what changes, what doesn't, and what gets hidden.
All of it had to be formulated with development efficiency in mind.
Complexity
Beyond the different types of user on the platform, there is another extensive layer of complexity: each client company assembles its own app configuration, hiding features or not, and the menu and the home screen reorganise themselves because of it. Every screen I designed had to survive across different versions.
Mapping all of those paths and scenarios was a real challenge. In digital product design the alternative flows are often neglected and we show only the happy path in the mockups, but failing to map those routes properly would create engineering debt later on.
So we didn't just produce mockups for every flow and scenario; everything was extensively documented as well.
Accessibility
Our personas were complex. The app had to speak to young people in their first job, to older users looking to improve their health, to teenagers coming in as dependents…
With the whitelabel launch it got more complex still, and with that in mind there was one factor that could not be neglected: accessibility.
We ran a full review following WCAG, text sizes, colour contrast, touch targets, clarity of information, captions. Everything was revisited through that lens, improved and tested.
Testing and validation
No feature reached development without first going through a mockup and a prototype presented to product and engineering. After that I wrote the spec, handed it to the team, and followed the build in a daily meeting. Once it was ready it was tested before shipping: every route, every button, every state, what the screen showed when something went wrong. It went back for adjustments as many times as it needed.
I was the one presenting what was new internally, and the company grew fast, before long I was explaining a launch to fifty people in a meeting and answering a question from a department I didn't even know existed. That turned into an excellent research channel. Sales brought me what the client was asking, support forwarded me tickets to help resolve, I followed the store reviews, and I talked directly with the wellness professionals working through Namu PRO, the app on the other side of the consultation. A good part of what got adjusted in the product came out of those conversations.
Leadership
After two and a half years I became the design team lead, and we hired a junior designer.
A good part of my job became knowing what to delegate and how: too complex a task drowns someone, too small a one leaves them idle, and Namu's ecosystem was far too large for anyone to absorb in one go.
I introduced it piece by piece, with a check-in whenever he reached a part of the app he didn't know yet, and I taught the essentials: document, write specs, feed the design system without breaking what was already there.
I was there to lead and to teach, and I learned more than I taught. Until then I had always been a solo designer. Sharing the work with another person changed my whole routine. I spent a year in that role and it was one of the most rewarding experiences I have had.
Results
Some of the numbers reached:
16 min/day of average use in the app, nearly 2× the wellness mobile benchmark in the same niche.
105% growth in monthly active users in the six months before I left.
3,600 monthly active users.
Partnerships with major insurers and pharmacy chains.
Projected access to 3.2 million people for 2025 through the whitelabel partnerships and B2B sales.
Takeaways
I joined Namu when there were fewer than ten people there and left when it was already one of Brazil's leading preventive health and wellness platforms, with 4 main products: Namu App, Namu Business, Namu Whitelabel, Namu PRO.
At the start I was the only designer, and by the end I was leading a small team, where I got to learn how to guide another designer inside the ecosystem I had built, so that he could make autonomous decisions without breaking what had already been built. Beyond that, what shaped me most in the meantime was sitting every day next to people who did completely different things from me: developer, product manager, advertiser, video editor, salesperson. Each one showed me a part of the product I would not have seen on my own.
At Namu I learned to decide fast, because a short deadline forces you to choose where you can cut and where saving costs you dearly later. And when the features started shipping one after another, I discovered the price of leaving a decision in conversation only. Whatever nobody wrote down disappears in the next sprint, and someone will spend a week rediscovering why. Documenting became part of designing.
I could write a lot more about what I learned, but I will save it for when you and I get to talk ;) Thank you for reading.
This case study is a preview, we're still building it.