A client once asked me, “Can you just send the Figma when you are done?”
I knew what they meant. They wanted progress. Something they could point at in a meeting. Something that looks like a product.
But that question also reveals a common misunderstanding that shows up everywhere, from startups to enterprise teams.
Figma is not UX.
Figma is where UX decisions get documented. UX is the work that earns those decisions in the first place.
I love Figma. I use it constantly. But I have learned the hard way that if I open a design file too early, I end up in performance mode. I start polishing screens before I have earned the right to draw them.
And the cost shows up later.
It shows up as scope creep. It shows stakeholders debating colors rather than outcomes. It shows up as a build that technically ships, but still does not solve the problem that started the whole project.
Here is the story of what changed for me and the steps I now take before I open a design file.
The Moment I Stopped Starting In Figma
Early in my career, I treated Figma like the starting line. I would get a vague request, open a file, and start exploring.
Sometimes it worked, mostly because the problem was small or the team already had clarity.
But the projects that hurt were the ones where the request sounded simple, and the reality was not.
A redesign request that was actually a trust problem.
A dashboard request that turned out to be a data quality problem.
An onboarding request that turned out to be a messaging problem.
When I started in Figma, I could make something look good fast. That was the trap. The visuals created a false sense of certainty. Everyone felt like we were moving, but we were moving in the dark.
Now, when someone asks me for the Figma, I treat it like a signal. Not a red flag, just a signal that we need to align on what the work actually is.
Start With The Problem, Not The Layout
Before I touch UI, I want a clear answer to a boring question:
What problem are we solving, and for whom?
Not, we need a dashboard. Not, we need a redesign. Not, our competitor has this feature.
I want the sentence that forces clarity, like:
- New users are not completing onboarding because they do not understand what to do next.
- Patients are missing appointments because rescheduling on mobile is confusing.
- Admins cannot find the one setting they need, so they keep opening support tickets.
If we cannot write the problem in plain language, we are not ready for pixels. We are ready for questions.
Map The People And The Stakes
UX is not just user flows. It is context, motivation, and consequences.
I ask things like:
- Who is the primary user, and who else is affected?
- What does success look like for them?
- What happens if they fail?
- What does the business need to be true for this to be worth building?
This is where a lot of simple projects stop being simple, in a good way. You start to see the real constraints and opportunities.
And this is also where you often find the real decision makers. Not the person who requested the screens, but the person who owns the outcome.
Audit What Already Exists
Before we invent a new experience, I want to understand the current one.
That can mean:
- A quick walkthrough of the existing product
- A look at support tickets and common complaints
- A scan of analytics to see where people drop off
- A review of any past research, even if it is messy
Sometimes the best UX move is not a new screen. It is removing a step. Renaming something. Fixing a broken assumption.
You do not find that by staring at an empty Figma frame.
Define The Jobs And The Critical Paths
I want to know what the user is actually trying to do.
Not the feature list. The job.
Examples:
- I need to understand if this is the right plan for me.
- I need to book this without calling anyone.
- I need to fix this fast so I can get back to my real work.
Then I map the critical path, the shortest path to success.
If we cannot describe the critical path, we will design many screens that look impressive but still fail at the moment that matters.
Write The Content Before The Layout
This is the part that surprises people.
Words are not decoration. They are part of the experience.
Before I design, I often draft:
- The headings that explain what this page is
- The microcopy that reduces anxiety
- The error messages that help people recover
- The call to action that matches the user’s intent
If the content is unclear, the UI will be unclear as well. Figma cannot save you from vague thinking.
And when you write the content first, something interesting happens. You start seeing where the experience is doing too much work. You start spotting the steps that exist only because nobody wanted to make a decision.
Align On Constraints And Tradeoffs
Every project has constraints. Time, budget, tech, team capacity, legal, brand, platform.
I prefer to surface those early, because constraints are not a problem. Hidden constraints are.
This is also where scope gets real, not in a spreadsheet, but in a shared understanding of what we are optimizing for.
When we agree on tradeoffs upfront, the design process gets calmer. Less surprise. Less whiplash.
Then Open Figma
Once the problem is clear, the people are understood, the current experience is audited, the critical path is mapped, and the content is drafted, Figma becomes what it should be.
A tool for making decisions visible.
At that point, I move faster. I iterate with purpose. I can explain why a screen exists, not just what it looks like.
And when stakeholders ask for changes, we have something better than opinions. We have a shared definition of the problem and the outcome we aim to achieve.
The Rule I Follow
If I cannot write the problem, I do not draw the solution.
Figma is not UX. It is where UX shows up after you do the work that matters.
If you are a designer, I would love to hear this.
What do you do before you open a design file?
