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.
The case:
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.
Where was the failure?
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.
The Ghost problems
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.
What did I learn?
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.
This is a simple documentation template we ideate to consider the complexity variable in any project.
The template above identifies some possible complexity levels in products that need proper expectation coverage. I recommend always asking users how difficult it was to accomplish a goal in usability tests; this way, you can measure the level of complexity after a session.
Low product complexity: the action itself explains the product usage.
High intuitiveness and easy adoption.
Some objects or digital products are easy to use because they don’t need a complete guide to operate; usually, their primary action is the same usage expected, so there is no surprise or misuse.
How do we identify this level of complexity? In usability tests, users can follow a path or locate the object immediately to trigger an action without any guide; it is natural to use.
Usage expectation: high intuitiveness and easy adoption. Usually, these objects only cover one action, limiting the usage spectrum.
Medium product complexity: Usage discovery and adoption.
These products become an extension of your daily routine.
These products require some practice to operate correctly. An excellent example of this medium-complexity product might be social media or chat platforms; at first usage, you may not be an expert, but with time, these products become an extension of your daily routine.
How do we identify this level of complexity? In usability tests, users can stumble at the beginning of the task but can figure out how to proceed with some exploration. Sometimes, they may ask for help with the minimum steps.
Usage expectation: requires practice to master its use; The spectrum of use can vary from daily to frequent use.
High product complexity: several usage options and broader error range.
You need instructions, support in time, and a learning curve.
These products require unique tasks and operation timeframes employing specific profiles or roles. In my case, the solution we launched seven months ago had all HR (human resources) professionals as primary users.
This process occurred once a quarter, sometimes once or twice a year. Since the action wasn’t constant, people’s adoption and maneuver were low, so when the time came, people got frustrated if things went wrong.
When all the complaints came to us, we realized that the frequency of job action was as important as the solution itself (see the template above). We needed to think of a “one-shot” solution that was usable enough according to its difficulty. But to get there, companionship, training, and time were necessary to optimize the experience.
How do we identify this level of complexity? In usability tests, users have a notion of the main task but not the entire picture or know-how. The process is complex, so a previous presentation or training in these scenarios is essential. I recommend asking users after a usability test how challenging the process was for them to identify sensitive parts where we may make some adjustments.
Usage expectation: You need instructions, support in time, and a learning curve.
From that episode to now, product expectations are part of our workflow. From the early stages of any project now, we add this variable to the group of metrics to evaluate. Perfecting this teaching by understanding how difficult our products are, we can now create the proper information to ensure users feel well accompanied by a relevant product.
A final thought and my new mantra I like to share with you:
Good usability doesn’t exclude instructions.
Some designers state that a good product may not need instructions; it should be intuitive enough that anyone can use it. That statement is true, but always consider the product’s level of complexity to build a correct product expectation. We can not take this idea to extremes and delegate a product’s success only to what users can do by their means.
To write this article, I want to credit all the fantastic information sources and other authors who have had the exact same reflection as me, all from another exciting perspective.
The Paradox Of Choice / JT. Alexander -FMT
Product Design: Expectations vs Reality / Eugen Eşanu
Product Design: Expectations vs Reality (part 2) / Eugen Eşanu
As with other experiences, this is only one of the many #ShortStoriesOfMyLifeAsDesigner.
The UX dilemma: do complex products need instruction manuals? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
