Centauro had a design team of almost 30 people, with a set of design principles that almost nobody was using. The principles existed in documentation, had been created through a cross-functional workshop involving both UX and marketing, and were well-intentioned. But in practice, they weren't showing up in design decisions, critiques, or team conversations.

As the team was about to double in size, the risk was clear: without a shared foundation for how we make decisions, consistency would become impossible and alignment would depend entirely on individual judgment and informal communication.

Before proposing anything new, I wanted to understand why the existing principles weren't being used. Rather than assuming, I ran a structured workshop with the entire design team to find out.

Three root causes emerged from the workshop: the principles weren't memorable: designers had to look them up to recall them. They weren't applicable: it wasn't clear how to connect them to daily decisions. And they were too broad in scope: they tried to say everything and ended up directing nothing.

With the team about to grow, we decided this was the right moment to start from scratch rather than patch what wasn't working.

I designed a multi-stage workshop process that took the team from diagnosis to ownership. The goal wasn't just to produce better principles. It was to produce principles the team had genuinely built together, because participation was the only way to get real adoption.

The process had six stages: understanding what principles are and what makes them effective; each person creating three candidate principles; grouping by similarity; small groups defining and writing three principles each; a presentation and vote to select the final set; and finally, applying the chosen principles to real pages of the Centauro website to test whether they actually worked in practice.

That last step revealed something important: what the team had produced weren't quite principles yet. They were three broader concepts (trust, simplicity, empathy) with a cluster of values and ideas underneath each one. Rather than forcing them into a principle format, I adapted the process to work with what had actually emerged.

We added a refinement stage: writing and rewriting short sentences that captured each concept, testing different wordings against each other, discussing what different people understood when they read the same sentence. Language turned out to be the hardest part of the work.

We also added something we called "What does that mean?" A practical complement to each principle with concrete examples of how it should show up in daily design decisions. This was contributed to asynchronously by the whole team, which served as both a participation exercise and a comprehension test: if someone's contribution was very far from the intended meaning, we knew we needed to rewrite.

The final output was three design principles, each with a short memorable statement and a set of concrete "what this means" examples written by the team:

The principles were then embedded into Figma templates, team pages, and critique documentation, bringing them into the places where design decisions actually happen, rather than left in a document that nobody opens.

The principles became part of the team's critique culture and design documentation. The adoption wasn't instant. It never is. But the foundation was different: these were principles the team had built, tested, and written themselves. The sense of ownership changed how people related to them.

The process itself also became a model for how to approach team alignment problems: start with diagnosis, involve everyone, make the abstract concrete, and embed the output into daily routines rather than documentation.

Prime is eDreams' subscription program, one of the most important revenue drivers in the business. Acquiring new Prime members is a key goal, and the mobile funnel is where most of that happens.

At the time, the existing experience had serious usability issues. Through Fullstory analysis, I identified patterns of back-and-forth navigation, click rage, and high drop-off on the Prime page, signals that users weren't understanding the value proposition, or weren't encountering it at the right moment.

The team's initial instinct was to improve the existing Prime page: better layout, clearer copy, stronger visuals. A reasonable direction, but one that accepted the current mental model without questioning it.

After running a benchmark across competitors and analysing behavioural data, I reframed the opportunity: instead of asking users to navigate to a separate page and make a deliberate decision, what if Prime was introduced more naturally, at the moment of checkout, in a way that felt low-friction and transparent?

This shift changed the entire design direction. The goal was no longer to improve the Prime page. It was to rethink how Prime acquisition happened in the funnel.

Before proposing anything, I ran a thorough audit: Fullstory sessions, funnel metrics, Prime page performance, and a competitive benchmark. I was looking for patterns, not just problems.

What I found was that users weren't rejecting Prime. They were confused by it. The value wasn't landing at the right moment, and the commitment felt too large too early.

Rather than benchmarking travel competitors, who were all making similar mistakes, and looked at a completely different sector: food delivery. Uber One had solved a similar problem elegantly: a simple checkbox at checkout surfacing an instant, contextual saving. No separate page. No forced decision. Just a transparent offer at the right moment.

That cross-industry leap was the unlock. It showed that the solution didn't need to live within the conventions of travel booking. It needed to borrow from somewhere that had already figured out low-friction subscription acquisition.

Prime is a high-stakes touchpoint. The solution had to work across a complex matrix of user states. Getting it wrong for any of them would mean either missing an acquisition opportunity or creating a frustrating, confusing experience.

I mapped and designed for every relevant scenario: existing Prime members, users who had already used their free trial, users who were logged in vs not, users with price freedom vs without. Each state required a different approach: different messaging, different hierarchy, different CTA logic.

This was the hardest part of the work: not the concept itself, but making sure the concept held up across every edge case without becoming inconsistent or manipulative.

Because Prime acquisition is one of the most sensitive areas of the business, this proposal required buy-in at every level: product leads, design leadership, and C-level stakeholders. I presented multiple times, always grounding the direction in behavioural data and the benchmark rather than design preference.

The proposal was approved at every level and moved into A/B testing.

