UX Designers Spend Too Much Time in Figma — and Too Little in Their Own Product

This may be the most important insight of all. A perfectly built screen in Figma says surprisingly little about how a product feels after three months of daily use. Figma has no real loading times, no ten-year-old datasets, no permission issues, no forgotten empty states, no browser quirks and no situation in which someone under time pressure is trying to complete the same task for the twentieth time that day. Figma shows an idealized state. The real product shows reality.

This creates an interesting distance in many product organizations: UX works in Figma, Product in Jira or Linear, Development in code, Management in dashboards and Marketing with screenshots. Everyone is constantly dealing with the product — yet hardly anyone spends several hours per week truly inside the product itself. Eventually, teams know the roadmap, tickets, components and feature names better than the actual experience of using the product.

This is exactly where heavy use comes in. It is not about clicking through the happy path once before a release, but about using the product intensely enough for its quirks to become visible. Only then do you notice which navigation may be logical but is consistently slow; which information always appears in the wrong place; which dialog becomes annoying after the fiftieth time; or which function is theoretically well designed but constantly creates a detour in practice.

User testing is extremely valuable, but it usually shows a snapshot. We give a user a task, observe for twenty or thirty minutes and see where they hesitate, what they miss or where they abandon the process. What this rarely shows is the effect of repetition: How does a feature feel after the hundredth use? Which five seconds become unbearable after three months? Which small inconsistency costs time every day? This dimension only becomes visible when usage turns into routine.

A single extra click is usually not a problem. But if a user performs a process 50 times a day, that becomes 250 clicks per week, around 1,000 per month and 12,000 per year. A seemingly minor interaction turns into recurring work. Heavy users therefore start to evaluate interfaces not only visually or functionally, but also over time: What repeats? What consumes attention? What has to be decided or entered again and again?

Many of these problems can be reduced to a few typical friction points:

• reapplying the same filters or settings over and over,
• re-entering information even though the system already knows it,
• repeatedly going through confirmation dialogs and intermediate steps,
• navigating deeply or switching tools for frequent actions,
• waiting for slow states or constantly rebuilding the same context.

Sometimes my strongest UX signal is simply: When does my own product annoy me? Not once, but repeatedly. Annoyance is often a useful indicator of systematic friction. The first time, you accept an unnecessary step; the tenth time, you start to wonder; and by the fiftieth, you ask the truly interesting question: Why does this step exist at all? Maybe we do not need to make the form prettier — maybe we need to remove it. Maybe we do not need a better dialog — maybe we need no dialog. Maybe the process should not be optimized, but automated.

With AI, this question becomes even more important. If a system knows my role, context, previous decisions and most frequent actions, why does it force me to enter the same things again and again? Heavy use exposes these patterns — and often turns small UX friction into concrete automation or product ideas.

Anyone who uses their own product intensively eventually starts observing their own behavior automatically. Where do I search? Where do I go back? Where do I open Excel in parallel? Where do I take screenshots, copy data into notes or create a workaround? These detours are extremely valuable because they show where a product does not fully fit the real process. If users regularly have to continue working outside the system, perhaps a feature is missing — or an existing one is too complicated, too slow or placed in the wrong location.

5 participants are a commonly cited rule of thumb for small qualitative usability tests. Nielsen Norman Group also emphasizes that larger or smaller samples may make sense depending on the question. Heavy use complements such tests — it does not replace them. Nielsen Norman Group ↗

That is why designers and product teams should not only test features, but do real work in the product. Do not just check whether the export button works; export the file, open it, process it and share it. Do not just test whether search returns results; find an old record whose exact name you do not know. Do not just run through a checkout; actually order, change, cancel and order again. The real user experience often starts exactly where the defined test case ends.

This becomes especially clear in complex B2B products. A screen can look excellent while the overall process is still cumbersome because behind it are permissions, approvals, ERP and product data, variants, status changes, tables, exports, legacy systems and real business processes. In such products, UX is very often process design, not just screen design. Anyone who truly wants to understand these processes should go through them repeatedly with real data.

I have probably learned more about UX through my own products than through many theoretical methods. In client projects, at some point you can hand over a decision: the feature goes live and the project continues. With your own product, that does not work. You encounter your decisions every day. With products such as Gutscheingirl, coopz or Mina, I was not only the person thinking about UX, but also the product owner, operator, user, support, tester and sometimes sales. That removes the distance between a design decision and its consequences.

