How to handle conflicting user preferences when building custom software

Ten years ago, the company formerly known as Twitter made a huge change to its block feature. Instead of being able to prevent others from following, DMing, or tweeting at them, users could only hide tweets from offending accounts. The thinking: users could filter out negative tweets without alerting blocked accounts—a huge concern for frequent targets of harassment.

But thousands of other users actually felt safer with the original block functionality. And the sudden change sparked so much outrage that Twitter reversed the update that very same day. (A few months later, the company repackaged the “hide tweets” feature as a separate mute button.)

Most companies won’t have a product crisis as dramatic as Twitter’s. But many will encounter the underlying problem: conflicting user preferences. When those preferences clash, it’s important to have a strategy for how to move forward in a way that works for users and the business.

In this piece, we’ll lay out three steps to take when users want different things from your custom software.

1. Understand user needs versus user preferences

We talk a lot about the value of gathering user feedback at every stage of your product design: it’s the best way to build a product that users love.

Throughout that process, you’ll often learn about concrete needs related to your product’s functionality, like the ability to save work in a text editor.

But you’ll also learn about more general user preferences, like whether users prefer your software in light or dark mode. While neither design choice affects functionality, they have a tangible impact on user satisfaction. And like many user preferences, they can affect your product’s accessibility (e.g., for people with color blindness or light sensitivity).

Of course, users don’t always have the same preferences; there might even be a 50-50 split. And if you’re building an MVP from scratch, you can only build one version of your product—which means you’ll have to choose one preference over the other.

To help you make that decision, let’s take a look at a three-part framework.

2. Weigh each preference based on cost, perceived user value, and strategic value

To decide which preference to move forward with, consider evaluating each one based on three factors: cost, perceived user value, and strategic value. The preference you ultimately choose should win on most or all of these metrics.

When assessing each preference, make sure to ask questions like:

• How much time, money, and effort will this take? The more code you have to write from scratch, the more expensive a preference becomes. But there are other factors to consider. In the case of light versus dark mode, for instance, building both can be costly. Will those costs be justified by the gains in user satisfaction?

• How many users actually want this? If you prioritize a preference that only satisfies a handful of your users (like Twitter did with its change to the block feature), you could wind up having to reverse course later—and grapple with user fallout as well.

• Could this decision help you achieve other strategic goals? For instance, if 50 percent of your users prefer dark mode and your CEO happens to use dark mode on every device, prioritizing dark mode could be a valuable strategic move. By satisfying half your users and your CEO, you might earn support or favor for future product decisions.

Depending on your analysis, you may decide on a final preference (e.g., only dark mode) or simply prioritize one for the MVP before gathering feedback and iterating. No matter your decision, it’s important to make sure the rest of your stakeholders are on the same page—a process we’ll explore in the next section.

3. Use data to align stakeholders with your path forward

Sometimes, business stakeholders have strong preferences themselves. If those preferences conflict with users’, these stakeholders may push for what they want rather than what users want.

In these cases, user data can be a powerful persuasive tool. For example, let’s say that you want to implement a user preference for a toolbar at the top of your app, even though business stakeholders think it should be at the bottom. You could perform a heat map test (using eyetracking) to see where users start their navigation journey. If 90 percent of users start at the top of the page, that’s a clear sign that they expect a navigation pane in that location.

Of course, data isn’t infallible; it can always be challenged. But in most cases, it’s a highly convincing way to argue for a user preference and align your stakeholders.

4. Maintain a strong user feedback loop

Even with the best of efforts, no product will satisfy every user preference. But it’s important to keep a constant eye on user satisfaction. If there’s an outcry over a product decision—as there was at Twitter—you’ll want a mechanism to quickly measure the scope and respond if needed.

In practice, this means more than simply maintaining a user feedback form. Make sure you have an efficient way to…

• Let users know you’ve received their feedback.

• Confirm that their feedback has reached the right team.

• Follow up with next steps and a final decision.

That last point is crucial. Whether or not you choose to update your product, users still deserve to know the outcome of their feedback. Ignoring them will breed more discontent and ultimately sour the user experience.

Also worth noting: if you’re getting a lot of similar feedback about a user preference (like the inability to toggle light and dark mode), it’s probably worth acting on it quickly.

But take the time to question your own assumptions and hesitations. Widespread concern means that users aren’t getting the most value from your software—regardless of whether you agree with their feedback. By listening to your users, you can remove barriers to satisfaction and boost your product’s adoption.

A scalable product foundation makes it easier to pivot

No one wants to make the wrong decision about user preferences, especially if it could be costly to walk back. But with a scalable product foundation, it’s easier to pivot when needed without wasting time and money—and you can avoid leaving users frustrated for days on end.

One of the best ways to build that product foundation: work with a partner that can help you identify a product design and architecture that you can scale.

Of course, the right partner won’t take a prescriptive approach to this process. They’ll walk you through the tradeoffs of even the smallest product decisions so you can chart a path that minimizes costs. This way, you can confidently accommodate user preferences with the knowledge that you can change tack at a low cost.

If you’re looking for a partner with this kind of mindset, let’s start a conversation. We’d love to hear from you.