Cover image
Product Life Cycle
10 minute read

How to Reduce UX Friction in Secure Product Development

Prioritizing data security often comes at the expense of a good UX. To balance client needs with user preferences, product managers must use research, constant calibration, and a dose of creativity.

In product development, looks often end up getting all the attention. A pleasing UI is important, but UX is what makes or breaks your product.

As a product manager, I spend most of my time thinking about how to reduce friction throughout the UX. By that I mean either reducing the number of steps an end user must take to achieve their goals or reducing the complexity of those steps. An e-commerce app that makes you go through three security measures to make a purchase won’t perform as well as an app that requires only one.

However, low friction can’t come at the expense of security for organizations that maintain sensitive customer data, such as financial institutions and insurance companies.

Because ease of use and personal data security are usually at odds, finding the right balance can be tricky. Here’s how to do it.

The Age-old Battle Between Security and Convenience

For decades after the birth of the credit card in the 1950s, issuers wary of fraud required merchants to call them whenever a transaction exceeded the “floor limit”—the maximum amount a cardholder could charge without pre-authorization. That’s a lot of friction for a consumer waiting to buy a new car or refrigerator. As a result, when setting floor limits, banks and credit card companies had to weigh their appetite for risk against their consumers’ tolerance for inconvenience.

A customer with a $10,000 credit limit probably has more value to a bank—and higher expectations for service—than one with a $1,000 limit. You might decide to raise the floor limit for this type of customer to minimize the friction they experience. But what if those higher-value accounts are also most vulnerable to fraud? You might end up introducing a level of risk that would do more damage to your bottom line than would the loss of some of those customers.

Fast-forward to the digital age and this seesaw of competing demands remains, albeit with fast-changing threats and less-patient consumers. There’s no exact formula to reconcile these demands, so product managers working on software and applications need to constantly calibrate their UX to keep friction and security in balance.

Less Fraud Doesn’t Always Mean More Profit

In most secure software and applications, there are two sets of customers that product managers must serve:

  1. The organization that prioritizes the highest protection possible.
  2. The end user who wants a seamless product UX.

A bank, for example, would prefer 100% protection against fraud for many reasons, including:

  • Customer satisfaction.
  • Fraud loss reduction.
  • Brand reputation.
  • Cyberattack minimization.

On the other hand, the end user has competing requirements: They want easy and quick access to their account. That’s not going to happen if the bank’s UX is designed for 100% fraud protection.

Instead, the end user will encounter high friction every time they use the app. For example, after entering a password, the user might need to enter a two-factor authentication code sent to their phone, followed by a biometric scan or a CAPTCHA challenge. The resulting lag time could lead some users to reduce their app usage or, worse, look for a new bank. In this scenario, the bank will have saved money on fraud losses but will have lost money on its dwindling customer base.

To complicate matters, different end users may have different thresholds for how much friction they’ll tolerate before seeking out another service provider.

An icon representing a bank is labeled with the text "The bank wants a secure app." An icon displaying a mobile phone is labeled with the text "The user wants a seamless experience."
The client’s needs and the user’s preferences are often at odds.

Lock Down the Client’s Goals, Costs, and Risk Tolerance

Now that we’ve established that attempting to provide 100% fraud protection doesn’t make business sense, we need to determine what does. Let’s start with the bank’s resources: money and people.

First, identify the bank’s current fraud rate and how much in losses it can absorb. Also weigh the net savings it hopes to gain with this new product against the cost of developing and maintaining it. (You may find that fraud protection costs more than fraud itself.)

Next, figure out how many suspicious cases and “false positives” the bank’s staff can process per day. False positives happen when the bank removes or restricts a user’s account due to a risk miscalculation. These false positives increase friction for the user, drain bank employees’ time, and can ultimately damage the brand’s reputation.

You can begin to scope your product once you’ve locked down what the bank can afford to spend or lose in money and labor. With this information, you can determine which data points to collect from end users to calculate their fraud risk score in real time.

Identify Which Data to Collect From End Users

Secure software and applications verify:

  • Who you are. These are your behaviors, which include things like your login locations or mouse movements.
  • What you have. These are the devices that are registered to you or that you use regularly.
  • What you know. This includes passwords, security questions, birthdays, and other personal information.

