How to avoid designing for current users at the expense of future ones

Three tips for balancing current and future user needs

Photo by Igor Omilaev on Unsplash

“We haven’t had much time to think about UX, but it works for our current customers.” The Project Manager said, signaling a tricky design scenario.

We were conducting a project overview, and I was left with far too many questions. The interface was crammed with too much random information, so I wasn’t surprised when he said that.

Sometimes businesses cater to their current customer to the detriment of future potential users. This can result in seemingly hopeless scenarios for designers (i.e., designing quick fixes without addressing significant issues).

However, your designs can still have a significant impact if you persuade the right people to take action. But it starts with understanding the tension between current and future users.

Businesses avoid risk, which means they might do what users say

If a company was paying you $1 million annually in revenue, wouldn’t it be best to cater to their every need?

That’s the question you must understand to comprehend how these hodge-podge applications get built. If current customers are paying you a lot, businesses will try to bend over backward to accommodate them.

They’ll set up dedicated account managers, sometimes even giving personal e-mails or phone numbers, to ensure that this current customer is happy.

So, it’s unsurprising that if a customer asks you to build a feature, your company often wants to accommodate them.

However, the problem is, in many of these scenarios, UX isn’t involved; Sales is. Sales aim to increase revenue and incentivize customers to either sign the contract or continue paying us.

I talked about how this can lead to a lot of havoc within the UX and Product teams with new customers, but there’s one other important aspect: they may be taking what customers say at face value.

UX doesn’t take user suggestions at face value. Others might.

If your customer asks for “a dashboard like competitor X,” UX professionals know better than to take that at face value. We might ask many questions to understand the underlying need, what they want from it, and more.

However, other team members, like Sales, might not. They may interpret that to mean we must design exactly what the customer wants.

As such, we might end up with a random dashboard with little purpose behind it because a customer thought it looked nice.

AI-generated dashboards are about the level of thought I’ve seen around dashboards before (Art by midjourney)

This was the type of feature mishmash I saw at the demo. Random pieces of information were thrown on there to fit a specific use case of a current customer. As a result, the new user experience seemed incomprehensible.

This is a more common problem than you might think. In his book Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, Steve Krug recommends making a home page tour with any usability testing you do.

This is because the Home Page often becomes a dumping ground for “Current customer needs for specific projects,” meaning that future users are alienated and isolated the first time they try to use your site.

So, how exactly do you combat this? Well, it’s a bit tricky because your traditional arguments might not work. But to do this, you must first create enough wiggle room to design something that suits current and future users.

Create wiggle room around feature requirements

It’s tough to argue directly against implementing a feature. Your design idea will not win against the tradeoff of “We didn’t build exactly what the customer wanted, and they’re unhappy, so they canceled their $1 million/year contract with us.”

That’s unlikely, but that’s a concrete risk in your team’s mind. On the other hand, future users are a vague sentiment that can be hard to design around.

So, one of the most important things to do is to create enough wiggle room in your requirements to design something that won’t scare new users.

This is often most effective at a user story level, where you ensure your Agile backlogs are filled with user-centric instead of feature-centric requirements.

For example, a customer might say, “I want to filter and sort results in a large, well-organized table.” The first part of that sentence is what we should focus on while trying to steer clear (as much as possible) for the second part.

We want to ask enough questions and understand the motivation to be able to re-phrase that as “User needs a way to quickly narrow down a single data point, as they’re often working with thousands of data points.”

Doing so allows us to try different design patterns, such as tables, cards, visualizations, etc. On the other hand, if the story is written that they “want a table,” and you deliver something else, they may be unhappy that you didn’t do what they said.

Creating this wiggle room also allows for talking more directly with the customer. Rather than getting your requirements from word of mouth, continually asking these questions of your team (and having them unable to answer) may get them to approve of your talking directly with customers.

However, sometimes the feature request is so bad that this wiggle room isn’t enough. This is when you can use Sales demos and visceral design to your advantage.

Use Sales demos (and visceral design) to your advantage

Future customers come from many different companies, environments, and contexts, so it is hard for your team to prioritize their needs. We may create personas that capture their characteristics, but no one customer will be an exact match for a persona.

However, having them prioritize Sales demos is a different story. Potential customers may be scheduling demos with Sales representatives and walking through a sample version of your product at any time.

This product version for walkthroughs is limited, stable, and polished. After all, think about how poor your customer’s first impression would be if your application crashed or looked unfinished.

You can use this idea to your advantage if asked to design an unnecessary or unwanted feature. The idea is simple: imagine Sales is on a call with a customer, and they’re demoing some features.

The customer looks at the demo and immediately thinks it looks ugly or overcrowded.

The first thing customers notice is how ugly/overcrowded something like this is

Consciously, they may listen to the explanation of features, which is what they need. But they subconsciously are repulsed by it.

https://uxplanet.org/3-layers-of-emotional-design-every-product-designer-must-know-dc0179200603

This is called Visceral design, the 1st layer of Emotional Design, and it happens nearly unconsciously. At this level, if the person is overwhelmed or feels negatively about your product, it can be hard to overcome this feeling.

It’s not just Sales demos: it could be the Product team (or executives) showing off future features to customers or more. This is the strongest argument to avoid designing certain features by linking them with the concrete scenario of the Sales call.

While it’s true that some features could be hidden for these purposes, if you talk about how bad of a first impression this feature will provide, then your team may change their minds about its priority.

Many times, to avoid these tricky scenarios, all you need to do is persuade a vital member of the Product team.

If all else fails, work with the product team to get them on your side.

Lastly, having someone advocate for you is an excellent way of ensuring your viewpoint is heard. Likely, these feature promises aren’t just causing you headaches but also causing issues with the Product team.

So, talk with the product team and gather evidence to point out the downside of taking these actions. The most common data sources in these cases are competitive research, customer surveys, and more.

The idea is to help form a more solid case around the downsides of taking current action, which otherwise might be vague.

The more you can explain how this may hurt the business, our users, and our relationships in the future, the more likely we are to avoid being led around by your current customers.

Creating advocates of the product team can help them fight for you and help you craft a better argument against it.

A bird in the hand isn’t always worth more than two in the bush

That expression is meant to express how you should be content (and care for) with what you currently have rather than chasing future gains.

However, that’s not how the world of business works. Pleasing your current customers while alienating future ones through increasingly poor design can often lead to businesses failing.

That’s because there’s no guarantee that your current customers will always be able to support you. Whether due to other Salespeople convincing your customers to switch or your customers going bankrupt, it’s dangerous to over-rely and cater only to your current customers.

So, if you’re being asked to design for current customers at the expense of future users, here are some tips to navigate this tricky situation. Doing so may allow you to design features that appeal to current and future users.

I’m creating a Maven course on Data Informed Design! If you’re interested in learning (or would like to provide feedback), consider filling out this survey.

Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.