A UX Case Study Told From the Client, Team, and User Perspective
The final product only shows where the team landed. It doesn’t show the questions the client was trying to answer, the decisions the design team had to make, or the moments where user needs changed the direction entirely. This UX case study looks at the journey from problem to product through three perspectives: the client, the Pepperplane team, and the people who ultimately use the product.
A polished product can make the path to the solution look almost too straightforward. The interface is clear, the workflows make sense, and the final product feels considered. From the outside, it can look as though the team simply understood the problem, designed the right solution, and moved neatly into development. That’s rarely how it happens.
Behind every shipped product are different people looking at the same problem from very different angles. The client is thinking about business goals, timelines, priorities, and whether the investment will create the outcome they need. The design team is trying to understand the problem deeply enough to make good decisions. The end user, meanwhile, is simply trying to accomplish something without having to think too hard about the product at all. The interesting part of UX is what happens when those perspectives come together.
“The final design shows you where we landed. The interesting part is how we got there.”
The Client POV: “We Know Something Needs to Change”
Most projects begin before anyone knows exactly what the solution should be. From the client’s perspective, there is usually a reason the conversation has started. Perhaps users are struggling with an existing workflow, the product has grown quickly and the experience hasn’t kept up, or a new feature needs to be introduced but the team isn’t completely sure how it should fit into what already exists. The client often knows where the pressure is coming from, but that doesn’t necessarily mean the solution is obvious.
That’s why our first conversations aren’t about jumping straight into screens. We want to understand what’s happening behind the brief. What is the business trying to achieve? What is currently creating friction? What have clients, users, or internal teams already been saying? What does success actually look like if the project works? For the client, this stage creates something important before a single interface is designed: clarity. Instead of immediately committing to a solution, the team begins building a shared understanding of the problem.
The Pepperplane POV: “Before We Design, We Need to Understand”
From our side, the temptation to start designing is always there because putting something on a screen feels productive. But if we don’t understand the problem properly, we’re just designing faster in the wrong direction.
Depending on the project, we may begin with stakeholder conversations, user interviews, workshops, reviews of the existing product, journey mapping, user story mapping, or user flows. Each activity helps us understand something different about the experience. Stakeholder conversations give us business context. User research helps us understand how people actually behave. Journey maps show us where friction appears across the broader experience. User story maps help the team align around what people need to accomplish, while user flows make decisions, paths, and edge cases visible before we start worrying about visual detail.
This is the part of UX that often disappears from the final case study, but it shapes everything that follows. We’re not collecting artifacts because a UX process says we should. We’re using them to answer questions. Who are we designing for? What are they trying to do? Where is the experience breaking down? Which assumptions are we treating as facts? What should we solve now, and what can wait? By the time we begin sketching, we want the team to have a much stronger answer to those questions than we did at the beginning.
The User POV: “I Just Need This to Work”
The end user sees the product very differently. They don’t know about the project brief, the workshop, or the internal debate over priorities. They don’t care how many versions existed in Figma. They simply arrive with something they’re trying to accomplish, and that’s what makes user research so important.
A workflow that makes perfect sense internally may feel completely different to the person using it. Users may have developed workarounds the product team has never seen. They may describe a frustration differently from how the business understands it. Something everyone assumed was an important feature may barely matter, while a seemingly minor point of friction may affect the user every day. Those moments can change the direction of the work.
The goal isn’t to ask users to design the solution for us. It’s to understand their experience well enough that we’re not designing based entirely on what the team assumes they need. When that user perspective enters the conversation early, product decisions become more grounded.
Where the Three Perspectives Start to Align
This is usually where the project becomes interesting. The client brings the business goal, the user brings the reality of the experience, and Pepperplane helps connect the two. Sometimes everything aligns quickly. The problem the client identified is exactly what users are struggling with, and the direction becomes clearer. Other times, there’s tension.
The business may want to introduce more functionality while research shows users are already overwhelmed. A stakeholder may believe a particular workflow is essential, while user interviews reveal that people avoid it whenever possible. A solution that appears simple from a product perspective may become much more complex once developers explain how the system actually behaves. UX isn’t about choosing one perspective and ignoring the others. It’s about finding a solution that makes sense across all of them, and that’s where a lot of the real decision-making happens.
The First Design Gives Everyone Something to React To
Once we’ve built enough understanding, we can begin turning that thinking into something visible. The first design is rarely polished. It might be a rough sketch, a wireframe, or an early flow that helps us test whether the direction makes sense.
For the client, this is often the first time the product idea feels tangible. For the design team, it’s an opportunity to see whether the research and mapping translate into a coherent experience. For users, when testing is involved, it becomes something they can actually respond to rather than something they have to imagine. This is why we don’t expect the first version to be right. Its job is to create a better conversation.
Once people can see and interact with something, questions become more specific, gaps become easier to identify, and feedback becomes more useful because everyone is responding to the same thing.
Feedback Changes the Product, but Not Always in the Way You Expect
One of the most useful things about collaborative product design is that feedback comes from different directions. A Design Review may uncover an assumption we haven’t challenged. A stakeholder may point out a business requirement that changes part of the flow. A developer might identify a technical consideration that affects the interaction. User feedback may reveal that something we thought was obvious is actually confusing.
These moments don’t mean the process is going off track. They’re the process working. The important thing is that every change has a reason. We’re not revising the design simply because someone wants a different version. We’re responding to new information that helps us make a better decision. That distinction matters because iteration should reduce uncertainty, not create endless rounds of preference-based feedback.
The Developer POV: “Here’s What Happens When This Becomes Real”
There’s another perspective that becomes increasingly important as the product moves toward implementation: development. A design can appear complete in Figma and still raise practical questions once it meets real data, technical constraints, permissions, performance, and system behavior.
What happens if the request fails? What if the user has a different account type? What happens when there’s no data? Can someone enter this flow from somewhere we haven’t considered? Developer questions often reveal UX gaps because they force the product to move beyond the ideal path.
At Pepperplane, we don’t see that as a handoff problem. It’s part of the design process. Designers and developers work through those scenarios together. Sometimes the design changes. Sometimes the developer finds a better way to support the original intent. Sometimes both sides realise there’s a simpler solution neither had considered initially. That collaboration helps close the gap between what was designed and what ultimately gets shipped.
The Client POV: “Now We Understand Why This Is the Solution”
One of the biggest differences between a purely execution-led project and a strategic UX process is how decisions feel to the client. Instead of receiving a finished design and being asked whether they like it, the client has seen the thinking evolve.
They understand what came from research. They’ve seen where assumptions changed. They know why a workflow was simplified, why something was deprioritized, or why a particular decision supports both users and the business. That context changes the conversation. Approval becomes less about subjective preference and more about whether the solution supports the goals everyone agreed on.
For clients, that creates confidence. Not because every decision is perfect, but because there is clear reasoning behind it.
The User POV: “It Just Makes Sense”
The user never sees most of this, and ideally, they shouldn’t need to. They won’t know about the stakeholder workshop that clarified the priority. They won’t see the discarded flow that exposed an edge case. They won’t hear the developer question that changed an interaction or the Design Review that simplified a decision.
They’ll simply experience the result. A workflow feels easier. The right information appears at the right moment. The product behaves the way they expect. They accomplish what they came to do without having to understand all the thinking that made it possible.
That’s one of the strange things about good UX. The more thinking that happens behind the experience, the less thinking the user may need to do while using it.
What This Looks Like at Pepperplane
At Pepperplane, we see the journey from problem to product as a shared process rather than a sequence of isolated deliverables. Clients bring context about the business and what success needs to look like. Users bring the reality of how the product fits into their lives and workflows. Developers bring technical knowledge about how the experience can work in practice. Our role is to connect those perspectives and help the team turn them into thoughtful product decisions.
That can involve research, workshops, journey maps, story maps, user flows, early concepts, Design Reviews, prototyping, and ongoing collaboration with development. The exact mix changes from project to project because the process should serve the problem, not the other way around.
What remains consistent is the goal: create enough shared understanding that the team can move from assumptions to confident decisions.
Final Thought
The final product is only one perspective on the project. It shows where the team landed, but it doesn’t show the client trying to balance user needs with business goals, the designers working through competing possibilities, the developers exposing scenarios that weren’t obvious in the prototype, or the users whose frustrations ultimately shaped the experience.
Those perspectives are the story behind the solution. They’re what turned an initial problem into something the team could understand, design, build, and eventually place in front of real users.
The final design shows you where we landed. The interesting part is how everyone helped us get there.
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.