Once the software collects this information, machine learning models use the inputs from each category to assign the user a fraud risk profile. Based on this profile, an organization can decide whether to allow access, deny access, request further authentication, restrict functionality, or any combination of those options.

As a product manager, it’s tempting to collect as much information as possible. However, this isn’t always the best practice. That’s because the more information you collect from each user, the more time and resources it takes to calculate the risk score on the back end. This, in turn, increases the lag time for the user, i.e., more friction.

Instead, start with the indicators that seem to be the simplest signifiers of a user’s identity, such as location, known devices, and passwords. Then, think about the ways a malicious actor could circumvent those indicators. Sophisticated criminals could spoof a user’s location and device, and may have access to passwords compromised through data leaks or malware attacks. To close those loopholes, you might also analyze mouse movements or check to see if the user has made similar purchases in the past.

Before adding a new indicator, weigh its impact on fraud prevention against the upfront costs of adding it to the product. You should also factor in the recurring labor and financial costs that come with additional calculations and data storage.

Remember that finding the right set of indicators is an exercise in trial and error. The only way to truly determine the benefit of each indicator is to add and subtract each of them, monitoring every combination’s impact on your fraud rate and user experience for both the client and end users.

Embed With Clients to Vet Your Indicators

While the client may prioritize fraud reduction, usability for their own employees (such as fraud analysts) is also important on the back end. It’s therefore wise to make sure that the data points you plan to collect will help and not hinder them.

A design thinking framework is a useful approach to products that serve two user sets. It’s human-centered rather than problem-centered and asks designers to empathize with users so they can imagine their future needs. Design thinking can help product managers develop a dynamic product that serves competing interests—in this case, security and convenience.

Investing in the empathy stage means asking questions and embedding in your client’s everyday workflow. That allows you to engage with RFPs to forecast market shifts and see how the client’s data aligns with their real-time threat landscape. Once you understand these strategic and tactical challenges, you can begin development.

Plan to spend as much time as possible with your client during the development and testing phases. While feedback will give you a sense of the client’s wish list, shadowing helps you identify miscommunications, knowledge gaps, and design flaws that won’t show up in self-reporting.

Shadowing is fairly simple if you’re an in-house product manager sharing office space with fraud analysts. If you’re a consultant or off-site worker, you’ll need to arrange site visits as often as possible. If travel isn’t an option, virtual sessions with screen sharing are worth the effort.

Check in weekly with fraud analysts once your product is up and running to ensure that the UX design is serving them, particularly as you launch new features: Why do they perform tasks in a certain order? What happens when they click a particular button? How do they react when they get a notification? What changes are they noticing in their day-to-day work?

Collect Your Data

Data collection technology lets organizations leverage hundreds of data points to verify a user’s identity. It also helps e-commerce sites and apps tailor a user’s experience to their demographic profile. A user who fits a certain profile can even get custom deals or trigger automated assistance.

So how does this work in security applications?

  • Web browsers: Each time a user navigates to a protected site in a browser, embedded JavaScript “collectors” gather identifying information. This could include data points like location, device details, and mouse movements.
  • Native apps: Native apps are designed for a specific device platform, such as iOS or Android. When accessing a service from a mobile device, these apps use software development kits (SDKs) to collect identifying information, which might include finger taps and swipes instead of mouse movements.

Your machine learning models will then assign a fraud risk score based on the overall pattern these data points form. If the risk score is above average, it makes sense to introduce more friction in the form of two-factor authentication or security questions. However, if too many of your users are triggering extra verification steps, it might be time to reconsider your risk threshold or data collection strategy.

Keep Reducing End-user Friction

Once your product is running, keep track of end users’ complaints logged with call centers or through app stores to discover pain points and suggestions for improvement. Even the best pre-launch testing won’t catch every friction point, and new operating systems and device releases can cause unexpected complications that slow down end users.

For businesses built on e-commerce, the costs of these slowdowns are plain to see. In 2022, the Baymard Institute estimated that 17% of avoidable cart abandonments were due to an overly long or complicated checkout process; an additional 18% of respondents blamed a lack of trust in the security of their credit card information. Baymard estimates that slow checkout and lack of trust in site security were among a set of factors that contributed to $260 billion in lost sales across the US and EU. That presents an incredible opportunity for e-commerce product managers to rethink their point-of-sale solutions. But no matter your industry, reducing user friction and ensuring confidence in your data protection should be an ongoing practice that can yield happier customers and major business innovations.