An idea can look excellent in a concept, convince everyone in Figma and receive approval in a meeting — and two weeks later, daily use reveals that it is annoying. At that point, the original design rationale matters very little. The only question that matters is: Does it work in everyday use? This experience forces you to fall less in love with your own solution and become much more willing to change it quickly.

Of course, the most important objection still applies: You are not the user. Heavy use must never mean: “I like it, so users will like it too.” Designers know the system better and have different goals and experiences. But this principle should not lead to the opposite conclusion that our own usage experience is irrelevant. If I notice every day that a process is slow, that I constantly have to enter the same data, or that a frequent action is buried five levels deep, that is at least a signal worth investigating. That is exactly why real observation with users remains indispensable.

For me, the strongest product decisions emerge from three perspectives that need to come together:

None of these perspectives is sufficient on its own. But when all three point to the same problem, things get very interesting.

Another thesis that may not please everyone: many products need fewer major UX redesigns and more continuous small improvements. A new design system, a new navigation or a complete relaunch are easy to present. In everyday use, however, other things often determine whether a product feels good: a saved filter, a useful default, a prefilled input, one fewer click, a better error message or a loading time reduced from four seconds to one.

We overestimate visible design and underestimate invisible product quality. A step that no longer exists is hard to show in a portfolio. An automatically filled field does not look spectacular. Better performance does not create a beautiful screenshot. Yet for users, these changes may be more valuable than the next big feature.

Over time, something else emerges that I would call UX Debt . One extra click here, an inconsistent term there, another dialog, another edge case, another tab. No single decision is catastrophic — but a thousand small decisions layered on top of each other make a product heavy. Heavy users feel this very early because they experience it constantly.

64%

of the desktop checkouts studied by Baymard in 2025 were rated “mediocre” or worse.

The example is specific to e-commerce, but it illustrates well how even established products can accumulate many small UX friction points over the years.

Baymard Institute ↗

This also changes priorities. Roadmaps often have an inherent bias: new is more interesting than improving. A new integration, a new AI feature, a new capability. But perhaps users would benefit more if the existing core function finally became really good. Good product teams therefore need, alongside a feature roadmap, something like a friction roadmap: Which small things cost users time every day, and which of them can we eliminate?

For me, this also includes topics that are sometimes dismissed too quickly as technical details. Performance is UX. At 300 actions per day, every extra second is noticeable. Defaults are UX. Which view opens, which filter is preselected, what does the system remember, and what can it infer from context? Heavy use in particular develops a sense for which of these invisible details actually make a product better.

One problem remains: product teams get used to poor UX surprisingly quickly. After a while, we know the hidden buttons, odd terminology, keyboard shortcuts, workarounds and bugs so well that we barely notice them anymore. Heavy use should therefore be deliberate. Two questions help: If I saw this for the first time today — would I understand it? And just as important: If I had to do this a hundred times every day — would I hate it?

I would even establish a small ritual in the product team: a Heavy User Review. Not a three-hour workshop and no 80-slide deck, but 30 minutes every one or two weeks. Everyone brings three observations from real use — no solutions yet, just friction.

• “I had to set the same filter three times.”
• “I did not know whether it had been saved.”
• “The dialog appeared again for every process.”
• “I had to look up information in another system.”
• “A supposedly simple action took six steps.”
• “Search only works if I know the exact term.”

Observations like these are surprisingly good starting points for product improvements. They also create something that is difficult to measure but extremely important: product feel. Anyone who uses a product for hundreds of hours develops a sense for what fits, what is too complicated, which information arrives too late or which step should not exist at all. This feeling does not replace data — but it makes good hypotheses possible faster.

Figma is an excellent tool. But perhaps UX designers should spend a little less time looking at perfect screens — and more time experiencing bad processes. Open the real product. Log in. Do not use only the happy path. Search for old data, change settings, make mistakes, move between processes, use the product on mobile, on a slow device or ten times in a row. And write down what annoys you.

Not because this suddenly makes you a substitute for your users. But because you stop looking at your product only from the outside. Eventually, you no longer know just the screens, features and roadmap, but also the friction, habits, weaknesses, shortcuts and small time sinks. In my experience, that is where many of the best UX improvements emerge.

UX designers should not just design their own product. They should be among its most intensive users. Or, more simply: Close Figma. Open your product. And use it. Every day. If you want to establish UX systematically as a product discipline, you can read more under UX & Design Leadership and Product Strategy.