Why Some of the Most Important UX Decisions Happen Before Figma
Before we start designing screens, we want to understand the world around them. That means talking with stakeholders and users, reviewing existing products and workflows, identifying where people are struggling, and questioning assumptions that may have shaped the original brief. This early discovery work gives the team something far more valuable than a head start on the interface. It gives us clarity about what we’re actually trying to solve.
There can be a lot of pressure at the beginning of a software project to start designing something. Everyone is excited about the idea, there are features to explore, timelines are already being discussed, and opening Figma can feel like progress. Once there are screens on the page, the project suddenly feels real. But some of the most important design work we do happens before there’s anything particularly visual to show.
Before we start thinking about layouts, components, or interactions, we want to understand the people who will use the product, the business behind it, and the environment the product needs to work within. We want to know what’s happening today, where people are getting frustrated, what stakeholders believe the problem is, and which of those beliefs still need to be validated. It isn’t always the most visible part of UX, but it shapes almost everything that comes after it.
“Sometimes the most important design decisions happen before anyone opens Figma.”
We Start by Listening to the People Closest to the Problem
Stakeholder conversations are often one of the first places we start because they give us context that a project brief alone rarely captures.
A brief might tell us that a team wants to improve onboarding, redesign a dashboard, or introduce a new feature. Talking with the people involved helps us understand why. Maybe customers are abandoning onboarding before they reach an important step. Maybe support teams are repeatedly answering the same questions. Maybe the business is preparing to serve a different type of customer and the existing product no longer supports that direction very well.
Different stakeholders also tend to see different parts of the problem. Leadership may be focused on growth, product teams on priorities, developers on technical realities, and customer-facing teams on the frustrations they hear every day. Bringing those perspectives together helps us understand the broader picture before narrowing in on a solution.
The goal at this stage isn’t to collect a list of requests. It’s to understand what people know, what they believe, and where there may still be unanswered questions.
Then We Talk to the People Actually Using the Product
Stakeholders know the business incredibly well, but they’re not always experiencing the product in the same way users are. That’s why user conversations can be so revealing.
What a team believes is frustrating may not be the thing users struggle with most. A feature everyone internally considers essential may barely register with customers, while a seemingly small inconvenience may be creating friction every single day.
User interviews help us understand the experience from the other side. We can hear how people describe their goals in their own words, where they hesitate, what workarounds they’ve created, and what they expected the product to do differently.
We’re not asking users to design the solution for us. We’re trying to understand their experience well enough that the decisions we make later are grounded in something more useful than our own assumptions.
We Look Closely at What's Already There
Discovery doesn’t always mean starting from zero.
When we’re working with an existing product, there’s usually a lot we can learn before proposing anything new. We review current workflows, screens, analytics or research when available, support feedback, and the ways users are already moving through the experience.
Sometimes the issue is obvious. Other times, the product works reasonably well until you follow a task from beginning to end and notice the small moments of friction accumulating along the way.
We also look beyond the interface itself. A frustrating experience may be caused by a workflow behind the product, a business rule, missing information, or a process that requires users to jump between systems. Redesigning a screen without understanding that context might make something look better without actually solving the problem.
Understanding what exists gives us a baseline. It helps us see what should be improved, what should be preserved, and what might not need changing at all.
We Look for Frustration, Not Just Feature Requests
One of the most useful shifts during discovery is moving from what people are asking for to why they’re asking for it.
Someone might request a new dashboard because they can’t find important information quickly enough. A client might ask for additional notifications because users are missing important steps. An internal team might request another filter because the existing workflow makes it difficult to find the right records.
The feature request is useful information, but the frustration underneath it is usually more interesting.
When we understand the underlying problem, we have more room to explore the right solution. Sometimes the requested feature is exactly what the product needs. Sometimes there’s a simpler answer. Occasionally, we discover that solving a different part of the experience removes the need for the requested feature altogether.
That distinction matters because good UX isn’t about finding elegant ways to add everything people request. It’s about understanding which problems are worth solving and finding the most useful way to solve them.
We Challenge Assumptions Before They Become Expensive
Every project begins with assumptions. That’s normal. The danger comes when assumptions quietly become requirements without anyone stopping to question them.
A team may assume users want a particular feature because several customers requested it. They may assume a workflow needs five steps because that’s how the internal process currently works. They may assume people understand certain terminology because everyone inside the company uses it every day.
Discovery gives us an opportunity to bring those assumptions into the open. We can ask what evidence supports them, whether we’ve heard the same thing from users, and what might happen if the assumption turns out to be wrong. This isn’t about challenging stakeholders for the sake of challenging them. It’s about making sure important product decisions aren’t resting on something the team has never actually validated.
A difficult question during discovery is usually much cheaper than a difficult realization after development.
Then We Turn What We've Learned Into Product Decisions
Research and discovery aren’t useful if everything we learn simply ends up sitting in a document somewhere. The value comes from what happens next.
Insights begin influencing priorities. User frustrations shape workflows. Stakeholder goals help us evaluate trade-offs. Assumptions that were validated give the team greater confidence, while unanswered questions tell us where we may need to explore further.
This is where research begins turning into design direction. By the time we start sketching flows or creating early wireframes, we’re no longer staring at a blank canvas wondering what might work. We have context. We understand more about the users, the business, the existing experience, and the constraints surrounding the product.
We still explore. We still question things. We still change our minds. But we’re starting from a much stronger place.
What This Looks Like at Pepperplane
At Pepperplane, we don’t see discovery as the phase we have to get through before the “real” design work begins. It is part of the design work.
The exact process depends on the project, but it can include stakeholder conversations, user interviews, reviews of existing products and workflows, workshops, journey mapping, and collaborative sessions with product teams and developers. Each activity helps us build a clearer picture of the problem before we become too attached to a particular solution.
Sometimes discovery confirms the direction everyone expected. Other times, it changes the conversation entirely. Both are valuable outcomes because the purpose isn’t to prove an initial idea right or wrong. It’s to give the team enough understanding to make better decisions about what comes next. By the time we’re working in Figma, the interface isn’t appearing out of nowhere. It’s the result of everything we’ve learned together.
Final Thought
The polished screens may be the part of UX that everyone eventually sees, but they’re built on decisions that happened much earlier.
A stakeholder conversation can uncover a business constraint that changes the workflow. A user interview can reveal a frustration nobody internally realized existed. Reviewing the current product can show that the real problem isn’t where the team originally thought it was. Questioning one assumption can save weeks of work on something users never needed in the first place.
None of those moments produce a beautiful interface on their own, but they give the interface a reason to exist. That’s why we don’t rush to draw the first screen.
Before we decide what something should look like, we want to understand what it needs to do, who it needs to work for, and what problem we’re really trying to solve because the better we understand those things, the better every design decision that follows can become.
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.
