What Is User Friction and How to Reduce It

Featured Image

You’re likely familiar with the phrase user friction.

What is user friction?

User friction is anything that hinders a user from achieving an outcome on your digital product. Common examples of user friction are an un-intuitive user interface and critical bugs/errors.

In the early 2000s, user friction was rampant but expected given that the internet was still pretty new. Web 1.0’s friction was defined by slow connections and lo-fi control interfaces. But today, friction is a product of UI overload. Technologies like Ajax and React have enabled web apps to deliver richer, but more complex interfaces. With complexity comes a new breed of user friction.

The Causes of User Friction

There are two types of user friction—accidental and structural.

Accidental friction is typically the engineering team’s department—bugs and errors that aren’t intended to happen and often prevent users from achieving an outcome. Accidental friction is tackled by (a) surfacing bugs that users are experiencing and (b) deploying patches in an efficient, expedited manner. Bugs and errors may be obvious (error alerts popping up on the user) or more discreet (a product not being responsive to certain screen sizes).

And then there’s structural friction. Unlike accidental friction, structural friction is more invisible. Structure friction happens when either:

  • A user struggles to understand your product
  • A user fears that your product will be hard to learn
  • A user believes too many steps are needed to accomplish a task
  • A user feels a product is slow to respond
  • A user feels an action behaved differently from what it should’ve

In other words, structural friction is user frustration at an otherwise ideally-functioning product. We can break structural friction down into three more categories.

  • Interaction Friction—if a user struggles with anything above while actively interacting with your product, that’s interaction friction. This is arguably the worst type of friction because users feel that your product is badly-designed / low-value.
  • Cognitive Friction—if a user believes that they need to expend a lot of mental energy to use your product, that’s cognitive friction. Unlike interaction friction, cognitive friction may stump users at the beginning of their journeys. Common examples of cognitive friction include:

    — A user feeling that a product’s terminology is different from their own.
    — A user feeling like a product’s utility is overshadowed by the energy to learn its interface.
    — A user feeling like a desired outcome on your product takes too much concentration, cognitive load, and/or too many clicks.
  • Emotional Friction—emotional friction happens when a user experiences either of the previous examples and develops a negative attitude about your product. Emotional friction may be witnessed in internal messages between employees angry with a tool or task. Even if a product solves the user's root problems, emotional friction can hinder them from giving a product a second shot.

Why Care?

There are plenty of products that users complain about but still buy and use. The most popular is likely Salesforce. Most sales professionals believe Salesforce is a powerful but unintuitive tool, but given Salesforce’s ecosystem, wouldn’t consider using anything else. In rare cases, friction may be perceived as a good thing. For instance, users may appreciate friction when utilizing a banking app because it implies better security.

However, most products are not afforded this friction-agnostic luxury. Today’s app marketplace is highly competitive, and products with high user friction will have fewer conversions from free/trial accounts to paid, especially when relying on a product-led growth strategy. Products with high user friction will suffer worse product adoption and feature adoption, thus feature a worse retention rate.

Without tackling user friction head-on, your product will not reach its full potential.

Metrics to Measure User Friction

The Metrics

Before we can tackle user friction, we need to understand where it is happening. There are a number of techniques you should implement to determine where user friction exists in your product.

  • User Flows—imagine each session that a user embarks on as a journey. Like any journey, there is a mission to be accomplished. First, decide if you can understand the user’s mission. Sometimes, this is easy—perhaps they clicked on “New Ticket” and, therefore, are on a mission to create a ticket. Other times, tricky—imagine a user that flounders around a product with no clear sign of what they want.

For journeys where the user’s mission is clear, then measure if they were able to accomplish it. For the earlier example of creating a ticket, a user needs to actually reach the end of that flow to accomplish their goal. If that drops off early, there’s a good chance that that region is a source of friction.

Of course, some users may abandon your product for reasons outside your control. Perhaps they received a funny text and got distracted, or maybe their toddler started screaming from across the house. With any product, there are going to be befuddling user journeys that cannot be explained because you weren’t there. That’s okay. What matters are trends and repetitive examples of user journeys that are interrupted at the same points.

  • Time-to-outcome (TTO). Determine an ideal time it should take for a user to achieve an outcome by either sampling your best user’s journeys or your employees. Then examine how long it takes for the average user to accomplish an outcome. Stay clear of the worst users—they are likely distracted by matters outside your control or don’t need your product. Instead, focus on the users that are successful but slow. Examine how much time they spend per step and cross-examine that with your best users. Using this method should reliably uncover sources of user friction.
  • Unexpected User Flows. Sometimes, users may do things completely irrational to a product-educated viewer. For instance—why did they start a ticket, abandon the flow, make a comment, then start a new ticket without revisiting their old draft? Alternatively—why did they attempt to create a template from the documents tab and delete it afterward? Sometimes, unexpected user flows happen because a user is fickle about what they want to do. However, unexpected user flows may happen because a user is confused about how a product works.

    Unexpected user flows typically happen when a user is invested in utilizing a product, but a product’s interface doesn’t efficiently reveal how they accomplish that action.
  • Lack of Usage. A user may not log into your product as often as they should. Perhaps they have the capacity to, but the perceived friction of using your product encourages users to procrastinate returning back.

