Core Insights
Figma Is Often the First Mistake
Open Figma and you have an almost irresistible blank canvas.
There is something satisfying about starting a new file, creating a frame, choosing a typeface, and watching an interface take shape. For someone learning UX design, it can feel like progress almost immediately.
But this is where many projects go wrong.
The designer starts making decisions before there is enough information to make them.
A navigation bar appears before anyone has thought about the site's information architecture. A dashboard gets designed before the team knows what users actually need from it. Buttons are polished before anyone has defined the task those buttons are supposed to help users complete.
The result can be a beautifully designed interface solving a poorly understood problem.
Good UX work usually starts somewhere less exciting: asking questions.
Before opening Figma, a designer needs to understand what is being built, who it is for, what those people are trying to accomplish, and what is currently getting in their way.
The interface comes later.
Start With the Problem, Not the Screen
Imagine a client says:
“We need a mobile app for booking fitness classes.”
It is tempting to translate that sentence directly into screens.
Home screen.
Search.
Class details.
Booking.
Profile.
But none of those screens tell you whether you understand the problem.
Why do people need the app?
How do they book classes today?
Are they struggling to find classes, compare schedules, understand pricing, or actually complete the booking?
Maybe the real problem has nothing to do with booking at all.
Perhaps people already know how to book a class. What they cannot easily do is find a suitable class near them at a convenient time.
That changes the product.
This is why a UX project should begin by separating the solution from the problem.
“Design a fitness booking app” is a solution.
“People struggle to find and compare suitable classes based on location, schedule, and price” is a problem worth investigating.
That distinction sounds small. In practice, it can change everything that follows.
Understand the People Behind the Problem
Once the problem is clear enough to investigate, the next question is simple:
Who is experiencing it?
“Users” is not a useful answer.
A first-time customer, a returning customer, an administrator, and a power user may all interact with the same product differently.
Consider an online banking application.
A customer might open it to check a balance, transfer money, freeze a card, or investigate an unfamiliar transaction. Those tasks have different levels of urgency and different consequences when something goes wrong.
The interface should reflect that reality.
Understanding users does not necessarily mean creating elaborate personas with fictional names, stock photos, and paragraphs of invented personality traits.
Sometimes the most useful thing a designer can learn is much simpler:
What are people trying to do?
What do they already know?
What do they find difficult?
What do they expect to happen?
What makes them hesitate?
These questions give you something much more valuable than a decorative persona: a reason for making design decisions.
Research Before You Decide
UX research is where assumptions start getting challenged.
You might believe that users want more features. Research may show that they actually want fewer steps.
You might assume that a dashboard needs more data. Users may tell you that they cannot find the one piece of information they actually care about.
You might think a checkout problem is caused by a long form. Analytics or usability testing may reveal that users are abandoning the process because delivery costs appear too late.
Research does not have to mean running a six-week study.
Depending on the project, it might involve interviews, usability tests, surveys, analytics, competitive analysis, customer reviews, support tickets, or simply studying how an existing product is being used.
The method matters less than the question behind it.
Good research reduces uncertainty.
That is its real value.
Don't Confuse Assumptions With Insights
This is one of the most important habits to develop as a new UX designer.
Suppose you write:
“Users don't like creating an account.”
That sounds like a research finding.
It might not be.
If you have not actually spoken to users or observed their behavior, it is an assumption.
A better way to think about the process is:
Assumption → Evidence → Insight → Design decision
For example:
You assume that mandatory account creation is causing checkout abandonment.
You examine analytics and run a few usability sessions.
You discover that users are not primarily frustrated by creating an account. They are confused about why the account is required and what they get in return.
Now you have an insight.
The design problem is no longer simply “remove account creation.”
It might be about communicating value, timing the request differently, or offering a guest checkout option.
That is UX thinking.
Define What Success Looks Like
Before designing the interface, it is useful to define what a successful experience actually means.
This is often overlooked because “success” can sound like a business problem rather than a design problem.
It is both.
For a travel product, success might mean helping users find and book a suitable flight without unnecessary confusion.
For a SaaS product, it might mean helping a new user reach their first meaningful outcome quickly.
For an ecommerce site, it might mean helping customers understand a product well enough to make a confident purchase.
These goals give you something to design toward.
Without them, design reviews easily become conversations about personal preference:
“I like this version.”
“I prefer the other layout.”
“This button looks better here.”
Those discussions are difficult to resolve because there is no shared definition of what the design is supposed to achieve.
A clear user goal gives the conversation somewhere to go.
Think About the Structure Before the Interface
Once you have a better understanding of the problem and the people using the product, you can start thinking about structure.
This is where information architecture becomes important.
Before deciding what a screen looks like, decide what information belongs there and how the different parts of the product relate to one another.
Imagine designing an ecommerce site.
You might have products, categories, filters, search, saved items, orders, account settings, recommendations, and checkout.
The challenge is not simply putting all of these things somewhere.
The challenge is creating a structure that makes sense to someone who has never seen the product before.
Where would they expect to find their orders?
Should saved products live inside the account or have a more prominent place?
Should categories be organized by product type, use case, brand, or something else?
These are UX decisions.
The pixels come later.
Design the Flow, Not Just the Pages
This is one of the biggest mindset shifts for someone coming from UI design.
A product is not a collection of isolated screens.
It is a series of interactions.
A checkout experience, for example, might look like this:
Product → Cart → Shipping → Payment → Review → Confirmation
But the real experience also includes everything that can happen between those steps.
What if the address is invalid?
What if payment fails?
What if the item goes out of stock?
What if the user leaves halfway through?
What if they want to change the quantity?
A good user flow accounts for the actual journey, not just the happy path.
This is why designing flows before polished screens can be so useful. As Smashing Magazine has argued, designers can easily become focused on individual pages when the more important question is how those pages work together to support a user's task.
A screen can be perfect on its own and still be part of a terrible experience.
Sketch Before You Polish
Now you can start designing.
But there is still no reason to jump straight into high-fidelity UI.
A quick sketch can answer a surprising number of questions.
Where does the primary action belong?
What information needs to be visible first?
What can be secondary?
How many steps are actually necessary?
What happens when the user makes a mistake?
At this stage, ugly is useful.
A rough wireframe is cheap to change. A polished interface creates attachment.
This is one reason experienced designers often explore ideas at low fidelity before committing to visual detail. Early sketches make it easier to throw away an idea, change the hierarchy, or completely rethink a flow without feeling like hours of visual work have been wasted.
The objective is not to make the wireframe beautiful.
It is to make the experience understandable.
Then Open Figma
This is the point where Figma becomes useful.
Not because Figma tells you what to design, but because you now have something worth designing.
You have a problem.
You have a better understanding of the people involved.
You have research or evidence.
You have identified important goals.
You have started shaping the information architecture.
You have mapped the important flows.
Now you can use Figma to explore those decisions visually.
That might mean creating low-fidelity wireframes, building components, creating prototypes, testing different interaction patterns, and eventually moving into high-fidelity UI.
The tool has changed very little.
Your understanding has.
Don't Design the Happy Path and Call It UX
One of the easiest ways to spot an inexperienced design process is to look at what happens when everything goes perfectly.
The user enters the correct information.
The network works.
The payment succeeds.
The content exists.
The user knows exactly what to do.
Real products are not like that.
Users make mistakes. They change their minds. They lose connections. They forget passwords. They encounter empty states. They enter information incorrectly. They arrive at pages with no results.
These moments are not secondary to the UX.
They are part of it.
Loading states, error messages, empty states, confirmations, permissions, and recovery paths deserve design attention just as much as the main screens.
In many products, these states are where the quality of the experience becomes most obvious.
Test the Experience, Not Your Taste
At some point, you have to stop looking at the design yourself.
Put it in front of another person.
Give them a task.
Then watch.
Do not explain where the button is.
Do not tell them what the screen means.
Do not correct them halfway through.
If they hesitate, that is information.
If they click the wrong thing, that is information.
If they ask a question the interface was supposed to answer, that is information.
Usability testing changes the role of the designer. Instead of defending a design because it makes sense to you, you start looking for evidence that it makes sense to the people using it.
That mindset is especially important today, as AI-assisted design makes it increasingly easy to generate polished interfaces quickly. When producing screens becomes faster, deciding whether those screens actually solve the right problem becomes even more important. Nielsen Norman Group has recently described this shift in terms of designers increasingly needing to evaluate and guide AI-generated design rather than simply producing every interface manually.
UX Is Not a Straight Line
It is tempting to imagine UX as a neat sequence:
Research → Wireframe → UI → Prototype → Test
Real projects rarely behave that way.
You may discover during testing that the navigation is wrong.
That can send you back to the information architecture.
You may discover during research that the problem you were solving was not the most important one.
That can send you back to the beginning.
You may discover that two user groups have completely different needs.
That can change the flow.
This is not wasted work.
It is the work.
UX is iterative because learning changes the design.
A useful process is therefore less like a straight road and more like a loop:
Understand → Design → Test → Learn → Change → Test again
The goal is not to produce every deliverable in the correct order.
The goal is to make better decisions as your understanding improves.
What Should You Actually Have Before High-Fidelity UI?
For a small project, you do not need a 100-page UX document.
You need enough thinking to explain why the design exists.
That might include:
A clear problem
What are you trying to solve?
A defined user
Who experiences the problem?
Research or supporting evidence
What makes you believe this problem is real?
User goals
What are people actually trying to accomplish?
Information architecture
How is the product organized?
Key user flows
How do users move through the experience?
Wireframes
What is the simplest structure that could solve the problem?
Prototype
How does the experience behave?
Testing
What did real or representative users struggle with?
Iterations
What changed after you learned something new?
The exact artifacts will vary from project to project. The thinking behind them is what matters.
The Best UX Designers Are Not the Ones Who Open Figma Fastest
There is a strange contradiction in learning UX.
The more excited you become about design tools, the easier it is to spend too much time inside them.
You learn Auto Layout.
Then components.
Then variables.
Then prototyping.
Then advanced interactions.
All of that is useful.
But none of it answers the most important question:
Are you solving the right problem?
A strong UX designer knows how to move between research, product thinking, interaction design, visual design, and validation.
They know when to make something more detailed and when to throw it away.
They know when a design problem is actually a content problem.
They know when a UI problem is actually an information architecture problem.
And they know when the right answer is not another screen.
So the next time you start a UX project, resist the urge to open Figma immediately.
Spend a little more time understanding the problem.
Talk to users.
Look at the evidence.
Map the journey.
Sketch the experience.
Then open Figma.
You will probably design fewer screens.
And they will probably make a lot more sense