A bar graph showing reasons for preventable cart abandonments during checkout. Values include: Additional costs too high, 48%; Account creation required, 24%; Delivery too slow, 22%; Site security feels untrustworthy, 18%; Checkout too complicated, 17%; Total cost unclear, 16%; Website errors, 13%; Return policy too stringent, 12%; Payment methods limited, 9%; Card declined, 4%.
Complicated checkout processes and lack of trust in site security accounted for 35% of avoidable cart abandonments in 2022.

Here are two examples of successful friction reduction in secure product development:

3DS

In the late 1990s, Visa and Mastercard teamed up to create the 3D secure payments (3DS) security protocol. Released in 2001, the original protocol required all users to register their cards with 3DS and log in at each checkout with a dedicated 3DS password. If a user couldn’t remember their 3DS password, they were required to retrieve or reset it before completing their purchase. In a later release, card issuers had the option of replacing the oft-forgotten static password with a dynamic one-time password (OTP). However, the extra login step continued to hinder the checkout process.

The 3DS developers took note of this lingering friction and, in 2016, released 3DS 2.0, which includes an SDK component that allows applications to embed the 3DS element into their code. 3DS 2.0 is better suited to mobile transactions and analyzes more data points to yield a more accurate risk assessment. As a result, only a small percentage of 3DS 2.0 users need to take an extra authentication step, often in the form of an OTP.

Image comparing the old and new 3DS processes. The original 3DS required all shoppers to authenticate their identities with static passwords, often entered in a pop-up window or redirect site. The 3DS 2.0 process shows more  authentication steps happening automatically and in parallel with the shopper's checkout process, rather than slowing it down. These authentication steps include icons representing buyer location, devices, shopping history, current purchase, time zone, and biometrics.
3DS 2.0 uses passive authentication features that free most shoppers from extra steps during checkout.

Uber

3DS 2.0 is an example of reducing product friction through iteration. But you can also reduce friction at an industry level by introducing disruptive products.

Uber’s business model is built on subtracting friction from a traditional taxi ride. With Uber, there’s no more waiting on hold with a cab service or rummaging through your wallet at the end of your trip.

A seamless payment process was key to the company’s early success, but it came with some risks. Each time Uber automatically processes a transaction on a credit card stored in its app, it risks a chargeback (in which a cardholder disputes a transaction and receives a refund).

However, Uber calculated that the cost of these potential chargebacks was worth the opportunity to optimize the user experience. If a user had to dig out a credit card or enter a password each time they called for a ride, the whole business might have failed. Instead, Uber accepted risk over friction and the service took off.

In both of these examples, a user-centered product management approach that also weighed security and risk resulted in groundbreaking and profitable innovations.

The Best Maintenance Is a Good Offense

Frauds want to stay one step ahead of product teams. While other types of development can react to shifting requirements, secure software projects need to anticipate them. This means product managers must read industry literature and leverage data from multiple clients to learn from past security breaches and successful deflections.

Your product team should provide regular threat landscape reports and cross-reference them with your client’s experiences and requirements. Not every new threat will warrant a product update. Maybe your team has identified a new type of attack that your UX doesn’t protect against, but a discussion with your client reveals that it isn’t relevant to their threat environment: One banking client in South Africa may be dealing with a rash of SIM-swap fraud, while another in New York might be experiencing more attacks from hackers using VPNs. In most cases, it wouldn’t be cost-effective—and would introduce unnecessary UX friction—to protect both banks from both types of fraud.

As a product manager, your role requires constantly adjusting features to ensure that you aren’t trading security for a delightful user experience or vice versa. And while you’ll need lots of data to truly understand your clients’ and end users’ needs, the rest of this balancing act is a mixture of trial, error, and art.

Understanding the basics

Design friction occurs when a design slows down interactions with the product, either intentionally or unintentionally.

Friction in UX design refers to features that complicate a user’s interaction with a product. Friction can take the form of confusing design or extra steps between a user and their objective. While some friction can be necessary and intentional, too much friction can cause a user to abandon a product.

Good UX design improves compliance with security measures and ensures that companies don’t lose frustrated customers due to a clunky interface.