The Measurement Tools

There are fundamentally two major techniques to measure the aforementioned metrics.

  • Event-Based Journeys. Using a platform like Amplitude, Posthog, or Mixpanel, define events in your product. Each event has an associated user and session ID, and your analytics solution will be able to re-create user flows.
    Event-based journeys are a fantastic way to gauge user flow funnels. For instance, you can measure how many users that began a journey successfully completed it and at which stage users dropped off at.
  • Session Recording. Around 2014, session recording became an alternative option to event-based journeys due to the advent of the MutationObserver API. With the MutationObserver API, session recording efficiently records and reconstructs a user’s precise journey, including which buttons they clicked, which elements they hovered over, and what they saw on their screen.

The most popular session recording tool is FullStory, but other platforms like Posthog, Hotjar, LogRocket, and Highlight are gaining popularity.

Session recording is rarely successful without event-based journeys being recorded. Otherwise, your product designers will be unable to reliably find and aggregate findings on session recordings without an event-based journey database to triage through.

Techniques to Minimize User Friction

While some user friction issues may require a more bespoke, specific solution, there are common techniques used to minimize user friction. These techniques vary between accidental and structural friction, so I’ve split the following into two lists.

For Accidental Friction, friction via unintended bugs:

  • Invest in Quality Assurance. Via usability testing, catch bugs before they go live, minimizing unhappy users that hit snags. You can build a strong Quality Assurance process by hiring quality assurance testers or building out unit tests that must pass before a product is deployed. Many businesses use both of these techniques to minimize the likelihood of bugs. At CommandBar, we have invested in QA engineering earlier than most companies; we felt that the investment was justified given our product embeds into our customers’ products and therefore is held to a high-quality standard. This investment has paid off massively.
  • Install an Engagement OS tool. Tools like Intercom and Drift enable disgruntled, stuck users to seamlessly reach out to your team to report a bug. You can think of these tools as user-initiated user interviews. While not all users will take advantage of such a service, this real-time form of user research will dramatically improve bug reports.
  • Invest in a Bug-Focused Session Recording tool. Products like Sentry or LogRocket alert your engineers when a new error is surfaced on production and make replaying the relevant session seamless. A session recording tool is a way for your engineers to hit “rewind” and discover the root cause of a snag.
  • Improve Product Performance. Invest in an edge-based solution like Netlify or Fly.io to surface your app faster, implement caching techniques to minimize load times, and utilize techniques like socket connections to improve app reactivity. All of these require a sizable technical lift, so while they’ll pay enormous dividends, may rob your engineering team of time that may be scant.
  • Use a Browser Emulator to Test. Use a browser emulator like Chrome Devtools or BrowserStack to test your product in uncommon screen sizes and browsers that your engineers may not routinely use. This will help surface bugs that happen on a specific device more quickly.
  • Mobile Emulators. If your product has active mobile usage, hire a team to test your product on mobile devices using actual touch screens and screen keyboards. This may catch snags not available in an emulator as touch events are different.

For Structural Friction, friction via invisible hindrances when using your product

  • Condense Flows. Remove steps to decrease user fatigue to accomplish an action. However, condensing flows may lead to user confusion if they are presented with too many tasks at the same time. If you are going to condense flows, actively monitor if your revised flow is confusing users.
  • Simplify Complex UI Components. Users likely spend far less time on your product than all other platforms combined. When Sergio Nouvel declared that Web Design is Dead, he was arguing that websites need to put more effort into imitating familiar UIs than innovating on them. While certain common modals (selectors, taggers, checkboxes, etc.) may feel un-innovative, boring, and perhaps even inefficient, they are often the correct decision to minimize user friction.
  • Inform the User More. Sometimes, your product needs time to query a database or process a request. Use animated spinners or loading bars—even if slightly fictitious—to assuage the user of the idea of a broken product. Users are less likely to be frustrated at a platform if they feel like something is happening in the background.
  • Build a Community. By engaging your users in community Discords or forums, you’ll encourage users to be more forgiving of a work-in-progress product. Given all products are constantly improving, fostering this community is invaluable when things invariably break.

Why we built CommandBar

You may be wondering why we’re so passionate about user friction at CommandBar. Simply put, CommandBar is an omnipotent search bar with the explicit goal of minimizing user friction. While our product isn’t for everyone, CommandBar dramatically reduces user friction by extending a familiar, easy-to-use UX component—the search bar. With CommandBar, users simply need to search for a task, and even if the terminology isn’t exactly correct, they’ll be able to carry out that action and learn about the product’s organizational structure in the same sweep. We call this user pull - it’s the difference between Netflix recommendations and Netflix search results.

Using a CommandBar, you can make complex and hidden actions easy to locate and utilize. Additionally, you can make surfacing help content distraction-free, minimizing user confusion. While CommandBar cannot help with accidental friction, it can dramatically minimize structural friction, and with our dead-ends feature, inform root causes of structural friction.


User friction is one of the biggest challenges in user experience UX design. As products grow more and more competitive with each passing year, ensuring your product has minimal user friction is critical for long-term success. If you want to chat more with us on your user friction challenges, please book a call with our team today.