I take products from discovery to launch, from healthtechs to insurance companies, always alongside the engineering team and with the user at the center of every decision.
I'm a designer from Recife with over 5 years leading discovery, prototyping and handoff across digital products, from healthtechs to insurance platforms used by tens of thousands of people.
I've worked alongside CEOs conceiving products from scratch, led design system evolution and built design teams. I like complex problems, data-driven decisions, and making each delivery simpler than the last.
Maria sees the problem before rushing to the solution, and that made all the difference. She asked the right questions, explored alternatives with genuine curiosity and always sought to understand the why behind every decision. I recommend her without hesitation to any team that values real collaboration and strategic design thinking.
Geovana Paes
AI Product Manager at Amigo Tech
"
A UX Research specialist, Maria Fernanda has a unique ability to understand users' needs and behaviors, resulting in valuable insights for product development. Her meticulous, data-driven approach ensures design decisions are always well-founded and effective. Maria Fernanda is resilient and cooperative, showing a unique ability to face challenges with a positive, collaborative attitude.
Paulo Ortega
Product Design Specialist at Porto Seguro
"
A professional capable of finding creative solutions to problems, with rare clarity in documenting and presenting her point of view. Her sharp technical eye catches details few others would have the sensitivity to notice. She masters the main tools for great UX/UI work and knows how to work well in a team.
Marcos Barreto
Head of Design at Main Leaf
Let's talk?
Open to new projects, partnerships and conversations about product and design.
Redesigning AmigoFlow's hierarchy to support large-scale clinics
Team
1 Product Designer (me), 1 PM, 15 devs
The heart of the product wasn't ready for what came next. And I already suspected it.
AmigoFlow is a support CRM for clinics, with an AI agent at its center. The agent talks to patients over WhatsApp, resolves what it can on its own, and when it can't, escalates to a human agent. I was on the project from the start, a large product, heavy investment, a team of 15 developers.
The first version worked. But still during the first launches, with the business starting to talk about omnichannel and large clients, I raised a suspicion: this foundation would not last. And, in parallel with the MVP design, I began sketching what the solution would look like if, when, the suspicion was confirmed.
One agent, one channel, one group. Period.
In the first version, the central entity was the AI agent. For each agent created, a single WhatsApp number and a fixed group of human agents were configured inside it. A closed relationship: 1 agent → 1 channel → 1 group.
It worked well, while the product served small clinics, with a simple scenario.
The problem I predicted showed up. With a first and last name.
The confirmation came from outside: a large client raised a need the configurator simply did not meet. Large clinics don't follow the "one agent per channel" logic, one agent covers several channels, a clinic has one number for the doctor and another for reception, one channel is just marketing and another is scheduling.
And in the old model, each channel was an isolated world: the agent only saw messages from one channel at a time, switching tabs all the time. There was no unified view. The structure didn't support multichannel, and that was exactly what the new strategy demanded.
The difference between panic and a plan is timing.
Here is what I am proudest of on this project. When the problem broke out, it could have turned into a crisis, a "now what?" with the team scrambling to catch up.
But it didn't. Because much of the problem had already been mapped by me and the PM, and I had already been designing the solution in parallel. So, at the emblematic moment when the urgency appeared, we were not starting from scratch: we were pulling something already thought through out of the drawer.
The turning point was neither fast nor automatic, convincing people it was worth rebuilding a foundation that "already worked" takes argument and evidence. What unlocked it was the combination of two things: the pain was now visible (a real client, a concrete need) and the answer already existed. We managed to reassure the team that it had been anticipated and was solvable.
The architecture decision was mine, built by pulling the team in close.
The solution: invert the hierarchy. Instead of the agent being the central entity, the channel becomes it.
I got there from conversations with the PM and the feedback she got from users of an internal product we used as a reference, similar to ours, but with real users in operation. The decision on what the new architecture would be came from me, but never alone in the dark: I constantly pulled the team in to question my logic, the PM especially, and I ran multiple meetings with the devs during the design to understand what was feasible in time. Everyone aligned that the problem existed, the discussion was about the how, not the whether.
In the new model, I attach multiple channels, WhatsApp, Instagram, whatever, and inside each channel I configure an agent with its own skills and knowledge base. The difference is subtle and changes everything: instead of "this agent serves these channels," it becomes "this channel has this agent, which behaves this way in here." That lets me personalize per channel:
A channel just for marketing, with an agent trained for campaigns.
A channel for general support, scheduling, billing, questions.
A channel exclusive to the lead surgeon, with targeted instructions.
A channel per care unit, each with its own rules.
And the agents? They gained freedom.
Separate from the channel configurator, I created a sector configurator. Now an agent serves multiple channels, all messages flow into one place, without switching tabs. It's true omnichannel.
Inside each channel, I set a default sector: when the agent doesn't know where to transfer, it goes there. And the same default sector can exist across several channels, the agent receives everything unified, no matter where the conversation started.
How we validated it (without user testing, and why)
Being honest about the process: we did not test the new configurator with end users, because the system was rolled out by an internal team of ours, not by the clients on their own. Validation came another way, and a very concrete one: dozens of tasks the old architecture blocked were unlocked, and entire flows, previously impossible, came to exist without the limitations of the 1:1:1 model.
The real test was one of capability: things that simply could not be done before, now could.
The foundation for everything that came after
The new model didn't just solve the immediate problem, it unlocked the next strategy: the shift to omnichannel. Because the foundation was drawn right early on, every feature launched afterward could be built on top of it, without hitting the same wall again. Had the restructuring taken longer, the cost of catching up, and undoing everything built on the old structure, would have been much higher.
What I take from this project
Anticipating is worth more than reacting. Seeing that the foundation would break before it broke, and designing the answer in parallel, is what turned a possible crisis into a controlled transition.
Being right is not enough, timing matters. I had the solution months before it was accepted. What unlocked it was not just the argument; it was waiting for the pain to become visible to everyone.
A technical decision can come from design, as long as you bring the team along. I drove the architecture, but questioning my own logic with the PM and the devs at every step. Authorship is not deciding alone; it is leading the decision.
Let's talk?
Open to new projects, partnerships and conversations about product and design.
