Different products, different teams, and a few lessons that keep following us
No two UX projects unfold exactly the same way. The users change, the business problems change, the technology changes, and every team brings its own way of working. But after working alongside product teams, developers, stakeholders, and users across different projects, some lessons have a habit of showing up again and again. These are a few of the things real projects continue to teach us about designing better products and working better together.
Different product. Different team. Somehow, some of the same lessons keep showing up. That’s one of the interesting things about working across different UX projects. You can begin with a completely new product, a different set of users, a new development team, and a business challenge you haven’t encountered before. The details change, and the solution certainly shouldn’t look the same, but somewhere along the way, a familiar lesson tends to surface.
Maybe the team realises an assumption everyone agreed on at the beginning wasn’t quite right. A developer asks a question that changes how we think about a flow. Something that looked simple in a workshop becomes surprisingly complicated once we map it properly. Or a user says something during research that shifts the conversation entirely.
Every project teaches us something new, but the best lessons rarely stay within a single project. They influence the questions we ask next time, when we involve different people, how early we share work, and how we approach uncertainty when we inevitably encounter it again. These are some of the lessons the work keeps teaching us.
Lesson 1: The earlier we create alignment, the less we have to untangle later
It’s easy to begin a project believing everyone understands the problem in roughly the same way. The brief has been discussed, requirements exist, and the team knows what needs to be designed. Then you start asking questions and realise that “roughly the same way” can hide quite a few different interpretations.
One stakeholder may be thinking about a business goal while another is focused on a particular feature. The product team may have one understanding of the user journey while development has another. Everyone can be using the same words without necessarily meaning the same thing.
We’ve learned that early alignment isn’t about getting everyone to agree on every detail. It’s about making different assumptions visible before they become design or development decisions. Workshops, user story maps, journey maps, flows, and even a good conversation around a shared screen can give the team something concrete to react to.
The earlier those differences surface, the easier they are to work through. Waiting until there’s a polished interface to discover them is usually a much more expensive conversation.
Lesson 2: The first version is supposed to teach us something
There’s a natural temptation to want the first design to be right. We’ve felt it too. You’ve done the research, mapped the problem, and spent time thinking through the solution, so surely the first direction should be pretty close. Sometimes it is. Sometimes it absolutely isn’t.
Real projects keep reminding us that the first version is valuable because it gives everyone something tangible to question, test, and improve. Once an idea exists outside someone’s head, stakeholders can respond to it, users can interact with it, developers can challenge it, and designers can see problems that weren’t obvious when the idea was still conceptual.
That means changing a design isn’t necessarily evidence that the first attempt failed. Sometimes its job was to help the team discover what the next version needed to become.
We’ve learned to become less precious about being right immediately and more interested in what each iteration can teach us.
Lesson 3: Users don’t always tell us what we expected to hear
Research has a useful habit of making a project slightly uncomfortable. A team can spend months thinking about a product and develop very reasonable assumptions about how people use it, what matters most, and where the problems are. Then you speak to the people actually using it and discover that their priorities are slightly different.
Sometimes the feature everyone thought was important barely comes up. Sometimes users have invented a workaround nobody on the product team knew existed. They might describe something using completely different language, or struggle with a part of the experience everyone internally assumed was straightforward.
Those moments are valuable because user research isn’t there to confirm what we already believe. It’s there to improve our understanding of the problem.
The lesson we keep taking forward is to leave room to be surprised. If every research conversation confirms exactly what we expected, we probably haven’t been curious enough.
Lesson 4: Developers belong in the conversation earlier than the handoff
Some of the most useful design questions we’ve encountered haven’t come from designers. A developer might ask what happens when data doesn’t load, how a particular interaction should behave under a different condition, whether the proposed flow fits the way the system actually works, or what happens when the user does something nobody accounted for. These conversations can reveal missing states, overlooked edge cases, and sometimes a simpler way to solve the problem entirely.
That’s why one lesson has become increasingly important in the way we work: developer collaboration works best when it happens during the design process, not after it.
The handoff becomes much less dramatic when development already understands the thinking behind the design and designers understand the realities of implementation. Instead of throwing finished screens over an imaginary wall and hoping everything translates, both sides have helped shape what eventually gets built.
Lesson 5: The Smallest Decisions Can Hide the Biggest Questions
Some decisions look almost comically simple when you see the final interface. It’s just a button. A label. A confirmation message. A small interaction between two screens. Surely that couldn’t have required much discussion. And then someone asks, “What happens if…?”
Suddenly that tiny decision touches permissions, data, user expectations, technical behaviour, another part of the workflow, and three edge cases nobody had considered five minutes earlier.
Real projects repeatedly remind us that the size of something on the screen has very little to do with the size of the decision behind it.
We’ve learned not to dismiss those conversations simply because the UI element looks small. Sometimes spending longer on a tiny interaction is exactly what prevents users and developers from dealing with a much bigger problem later.
Lesson 6: More Isn’t Always the Answer
When a problem appears in a product, adding something can feel like the natural response. Another feature. Another option. Another screen. Another piece of information to make things clearer. But some of the strongest decisions we’ve seen on projects have involved removing something instead.
Research might show that a planned feature doesn’t address the real problem. Mapping a workflow can reveal steps that don’t need to exist. Two similar ideas might be combined into one clearer experience. Sometimes the team simply needs to communicate something better rather than build something new.
Good UX isn’t measured by how much design we produce. It’s measured by whether we’re helping solve the right problem. That’s a lesson worth remembering, particularly when everyone is excited to start building.
Lesson 7: Showing Unfinished Work Usually Makes the Finished Work Better
There can be a strange moment in a design project where something is clear enough to discuss but not polished enough to feel comfortable sharing. We’ve learned that this is often exactly when it should be shared.
When people see work while there’s still room to change it, feedback becomes part of shaping the solution rather than approving something that already feels finished. Assumptions surface earlier, questions are easier to explore, and nobody has spent unnecessary time polishing a direction the team may ultimately change.
Design Reviews are especially useful here because the conversation can focus on why a decision works, what we might be missing, and whether it supports the user and product goals, rather than getting distracted by whether every visual detail is perfect.
Sharing earlier can feel messier, but it gives collaboration a chance to genuinely influence the work.
Lesson 8: Clarity Is Often the Thing That Makes Everything Else Move Faster
Speed matters on product teams. But one thing project after project has reinforced for us is that moving quickly and making progress aren’t necessarily the same thing.
A team can move incredibly quickly toward a solution and still lose time later if the problem wasn’t understood, requirements were interpreted differently, or important questions were left unanswered. The rework simply happens further down the road.
Spending time creating clarity can sometimes feel slower at the beginning. Mapping the flow, documenting a decision, asking another question, or bringing someone into a conversation takes time. But clarity has a way of giving that time back later.
Developers can build with more confidence. Stakeholders know what they’re reviewing. Designers make fewer decisions based on assumptions. Product teams spend less time reopening conversations everyone thought had already been resolved. The lesson isn’t “slow down.” It’s make sure the team knows where it’s going before asking everyone to move faster.
The Lessons Change the Way We Work
The useful thing about learning something on a project is being able to carry it into the next one. That doesn’t mean copying the same process from one client to another. Different teams need different things, and part of good UX work is knowing when to adapt. But experience changes what you notice. You recognise the moment when an assumption needs to be questioned. You know when development should be pulled into the conversation. You become more comfortable sharing something unfinished because you know the conversation will make it stronger.
Over time, lessons stop being things you write down after a project and start becoming part of how you approach the next one, and then the next project teaches you something else.
What This Looks Like at Pepperplane
At Pepperplane, we work alongside clients, product teams, developers, stakeholders, and users, which means every project gives us several different ways to learn.
Some lessons come from research. Others emerge during a workshop, a Design Review, or a conversation with development. Sometimes they come from an idea that worked beautifully. Sometimes, perhaps more memorably, they come from one that didn’t.
We try to carry those lessons forward without assuming that what worked for one product will automatically work for another. The goal isn’t to develop a perfect UX formula. It’s to keep getting better at asking the right questions, bringing the right people into the conversation, and recognising what each project is trying to teach us.
Final Thought
After enough projects, you start to recognise certain moments. The assumption that needs testing. The tiny interaction that deserves another conversation. The unfinished idea worth sharing. The developer question that might change the design. The user comment that makes everyone reconsider what they thought they knew.
The products may be different and the teams may change, but those moments continue to remind us of something important: good UX is as much about learning as it is about designing.
Every project leaves us with a finished piece of work, but it also leaves us with a slightly better understanding of how to approach the next one. And for us, that’s part of the value of doing the work in the first place. Different product. Different team. Somehow, some of the same lessons keep showing up.
Ready to Build Better Products Together?
Looking for a UX partner who can bring clarity to your next project? We’d love to chat.
Book a discovery call and let’s build something remarkable together.