The final solution introduced two connected components: a persistent checkbox in the sticky checkout footer, and an expandable drawer surfacing Prime benefits in a timeline format: clear, honest, and non-intrusive.

I also proposed combining the guest and payment pages into a single checkout page, reducing friction and contributing to higher continuance through the funnel.

One of the things I valued most about this project was its impact beyond its own scope. Other teams and verticals started referencing or adapting parts of the solution.

The project completed A/B testing and delivered measurable results across both acquisition and engagement metrics. But the most lasting impact went beyond the numbers.

This kind of cross-team influence is hard to measure but easy to recognise. It happens when the thinking behind a solution is clear enough that others can pick it up, adapt it, and run with it independently. The proposal didn't just solve one problem. It changed how other teams thought about a whole category of problems.

eDreams offers a wide range of ancillary products throughout the booking journey: insurance, seat selection, bags, cars, and more. Each product had its own way of being displayed, often designed in isolation, without a shared structure or logic.

Every time a new product was added or an existing one changed, the team was essentially starting from scratch, reinventing the layout, the hierarchy, the interaction. The result was a funnel full of disconnected, inconsistent experiences that were hard to maintain and harder to scale.

The initial framing of the problem was visual: the displays looked different, had inconsistent sizes, and used different patterns. The natural instinct was to standardise the look and feel.

I reframed the challenge: instead of asking "how should these look?", I asked "what intent are we serving?" That shift opened up a completely different solution space, one based on purpose rather than appearance.

Once the question changed, the answer became much clearer: a modular system driven by shared intent across user needs, design goals, and business objectives.

Before defining any solution, I needed to understand the full scope of the problem. I audited how every ancillary product was currently displayed across the funnel, identifying inconsistencies, redundancies, and missed opportunities.

I then mapped all products by their typology, composition, needs, and value proposition. This was the hardest part of the work: finding a solution flexible enough to cover the most relevant scenarios without becoming so complex it would be impossible to maintain or too inconsistent for users to follow.

After exploring several approaches, I landed on three variants, each defined not by how they look, but by the intent they serve:

Each variant has defined UI weight, core elements, and optional elements, giving teams enough structure to be consistent, and enough flexibility to adapt to different products and moments.

One of the most important design decisions was making sure the system wasn't just a visual framework. I connected it to propensity models and user personas, so the right variant could be selected not just based on product type, but based on who the user is and how likely they are to engage.

This created the foundation for a personalised but familiar experience: users encounter different products in different ways, but the underlying logic feels consistent and coherent.

The final system defines three modular variants that any ancillary product can adapt to. Each product doesn't need to look identical across variants, but it must share the same intent.

I translated the concept into visual proposals, defined display and visibility rules, and created documentation to align the team and enable future teams to apply the system independently.

The system is currently being tested. Results are not yet available, but the goals are clear, and the value of the framework is already felt in how the team approaches new products.

Repricing happens when a hotel raises the price of a room between the moment a user selects it and the moment they reach checkout. It's a common and unavoidable part of the travel booking experience, but how it's communicated makes all the difference.

At eDreams, 4.8% of users in the Hotels funnel went through a repricing. The data was clear: the larger the price increase, the higher the drop-off. Users experiencing a repricing of more than 30% converted 18.2% less than those who didn't encounter one at all. Beyond conversion, repricing also risked pushing users to competitors and damaging long-term trust.

The existing experience showed no repricing communication at all. Users would simply arrive at the payment page and find a different price than expected. There was no explanation, no context, no choice. Just a surprise at the worst possible moment.

Before proposing any direction, I built a structured discovery document mapping what was known, what was unknown, and what was assumed. Working alongside the data team, I investigated three key questions: how many users drop off immediately after seeing a reprice? At what percentage increase do users abandon? And how much revenue is lost from reprice drop-offs compared to absorbing the cost?

The answers shaped every design decision that followed.

The data revealed that not all repricings are equal. A 0–5% increase, the most common scenario, had a much lower drop-off rate than larger ones. eDreams could absorb changes up to 2.3%, which covered a significant portion of cases. The real damage happened at higher percentages, especially for users booking further in advance, for longer stays, with higher booking values, or for groups.

This meant a single, one-size-fits-all repricing message was the wrong approach. The communication needed to adapt to the situation.

I designed a contextual communication system with distinct responses depending on the repricing scenario:

A key decision was where to surface the repricing message. After analysis, the guest page, not the payment page, proved to be the better moment: users hadn't yet committed their payment details, so the interruption felt less jarring and conversion held up better.

On desktop, the repricing appeared as a modal. On mobile, a drawer. Both included a price trend chart to contextualise the change, showing that price fluctuation is normal, and a "Go back to hotel's page" CTA, giving users real agency rather than a dead end.

The final solution covered three distinct scenarios: sold out, higher-value repricing (shown at the hotel details page), and lower-value repricing (shown at the payment page), each with its own communication logic, tone, and set of actions.

The design prioritised honesty and user control: showing the exact new price, explaining why it changed, giving users a clear choice, and never trapping them in a dead end. The price trend chart was a particularly considered detail: it reframed the repricing as a market reality rather than a platform problem.

