Same Product. Four Very Different Stages.
A finished product rarely looks exactly like the idea that started it. Before the first rough sketch, there are already conversations, workshops, journey maps, user story maps, and user flows shaping what the team understands about the problem. From there, the design continues evolving through wireframes, feedback, visual design, and implementation. Looking at those stages side by side tells a much more interesting story than the final UI alone because it shows how product decisions actually develop over time.
There’s something satisfying about putting the first rough sketch of a feature next to the version that eventually shipped. Sometimes you can immediately see the connection. The basic idea survived, the structure feels familiar, and you can trace pieces of the original thinking all the way through to the finished product. Other times, you look at the two and wonder how one possibly became the other. Both are completely normal.
What that comparison doesn’t always show, however, is that the sketch wasn’t really the beginning. By the time we start drawing even a rough version of a feature, the team has often already spent time understanding the business problem, talking with stakeholders and users, mapping journeys, identifying key user stories, and working through how someone might move through the experience. The sketch is simply the first time some of that thinking becomes visible on a screen or page.
From there, wireframes help us work through structure and interaction in more detail, feedback introduces perspectives we hadn’t considered, UI design brings greater clarity and consistency to the experience, and collaboration with developers continues shaping what ultimately gets shipped. The interesting part isn’t simply seeing where we ended up. It’s understanding what happened before the sketch, what changed after it, and why.
“Same product. Four very different stages. And a lot of thinking before stage one.”
Before Stage One: Figuring Out What We’re Actually Designing
Before we sketch anything, we need to understand what the product or feature is actually trying to accomplish. That usually means spending time with the people closest to the problem and building a shared picture of the experience before we begin proposing solutions.
Depending on the project, that can include stakeholder interviews, user interviews, collaborative workshops, reviews of the existing product, and conversations with developers or product leads. Each of these helps us understand the business goals, user needs, existing constraints, and assumptions that may still need to be challenged.
This part of the process matters because a feature request rarely tells the whole story. A client may ask for a new dashboard, workflow, or piece of functionality, but before designing it, we want to understand why it’s needed, who will use it, what problem it should solve, and how it fits into the rest of the product. That context becomes the foundation for everything that follows.
User Story Mapping Creates a Shared View of the Work
Once we understand more about the problem, user story mapping can help the team see the product from the user’s perspective rather than as a collection of separate features.
A user story map helps us identify what someone is trying to accomplish, the activities involved, and the steps that support those activities. It gives product, design, development, and stakeholders a shared view of the experience before anyone becomes too attached to individual screens.
This is often where assumptions begin to surface. Two people may have been talking about the same feature while imagining completely different workflows. A story map makes those differences visible and gives the team an opportunity to resolve them before they become part of the design.
It also helps clarify priorities. Instead of asking which features sound most important, the team can start looking at which parts of the experience are essential for users to achieve their goals and which can be introduced later.
User Journey Maps Add the Wider Context
User story maps help us understand what people need to do. User journey maps help us understand what that experience is like from their perspective.
They can capture the broader journey around the product, including what happens before someone enters a particular workflow, what they’re trying to accomplish, where frustrations occur, and what they may be thinking or feeling at different moments.
That wider context is useful because software rarely exists in isolation. A frustrating part of the experience may not be caused by the interface itself. It could come from missing information, an internal process, a handoff between teams, or something users need to do outside the product.
Journey mapping helps us see those connections before we start solving the problem at screen level. It gives us a stronger understanding of where design can create the most value and where a visual change alone may not be enough.
User Flows Turn Understanding Into Structure
Once the team has a clearer picture of the user, the journey, and the priorities, we can start thinking more specifically about how someone will move through the product.
User flows help map the sequence of actions, decisions, and outcomes involved in completing a task. They show where a user enters the experience, what choices they make, what happens next, and where alternate paths or edge cases might appear.
This is often the point where an idea that sounded very simple begins revealing more complexity. A single sentence in a requirement might turn into several decisions once we consider different user types, permissions, errors, or alternate scenarios.
Working through those flows before sketching gives us a much stronger starting point. We’re no longer drawing screens based on a vague feature description. We’re visualising an experience the team has already thought through together.
Stage One: The Rough Sketch
By the time we reach the first sketch, quite a lot of design thinking has already happened.
The sketch takes what we’ve learned from interviews, workshops, story maps, journey maps, and user flows and begins translating it into something more tangible. It might be a few boxes on paper, a whiteboard drawing, or an intentionally rough digital concept.
At this point, we’re still not particularly concerned with whether it looks good. We’re testing structure. What information belongs together? What does the user need at this moment? Does the sequence make sense? Is there an obvious next step? Are we introducing complexity that the earlier mapping suggested we could avoid?
Keeping the sketch rough is useful because the direction is still easy to challenge. If something doesn’t work, we can change it without feeling like we’ve lost a large amount of effort. The sketch gives the team something concrete enough to react to while still leaving plenty of room to rethink the solution.
Stage Two: What Changes During Wireframing
Once we begin wireframing, the idea has to become more specific. A box labelled “account information” suddenly needs actual content. A simple arrow between two steps becomes a workflow with decisions, alternate paths, validations, and edge cases. Things that seemed straightforward during mapping often reveal new questions once we ask how someone would actually interact with them on screen.
This is where we begin making more deliberate decisions about hierarchy, navigation, content, and interaction. We may discover that users need information earlier than expected, that a workflow contains unnecessary steps, or that two ideas that looked separate actually belong together.
The wireframe is still intentionally simple, but the thinking behind it becomes much more detailed. We’re no longer asking only whether the idea sounds reasonable. We’re starting to see whether the experience actually works when someone has to move through it.
Stage Three: Feedback Changes the Direction
By the time a feature reaches wireframes, more people can react to something concrete. That’s when some of the most useful conversations begin.
A stakeholder may point out a business requirement that wasn’t obvious during the initial discussion. A developer might identify a technical consideration that affects the interaction. Another designer may question whether the hierarchy makes sense. User feedback might reveal that something we thought was intuitive isn’t nearly as obvious as we assumed.
Not every piece of feedback results in a change, but each perspective gives us another opportunity to evaluate the direction. The important thing is understanding the reason behind the feedback rather than treating design review as a checklist of requested revisions.
Sometimes one question changes a small interaction. Sometimes it changes the entire flow. That’s part of why we show work before it’s polished. We want those conversations to happen while the design is still flexible enough to respond to them.
Stage Four: The UI Starts Looking Finished
Once the structure and major interactions are working, the interface begins looking much more like the product people eventually recognise.
Typography, spacing, colour, components, states, content, and interaction details bring clarity and consistency to the experience. A design system may help connect the new feature with the rest of the product, while prototypes allow us to understand how interactions feel rather than simply how individual screens look.
This is usually the stage that gets the most attention because it’s visually satisfying. It’s also the stage most likely to appear in a portfolio or presentation.
But when you place that polished interface beside the discovery work, rough sketch, and wireframe, you can see that visual design isn’t where the thinking suddenly began. It’s where a lot of earlier thinking became visible.
What Actually Survives From the First Idea?
One of the most interesting parts of comparing these stages is seeing what didn’t change.
Sometimes the central idea behind an early sketch survives almost untouched because it genuinely worked. Perhaps the overall sequence was right from the beginning, or a particular interaction continued making sense as the team learned more.
Other elements may disappear entirely. A step we initially thought was necessary gets removed. Information moves somewhere else. A feature becomes simpler. An interaction changes because user feedback reveals a better approach.
Iteration doesn’t mean changing everything for the sake of it. The goal is to preserve what works and improve what doesn’t. Looking at the stages together makes that distinction much easier to see.
And Then the Product Gets Built
Even a polished Figma file isn’t the end of the story. Once development begins, the design meets real systems, real data, technical constraints, and all the small scenarios that are difficult to capture perfectly in a prototype. Designers and developers continue talking through questions, reviewing implementation, and making adjustments where needed.
This is why we like including the shipped product when we look back at the evolution of a feature. It closes the loop. You can see where the thinking started, how discovery and mapping shaped the direction, how design refined it, and what ultimately became real for the user.
Sometimes the shipped experience matches the final design almost exactly. Other times, there are small differences that reflect decisions made during implementation. Those differences are part of the story too.
The Process Isn’t Really a Perfect Sequence
Putting Discovery → Sketch → Wireframe → UI → Shipped Product into a neat sequence makes the process wonderfully easy to understand. Actual product design is rarely quite that tidy.
Research may send us back to rethink part of the journey. A user flow may need to change after a workshop. Developer feedback may cause us to reconsider an interaction we thought was settled. User testing may send part of the experience back into exploration, and business requirements may evolve while development is already underway.
The stages are useful for understanding how an idea matures, but good UX isn’t about following a perfectly linear process. It’s about continuing to learn and being willing to adjust the work when new information gives us a reason to.
The destination matters more than pretending we got there in a straight line.
What This Looks Like at Pepperplane
At Pepperplane, we like looking back at these progressions because they show something a finished interface can’t. They show the decisions.
You can see where an interview changed our understanding of the problem, where a story map aligned the team, where a journey map exposed friction, where a user flow revealed complexity, where feedback simplified an interaction, and where collaboration with development influenced the shipped experience.
That’s also why we don’t think of workshops, maps, early sketches, or wireframes as disposable work simply because users will never see them. Each artifact helps the team understand something and gives us a stronger foundation for the next decision.
The finished product is the outcome, but the evolution is where much of the design actually happened.
Final Thought
A finished product rarely shows you how many questions, conversations, and changed minds it took to get there. By the time something ships, much of that thinking has disappeared into the experience itself.
And maybe that’s the point. Good UX isn’t about getting the first idea right. It’s about giving an idea enough room to be questioned, tested, challenged, and improved.
Some early thinking will make it all the way through. Some won’t. What matters is that every stage helps the team understand the problem and the product a little better.
The final screen shows where we landed. The journey there shows how we learned what was worth building.
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.