#11 Stop opening Figma. Do this first.

There’s a phase in every UX project that nobody talks about online.

It doesn’t look good in a portfolio. You can’t animate it in Figma. There’s no satisfying “before and after” to post on LinkedIn. And yet, skipping it is probably the number one reason why junior UX designers end up producing work that doesn’t solve the business’ and users’ problems: screens that look polished but solve the wrong problem, flows that are incomplete, handoffs that fall apart the moment they hit the development team.

I know this because I’ve been there myself.

Early in my career, I used to go straight to the mockups. Someone would give me a brief, I’d open Figma, and I’d start designing. It felt productive. It felt like “doing UX”. And the results often looked pretty good, at least to me.

Then came the demo: the developers would present something that looked completely different from what I had designed. Or worse, they’d say “we can’t build this” about something I had spent days on. The reason, in most cases, was simple: I had never involved them at the beginning. I hadn’t asked questions. I hadn’t checked my assumptions with the people who actually knew what was technically feasible. I had just... designed in a vacuum, and handed things over hoping for the best.

It took a few painful demos to understand that the problem wasn’t my Figma skills. The problem was that I was jumping straight to solutions before properly understanding the problem.

If you scroll through UX design content online on TikTok, Instagram, YouTube, or Behance, what you see is almost exclusively the output: beautiful interfaces, smooth micro-interactions, clever UI patterns. The “wow” stuff.

What you almost never see is what happens before that. The messy, unglamorous phase where you sit with a brief and ask yourself: what do I actually know here? What am I assuming? And what do I still need to find out?

This is the phase that experienced designers have internalized so deeply they barely talk about it anymore. But for someone early in their career, it’s completely invisible — which means they skip it, open Figma, and start drawing. And then they get lost. The screens are incomplete. The flows don’t account for edge cases. There’s no logic holding it all together, because the logic was supposed to come from understanding the problem first.

Before you open any design tool on a new project, I suggest doing one simple exercise: Take a blank page (or a Miro board, or a Notion doc — whatever works for you) and divide it into three columns:

Facts — what you know for certain. This might come from the project brief itself, previous research, from conversations with the product team, from analytics data, from technical documentation. Facts are things you can point to and say: “this is verified.”

Assumptions — what you think you know, but haven’t validated yet. In UX, assumptions are the beliefs you hold about users, context, or goals that haven’t been tested. They might be right. They might be completely off. The key is to make them explicit rather than letting them drive your design without questioning them.

Questions — what you don’t know yet. These are the gaps: things you need to find out before you can design with confidence.

The goal isn’t to have perfect answers before you start. It’s to know what you’re working with versus what you’re still figuring out — and to have a plan for closing the most critical gaps.

Let’s say you’re designing a B2B platform for managing service tickets. A stakeholder tells you:

“Our users can’t find the tickets assigned to them — add a filter at the top of the list.”

A junior designer might open Figma and start exploring filter UI patterns.

An experienced designer pauses and asks: wait, what do I actually know here?

Facts: There’s a list of tickets. Users are assigned to specific ones. There’s currently no filter.

Assumptions: My hypothesis is that the interface’s main problem is discoverability: Users know what they’re looking for but can’t find it. The stakeholder assumes a filter could solve it.

Questions: How many tickets are we talking about — 10 or 10,000? Do users search by their own name, by status, by date? Are there other ways they currently navigate the list? And — most importantly — is the real problem the filter, or is it something else entirely (e.g. unclear microcopy, a badly designed system) that’s causing users to lose track of their tickets in the first place?

Suddenly, what seemed like a simple UI task becomes a much more interesting problem. And the solution you design will be a lot more likely to actually work.

One thing I want to be clear about: this exercise isn’t necessarily meant to be done alone. Some of your questions will be answered by user research. But many of them, especially in B2B contexts where access to users is limited, will be answered by talking to your team.

Developers know what’s technically feasible. Product managers know the business constraints. Customer support knows what users actually complain about. In my experience, one honest conversation at the beginning of a project can save you days of rework later.

Which brings me back to my early-career self, presenting mockups at a demo and watching them fall apart: the developers weren’t necessarily wrong, I just hadn’t asked them anything.

The “unsexy” truth about UX design is that the quality of your output depends almost entirely on the depth of your preparation. The beautiful screens come later — and trust me when I say that they come faster, and they hold up better — when you’ve done the boring work of understanding the problem first.

So next time you get a brief, before you open Figma: grab a blank page. Write down what you know, what you think you know, and what you still need to find out.

It’s not glamorous. But it’s the thing that separates designers who produce work that actually ships from those who wonder why their designs keep getting changed in development.

Have you ever jumped straight to mockups and regretted it? I’d love to hear your experience in the comments!

If this framework resonates with you, I can’t recommend The Mom Test by Rob Fitzpatrick enough.

The book is technically about how to talk to customers when validating a startup idea, but the core lesson applies perfectly to UX work:

Most of the questions we ask are unconsciously designed to get the answers we want to hear, not the answers we need to hear.

The title comes from a simple idea: if you ask your mom “do you think my app is a good idea?”, she’ll say yes because she loves you, not because it’s true. The same thing happens when designers ask users leading questions, or when we present our assumptions to stakeholders framed as facts.

It’s a short, practical read (you can finish it in a weekend) and it will permanently change how you approach conversations with users, clients, and stakeholders alike. I highly recommend it if you want to get better at asking the right questions before you start designing!

🎓 New on Uxcel: Design Mentorship Mastery I’ve recently partnered with Uxcel to update the Design Mentorship Mastery course — a course I personally revised and contributed to. If you’re interested in getting better at giving and receiving design feedback, or thinking about mentorship as part of your career, it’s a great place to start.

💬 Work with me 1:1 I still have a few open spots for mentorship. If you’re an aspiring or junior UX designer looking for guidance on your portfolio, career path, or day-to-day design challenges, you can find all the details and book an intro call on my MentorCruise profile.