Results were measured approximately July 2024, after the MVP rollout.

The Hotel Details Page is one of the most critical moments in the booking funnel. It's where users decide. But the existing page had grown organically, accumulating information and features without a coherent structure or a clear point of view on what it was trying to achieve.

Almost all hotel details pages in the industry look the same: the same sections, the same order, the same amount of information regardless of who's looking or what they need. A solo traveller booking for tomorrow night sees the same page as a family of four planning a week-long trip. That sameness was the real problem.

I started with research: user testing sessions, past usability data, and competitive benchmarking, to understand what was actually happening on the page. The findings confirmed what the data suggested: the page wasn't failing because of any single broken element. It was failing because it couldn't adapt.

If we know a user is searching for a stay for four people, two of whom are children, we should be surfacing child-friendly amenities prominently. If we know from past behaviour that they consistently stay in hotels with exceptional breakfast reviews, that should be highlighted. The page shouldn't just display information. It should prioritise the right information for the right person at the right moment.

Before any visual work, I ran a usability study with 15 participants to evaluate the existing page. Users generally found it informative and structured, but identified real friction points: Prime membership benefits were unclear, promotional discounts overshadowed key information, and pricing wasn't always legible. Was that per person or for the whole stay?

These weren't cosmetic issues. They were hierarchy problems. The page was saying too many things at the same volume.

Once I had a clear picture of the problems, I built an information model before touching any designs. The goal was to map every element that could appear on the page: room name, refund type, boarding type, price, availability, amenities, descriptions, and classify each one by type, relevance to the user, requirement (mandatory vs conditional), goal (functional vs marketing), and state (static vs dynamic).

This was essential because hotel data is messy: some hotels have certain information, others don't. Some details are always relevant, others only matter in specific contexts. The model gave me a shared language for making decisions about what to show, when, and why.

The proposal wasn't a redesign from zero to one. That would have been too risky and too slow. Instead, I designed a full future vision and then broke it into a modular delivery sequence that could be tested and shipped incrementally:

The final vision was a page that could adapt to the user rather than presenting the same experience to everyone. The same structure, but with content prioritised differently depending on who was looking: their search context, their booking history, their group composition.

A family of four with young children would see family-friendly amenities surfaced prominently. A user who consistently books hotels with high breakfast ratings would see that highlighted. The page would feel familiar. The structure doesn't change enough to disorient, but it works harder for each individual.

I also tested the final vision with 15 users. The response was positive: clear structure, easy to scan, well-received visual design. Key areas of confusion: Prime pricing, discount hierarchy, price per person vs total, were directly addressed in the new design.

Because the work was delivered modularly, there is no single consolidated metric for the full vision. Individual modules have shipped with measurable results. The full revamp continues to be implemented incrementally.

In July 2021, PicPay acquired GuiaBolso, one of Brazil's most well-known personal finance apps. GuiaBolso had over 6 million users and had been offering personalised financial management tools based on shared data even before Open Banking formally existed in Brazil.

I joined at the beginning of the integration process. There was no brief, no plan, no playbook. Just a newly acquired product, a team to lead, and the question: how do you take a full financial management app and bring it inside a completely different one, without losing what made it valuable?

The obvious challenge was technical: different brand, different structure, different logic. But the harder problem was the audience.

On top of that, Open Finance was brand new in Brazil. Getting users to connect their bank accounts from other institutions required building trust around something most people didn't understand yet. And every fintech in the country was racing to be first: whoever got users to link their accounts first would almost certainly keep them.

The whole company was watching. This product was PicPay's vehicle for winning the Open Finance race.

I led a team of three designers, working alongside researchers, content people, and a manager, across a product that touched every financial dimension of a user's life: payments, receipts, credit card bills, bank statements, and cross-bank account aggregation.

We started by questioning everything GuiaBolso had built. Some of it was right for GuiaBolso's users but wrong for PicPay's. The category system, for example, had grown bloated over time. We had to simplify it significantly without losing the granularity that made it useful. Every decision required holding two very different users in mind at the same time.

The consent flow for Open Finance was one of the most critical pieces of work. Users needed to understand what they were agreeing to, feel confident that their data was safe, and see immediate value in connecting their accounts. We had to design not just a flow, but the trust around it.

Tone of voice was another challenge that's easy to underestimate. GuiaBolso spoke to financially aware users. PicPay's audience was much broader. Everything, from error messages to empty states to onboarding copy, had to be rethought.

The vision we were designing toward was PicPay as the "Conta das Contas", an account of accounts, where users could see and manage all their financial relationships in one place, regardless of which banks they used. That was the north star.

The MVP alone was substantial. Financial management is not a simple product. Getting to something that was clear enough for a first-time user, complete enough for someone who had used GuiaBolso for years, and trustworthy enough for Open Finance to work, required sustained design thinking at every layer of the experience.

I left the company before the product launched. The foundation my team and I built carried through to the final release in October 2022, when "Minhas Finanças" went live for all PicPay users.