Launching a product hoping to change the world, or at least change how our users approach problems and grow positive numbers in companies, is rewarding. We do great work when some of these consequences become real, and we can make a difference.

Most designers measure a product’s success by combining good usability, intuitive level, or design quality. Still, one variable we often overlook in design deliverables or a product build process is the proper clarity of expectations, how much this new product will cover in terms of functionality and experience, mainly if we deal with customers outside the technology environment.

What happens when the user’s expectations don’t match the product’s usage and scope? Well, this happened with my team, and I learned a lot about the consequences of this problem. I hope this experience inspires you to consider managing expectations as an essential variable in any product’s success.

As part of the new company vision, this year, we bet on releasing new products and services to expand into new potential and attractive markets. Most of the products we launched during the last part of 2023 and so far in 2024 are highly complex because users need to manipulate extensive databases, among other actions. Even though we ran many usability tests and monitored metrics, the results weren’t as expected, especially from the perspective of user satisfaction. Seven months after the initial launch, some internal and external customers were still frustrated with the solution.

The short answer is conceptual ambiguity. When the project’s main actors explained all the purposes of creating the solution, the range of actions didn’t specify the actual functionalities and limitations to the audience, so this product could potentially do everything. With such a fussy spectrum, the level of interpretation and misunderstanding was a potential threat.

Two phenomena may cause the ambiguity of product definitions and usage expectations: the assumption of proper usage from the production chain and the user’s lack of interest in “reading the manual.” These two ingredients only lead to frustration on both sides.

What happens in the product designer’s mind

Since we spend so much time building a product, it is highly probable to “assume” people will understand how it works on the first try; that should be the goal, but it is not always like this. Sometimes, we must accompany and advise users so they obtain an optimal experience.

What happens in the user’s mind

Not having the proper information increases usage uncertainty, whether because people are not interested in understanding how something works or because there is no data about the product/service. On the contrary, having too many options also leads to decreased satisfaction related to the “paradox of choice,” created by the American psychologist Barry Schwartz in his book The Paradox of Choice: Why More is Less, which states that having too many ways to do something creates cognitive burnout and the tendency to regret our decisions eventually. The broader the range to choose, the more complex the decision. Either way, users can face friction without knowing the product’s actual range of actions, generating a particular syndrome.

Similar to phantom pain, which states humans can feel hurt in a non-existent limb, we can experience a similar sensation in digital products; in this case, it is not because we may miss a part of the body but a portion of information. When we miss information to operate an artifact, or we don’t have the range of feasible actions, we tend to explore; don’t get me wrong, this is not bad at all, but during the exploration process, we can spot possible problems beyond the expected initial product functionality translating these issues into frictions.

In the failed case above, we met with stakeholders one day to discuss how some big customers were frustrated about missing product actions. After hearing their reasons, we immediately knew where the problem was: unclear function expectations and a follow-up plan from our side to anticipate possible uncertainty. Although we knew we should not worry because all the frictions detected were part of a plan for progression and new products, we didn’t communicate it effectively, punishing one significant success key: the product reputation among final users. That was on us.

My learnings about this case include many things, like addressing a proper communication plan, but this time, including the following concept:

The higher the product complexity, the more explicit the product expectations should be.

Let’s start from the beginning; what do I mean when I say “product expectation”? It is all related to how it works and what to expect, how many functionalities are available for users, what is available in terms of experience, and what is not.

Why is this information essential? Because we can provide users with the proper amount of information to operate the product or anticipate possible frictions and doubts.

Where is this information relevant to share? If possible, from the planning stage. This way, goals and common ground among the team and stakeholders are set. Once the product is released, this information will be essential for user onboarding, strategic presentations, and instruction manuals.