Centauro had a design team of almost 30 people and a set of design principles that hadn't taken hold. They existed in documentation, created through an earlier cross-functional workshop, but rarely showed up in design decisions, critiques, or team conversations. With the team about to double in size, that mattered: without a shared foundation, consistency and alignment would come down to informal communication.
Being part of the design team myself, I knew the problem first-hand, and took the initiative to look into it. To find out why the existing principles weren't being used, rather than assume, I ran a workshop with the whole team, together with one of the content designers.
We found that the problem wasn't that people didn't care about principles. It was that the principles gave them nothing to hold onto. They weren't memorable, so designers had to look them up to recall them. They weren't applicable, so it wasn't clear how to connect them to daily decisions. And they were too broad: they tried to say everything and ended up directing nothing.
The problem wasn't the people. It was the principles themselves.
With that, the content designer and I designed a workshop built to take the team from understanding to ownership. It started from the basics, what design principles are and what they are for, then asked each designer to propose what they thought a good principle could be. Working together, we looked for the ideas that kept recurring. And because the old principles had failed by being too abstract, we ended by applying the new ones to a real Centauro page, to test whether they held up in an actual decision.
That last step revealed something. What the team had produced weren't principles yet, they were three broad concepts with a cluster of values under each. Rather than force them into shape, we added a refinement stage: writing and rewriting short sentences, testing wordings, comparing what different people understood from the same line.
Language turned out to be the hardest part of the work.
The final output was three design principles, each with a short, memorable statement and a set of concrete examples written by the team:
The principles were embedded into Figma templates, team pages, and critique documentation, bringing them into the places where design decisions actually happen.
The goal was never just to produce better principles. It was to give a growing team a shared way of making decisions, so that alignment didn't depend on whoever happened to be in the room. The principles were the output. The decision-making culture was the point.
Prime is eDreams' membership programme, and its growth is one of the metrics the business follows most closely. The acquisition flow belonged to another team, but given how much it mattered to the business, I kept an eye on it regardless.
Looking at the acquisition funnel, its user behaviour, and the existing data and research, I saw room to improve Prime attachment and continuance rate.
The next step could have been to improve the existing Prime page: better layout, clearer copy, stronger visuals. But that work belonged to the Prime vertical, and they were already on it. With the most direct fix in good hands, I took it as a chance to question the setup a level deeper.
The acquisition funnel worked in three stages: the booking funnel, then the Prime step, then back into booking. Users moved from their booking into a decision about Prime, then back again to finish it.
A few patterns in the behaviour stood out, and they pointed in two directions. Users seemed to still be making sense of Prime as they went, and they tended to continue mainly because they wanted to get back to the booking, the thing they had actually come to do. That moved the question away from the page itself.
That question sent me looking for references. Competitors had all landed on more or less the same approach, so I looked outside the industry instead. Food delivery offered a useful parallel: a checkbox at checkout that surfaces an instant saving in context. No separate page, no forced decision, just a transparent offer at the right moment. It matched the question I was asking.
The idea looked simple, a checkbox, but the details were not. Unlike a food order, a flight or a hotel is a much larger purchase, so the decision carries more weight and leaves less room for friction. On top of that, Prime had to work across a wide range of user states: existing members, expired members, users eligible for a trial, users who had already declined. Each one carried a different risk, a missed acquisition or a frustrating moment for someone already paying.
The other challenge was getting it approved. Prime acquisition touches the most sensitive part of the business, so the proposal had to be made several times, at every level, grounded in data and user testing.
The solution came down to two connected components: a checkbox in the sticky checkout footer, and a drawer that opens on interaction to explain what Prime is, what it includes, and how it works. That let users subscribe without interrupting the booking, with the relevant information arriving at the moment it was useful.
After testing and approval, something I hadn't planned for happened. Other teams began adapting the pattern to their own acquisition moments, some taking the mechanic, some the drawer, some the underlying logic, and building their own ideas from it.
eDreams offers a wide range of ancillary products throughout the booking journey: insurance, seat selection, bags, cars, and more. They were built at different moments and for different needs, without a shared structure to hold them together. Over time they had drifted apart, which made the system harder to maintain and harder to scale.
That drift showed up as a real inconsistency problem. The first instinct was a modular system, one that could adapt to each product while giving them a shared framework. It was also the natural place to start: we were working toward a more personalised funnel at the same time, and a modular system looked like a way to serve both goals at once.
Together with the team, I audited all 12 ancillary products across the funnel, mapping each by typology, composition, needs, and value proposition. The goal was to find a system that could adapt instead of being rebuilt every time. The question was what it should adapt to.
We tested several ways to organise it: size, visual weight, content similarity, business priority. Each one broke down for the same reason: it solved for a single dimension and left out the rest. That is when we noticed that visual inconsistency was not the main problem.
The answer was a modular system driven by shared intent across user, design, and business goals. Each component supports what people need, what the experience aims to communicate, and what the business seeks to achieve.
Rather than choosing what to show based on a single factor, the system weighs all three together. The final piece was tying that to the user's level of attention: how much someone has to take in and decide at that point in the journey.
The result is a modular system with three levels of attention:
Beyond the shared intent, each variant has a defined UI weight, core elements, and optional elements: enough structure to stay familiar, enough flexibility to adapt.
The system works in two directions: it surfaces the right product for the right user at the right moment, and it gives designers a way to decide which component to build, based on intent and business need.
The most lasting outcome so far is harder to measure. "Deep Dive", "Spotlight", and "Teaser" became shorthand across design and product teams, a shared vocabulary for talking about intent before talking about execution. When a PM says "this should be a Teaser", everyone knows what that means.
Repricing happens when a hotel raises the price of a room between the moment a user selects it and the moment they reach checkout. A meaningful portion of users in the Hotels funnel went through a repricing at some point. The data was clear: the larger the price increase, the higher the drop-off. Repricings were hurting conversion in the short term and risking trust in the long term.
Reducing drop-offs was the obvious goal. But the data showed what was happening, not why. To understand the why, I looked at the actual experience.
The existing flow showed no repricing communication at all. Users would arrive at the payment page and find a different price than the one they'd selected. No explanation, no context, no choice. A surprise at the worst possible moment, right as they were about to pay.
Seen that way, the problem changed shape. People weren't abandoning because the price went up. They were abandoning because it went up with no warning, at the moment they were most committed.
So the goal wasn't to soften the increase or bury it. It was to give people enough context to understand it: where the price came from, why it changed, and what their options were.
The data showed that users didn't respond to every repricing the same way, and the difference came from a combination of factors rather than any one of them: how large the increase was, the value of the booking, how far ahead it was made, how long the stay was, and whether the person was travelling alone or with others.
The why was the interesting part. Someone booking at the last minute barely reacted: a price moving the day before a stay seemed to be expected, and if anything it pushed them to book before it moved again. A small increase on a low-value booking rarely landed either. The damage concentrated in the opposite case, a larger increase on a bigger booking, made well in advance, for a longer stay, and it hit hardest when the person was travelling with others, because then accepting it was no longer a decision they could make on their own.
That showed where the real risk sat, and the response took three forms depending on the situation.
Each response had its own logic, tone, and set of actions. Testing pointed to the guest page, not the payment page, as the better place to surface them, before users had committed their payment details.
Under all three ran the same idea: inform the user in the right way at the right moment, so a price change read as part of how the market works rather than a trick.
The Hotel Details Page is one of the most important moments in the booking experience. It's where users find everything they need to start deciding: whether the place suits their needs, fits their budget, sits in the right location, how it compares with the other options. By the time they reach this page, the searching is mostly done, and the deciding begins.
I was responsible for this page, so I knew where it could be tightened: how information was displayed, the visuals, the hierarchy. But those were fixes. Given how much this page matters, for the user and for the business, it was worth stepping back to improve the decision at a deeper level instead of just the visual surface.
After analysing the funnel, talking to users, and digging into past research, I understood something about what the page is really for.
This page isn't where users search for a hotel. It's where they start imagining themselves there.
Which means it shouldn't just display information. It should help them picture it: surfacing what matters to this person, at this moment. A family with young children should see child-friendly amenities first. Someone who consistently books hotels with high breakfast ratings should see that highlighted. The page working for who's looking, so the decision feels less like a comparison and more like a choice already taking shape.
If the page should adapt to the person rather than just display information, then the question I had to answer should be a different one.
Before touching any design, I built an information model: every element that could appear on the page, classified by type, relevance, requirement, goal, and state. It gave me an exact picture of the information available, so the proposal stayed feasible and technically grounded rather than idealised. It also showed what should be common across every Hotel Details Page and what should be contextual, and that separation became the backbone of the design.
A common structure underneath every Hotel Details Page, then adaptation on top of it: to the information each hotel actually provides, and to what is most relevant for the person looking, based on their past behaviour, their preferences, and the search they had just made.
From there I designed a full vision of where the page could go, then made it approachable and measurable for the team by breaking it into a delivery sequence ordered by impact and effort.
Typography and spacing came first, low effort, and already easing the cluttered feeling that had come up in research. The gallery came second, the most emotionally significant part of the page, where imagining yourself there actually happens. Then section by section, each improvement shipping and validated on its own.
The result is a page that adapts to the person instead of showing everyone the same thing. It stays familiar, but works harder for each user, so their decision takes less effort to feel right.
When I joined PicPay, a major Brazilian fintech, it had just acquired GuiaBolso, a financial management app that let people connect their accounts and see their whole financial life in one place.
My role was to bring GuiaBolso inside PicPay's app. There was no brief and no playbook, just a newly acquired product, a team to lead, and the question of how to fit a full financial management app into a very different one without losing what made it valuable.
The obvious challenge was technical: different brand, different structure, different logic. The harder one was the audience. GuiaBolso's users had gone looking for a tool to manage their money and were comfortable with its depth. PicPay's users had come to pay and bank. The product's depth and vocabulary were familiar to one and foreign to the other.
There was a second challenge, and it came from the business. Open Finance, a way of sharing financial data across banks and apps, was just starting in Brazil, and every fintech was racing to be the first to get users to link their accounts. Whoever got there first would most likely keep them, since few people connect their accounts twice. Our product needed those linked accounts to work at all, so inside the company it was expected to be the thing that drove people to connect them.
So the goal was clear: build something simple enough for a first-time user, complete enough for a GuiaBolso veteran, and trustworthy enough for Open Finance to work.
To answer that, I led a team of three designers, working alongside researchers, content designers, and a manager. We began by auditing everything GuiaBolso had built. Some of it was right for GuiaBolso's users but wrong for PicPay's.
The category system had grown bloated, so we simplified it without losing granularity: keeping the categories most used in GuiaBolso, combining them with the most common PicPay transaction types, and letting users create their own on top.
Tone of voice carried its own weight. GuiaBolso spoke to financially fluent users; PicPay's audience was far broader, so everything from error messages to onboarding had to be rethought.
The Open Finance consent flow was the most critical piece. People had to understand what they were agreeing to, trust that their data was safe, and see a reason to connect their accounts at all. That was when we understood something crucial:
The product's value had to be visible before we asked for the data. Commitment came after understanding, not before.
So instead of asking for the connection up front, we showed the product first, filled with sample data, so people could see what they'd get in return before sharing anything.
Each of these choices pointed the same way: making a serious financial tool feel approachable to someone who had never reached for one.
We were building more than a tool for tracking money. For many of PicPay's users, it could be a first real way into understanding their finances, and we believed a better relationship with money could change far more than a budget. That was what the MVP was aiming at: not just value on day one, but a first step toward financial education.
I'm Livia, born in Brazil, based in Florence. Currently working as a Principal Product Designer at eDreams.
I started my career as the only designer at a small startup, responsible for everything from the product to the brand itself. Since then I've moved gradually from designing individual experiences to shaping the systems, teams, and decisions that surround them.
What's stayed constant is my curiosity. I've always been more interested in how things connect than in jumping to solutions, looking beyond the immediate problem to the context around it: what's driving it, what we're assuming, where it fits. Over time that's pulled my work into the space between teams, products, and decisions, helping people make sense of complexity and building the conditions for good design to happen.
I believe good design is intentional and contextual. Patterns and best practices are useful, but only when they serve the situation. I'd rather understand what makes a problem unique than reach for a solution that worked somewhere else.
Craft matters. The thinking behind it matters more.
Outside of work, you'll usually find me reading, baking, drawing, or going for a walk.