Users are clearly frustrated: A billion-dollar design lesson

In 2011, IDEO's Tom Chi showed a photo during a TEDx talk. In the photo, a user frowned and curled his lips before touching the screen, his expression full of frustration. Tom Chi used this photo to start sharing about rapid prototyping and design thinking. No one expected that this ordinary snapshot photo would later become one of the most cited pictures in the entire product design industry-not because of how well it was taken, but because of the expression of the person in the photo. It accurately hit the most common, expensive, and easily ignored problem in the technology industry over the past decade: users won't even know how to use what we create, or they are so angry that they want to smash the device after using it.

The sentence "The User Is Visibly Frustrated" has since become a cultural symbol. It is not just a footnote to a speech, but a mirror that reflects the most basic things that countless technology companies have forgotten in the pursuit of functional iteration, growth indicators and technological innovation-what are users experiencing? What do they feel? Why did they give up?

This article wants to talk about this topic seriously. Not to worship it as a golden sentence, but to use it as an entry point to explore why user frustration is still common today, even intensified in the AI era, and what we can do to really change this situation.

1. How can a photo become an industry consensus

Tom Chi was in charge of a project called "Design for Change" at IDEO. Instead of using complex user research reports, heat maps and transformation funnels, he simply held up a photo. The user in the photo is facing a touch-screen interface, and the interface designer obviously believes that the interaction is intuitive-the finger swipes, the icons respond, and everything is elegant. But the user seemed to have no idea how to operate it at all. His fingers hesitated to test on the screen, his attitude stiff and confused.

The reason why this scene resonates so strongly is that almost every product owner has experienced similar situations. You spent three months polishing a function, and everyone nodded and approved it at the review meeting. The design specifications were perfect, the code was implemented gracefully, and the test cases were all green. Then the product went online, the first batch of real users arrived, and the complaints received by the customer service filled the work order system within two hours. The user said,"Where is this feature? "" Why can't I find it? "" I ordered and didn't respond. Is it broken? "--And you stand in front of the big surveillance screen, look at the real-time data, and realize for the first time: users are obviously frustrated, and your design doesn't touch them at all.

According to public research by the Nielsen Norman Group, there is a 60% probability that the first point of confusion users encounter when using a product will cause them to simply abandon the current task rather than try to find another solution path. This is not the user's fault, it's a cognitive gap between product designers and users-you know your product too well that you can't truly simulate a "first meeting" user perspective. The reason why this photo is alive is because it embodies the problem: a real person, with real confusion and emotions, standing in front of our carefully constructed digital world, and our digital world has failed him.

2. Why is the question of "user frustration" still unanswered

It sounds ironic. User experience (UX) has existed as a professional field for thirty or forty years. The methodology of Design Thinking has been taught in Silicon Valley for twenty years. There are tools such as user research, usability testing, A/B testing, and Net Recommended Value (NPS). However, the phenomenon of "users are obviously frustrated" has not only not disappeared, but has even become more and more intense in some areas.

One core reason is that in the product decision-making chain, the voices of real users are systematically filtered out.

In most companies, the path of user feedback is as follows: users encounter problems �?customer service receives complaints �?work orders are summarized to product managers �?product managers after screening and submitting weekly reports �?weekly reports are discussed at product review meetings �?In the end, only 20% of the issues are marked as "high priority" �?engineers spend 30% of the time fixing �?the remaining issues are classified as "won't fix" or "need to be evaluated next quarter." In this chain, the user's original emotions-the confusion of frowning, the anger of wanting to drop the mouse-are translated into numbers such as "conversion rate dropped by 3.2%" during the transmission process, diluted into statistical percentile.

To make matters worse, many companies don't even rely on real user feedback. They rely on data analysis-DAU (Daily Active Users), Retention rate, page stay time. These metrics are certainly valuable, but they have a fatal blind spot: they can only tell you what users have done, not why they have done or why they have not done it. A user left during your registration process. What you see in the data is "bounce out", but what you don't see is that he stared at the phone screen and sighed three times before leaving, and then opened a competitor's app. Data records behaviors and filters emotions. The frustration in Tom Chi's photos is hidden in the filtered emotions.

3. Neglected signals: the hidden costs of user frustration

Many managers didn't realize how frustrated users were until the problem broke out. But in fact, signals of user frustration have long existed, but they have not been read correctly.

Pausing and hesitation during use is one of the most easily ignored signals. When a user stays on a certain interface for an unusually long time, or clicks on the same area repeatedly, it often means that the prompts in this area are unclear or the operation path does not conform to the user's mental model. But because this behavior does not trigger any "errors," most product monitoring systems do not proactively alarm. What the product team sees is that "the user's conversion rate is normal in step 3" and does not analyze how confusing the user's mouse trajectory is in step 3.

Unloading rates and the delayability of bad reviews are another issue. There is a long time lag between users "starting to feel depressed" and "deciding to uninstall and write a bad review." According to Qualtrics's industry research data, after experiencing a negative experience, users need to experience an average of 2.7 same negative experiences before choosing a complaint or a negative review. This means that when you see the App Store rating drop from 4.5 to 3.8, the problem has accumulated for months, but it has just been silenced.

There is a more hidden cost: Frustrated users can be contagious. In the social media era, if a user's angry experience is shared, it will not just affect him. J.D. Power's research shows that an dissatisfied user will tell an average of 9 to 15 people about their negative experiences, and on Social networks, this number can be amplified tens of times. The loss caused by a design flaw is often not the loss of users, but the erosion of the trust of the entire user group it represents in the product.

4. Real case: Two different outcomes of user frustration

Case 1: A newbie of a financial technology company guided the revision

In 2022, a medium-sized domestic financial technology company launched a new version of the interface of a financial app. The product team conducted a lot of internal reviews when designing the new version. The UI style was based on industry benchmark products. The interaction fluency was optimized for three rounds, and the code quality was controlled by senior engineers. The first week of launch was calm and peaceful. Everything in the data indicators is normal and even slightly improved.

But two weeks later, customer service began receiving a large number of complaints. The user said: "I don't know how much the wealth management products I bought are worth now. "" Why can't I see my yield curve? "" What do the numbers on this page mean? "The product team initially thought it was an individual difference between a few users, until they really went to the users-not looking at the data reports, but going to the office of an offline financial consultant to observe how real users used the app.

They saw the expression in Tom Chi's photo. The user stared at the screen, his fingers hanging in the air, not knowing where to click. One of the users was an aunt in her fifties. She said to the financial consultant,"I don't understand your software. Last time, I thought I lost 300 yuan and couldn't sleep. Later, I learned that the number is cumulative income. "The consultant smiled bitterly and said that she would listen to such feedback several times a day.

Only then did the product team realize the problem: the new version of the interface hides the "Account Overview" into the third-level menu, while the old version of the "My Assets" entry that users were accustomed to has been redesigned into an inconspicuous card. Users can't find where their money is, which is the most unacceptable mistake in financial management scenarios-once the sense of trust is shaken, users will not only lose, but will also tell all friends around them about it who are preparing to manage their finances.

The team then spent three weeks redesigning the information architecture, restoring the account overview to the first screen, adding colloquial explanation tabs next to key data, and adding a lightweight tutorial called "Guide to First Use". After launching, the NPS (net recommendation value) increased from 31 to 47 in six weeks, and the number of customer service orders dropped by 40%. This project was later summarized internally as a lesson: the data tells you that "the function is normal," but only by standing next to the user can you see "whether the function is understood."

Case 2: Optimization of the checkout process of an e-commerce platform

It is also a problem of user frustration, but another home appliance company platform has chosen a completely different response. Their data analysis team found that the successful conversion rate of shopping cart-to-payment on the mobile side was 15 percentage points below the industry average. The team spent two months doing multiple rounds of A/B testing, testing variables including button color, copywriting wording, page layout, and even font size. Test results showed statistically significant improvements in some changes, but the overall conversion rate never exceeded the bottleneck.

Finally, they hired an external usability testing team and spent three days recruiting 20 real users to conduct in-depth interviews and task testing. During the testing, a problem was discovered that the A/B testing could not capture at all: users frequently encountered an interaction of "entering a coupon code" during the checkout process-this interaction itself was fine, but its location and visual design made 70% of test users mistakenly think it was a required item. The user didn't know whether his coupon code could be used, and didn't want to fill in an invalid code and cause the order to fail, so he stopped at this step and repeatedly checked the order confirmation page to try to figure out "Do I have to fill in this?"

In fact, this field is optional and not filled in will not affect any subsequent processes. But the message was never clearly conveyed. The product team changed this field to an obvious "optional" tab and added the placeholder "No coupon code? Just skip it." After the changes were launched, the checkout conversion rate increased by 11% in two weeks, which is more obvious than the combined effect of all A/B tests in the previous two months.

The lesson from this case is: A/B testing optimizes known variables, but the real confusion point for users is often that you don't even know the variable to test. Only through direct user observation can you discover the problems hidden in "user assumptions."

5. Methodology comparison: The advantages and disadvantages of four user insight paths

Faced with the problem of "user frustration", different teams have different ways to deal with it. I have compiled a comparison framework to help you understand the application scenarios and limitations of various methods.

The core point of this table is that no one method is a panacea. Data analysis tells you "what went wrong" but cannot tell you "why"; questionnaires tell you "what users think", but users themselves often cannot explain their own behavioral motivations; usability testing can accurately restore the operating process, but there is a gap between the laboratory environment and the real use scenario; on-site observation is the closest to reality, but the cost is high and the speed is slow.

A mature product team should use a combination of these four methods rather than relying on a single path. But the reality is that most teams only use the first one and then wonder why the problems are always endless.

6. New challenges in the technological era: AI has not made users frustrated and disappeared

There is a view that with the development of AI technology, products will become more and more "smart", and the problem of user frustration will naturally be resolved-products will actively adapt to users, guess users 'intentions, and reduce users' cognitive burden. This vision is in the right direction, but the reality is far better than this.

Big Language Model (LLM)-driven product interfaces are creating a new type of user frustration: Users don't know how much AI understands. Traditional software interactions have a relatively stable contract-you click this button, it does it. But AI products are different. The user asks a question and the AI gives an answer. The user is not sure whether the answer is accurate or fabricated, whether he should believe it, and whether he should ask it again. This uncertainty itself is a deep frustration.

According to a 2024 O'Reilly technology adoption survey, 43% of developers who have used AI assistive tools (such as AI writing assistants and code generation tools) said they spend a lot of time "verifying whether the AI output results are correct"-sometimes even more than the time they spend completing tasks directly without AI tools. This data has not been widely reported, but it reveals an important truth: AI lowers the threshold for starting task completion, but increases the cost of quality verification of task completion. Users didn't feel more relaxed, they just shifted their energy from "doing things" to "checking things."

Another unique user frustration in the AI era comes from "over-personalization." Recommendation algorithms are becoming more and more precise and personalized, but users are beginning to feel a faint uneasiness: Is the content I see filtered by the algorithm? Is the news I saw true? This concern about "information cocoons" is becoming a new emotional burden on users, especially in news and content consumer products.

7. Guide to pitfalls: Common design traps that frustrate users

Combining industry practice and real cases, I summarized the five most common user frustration traps that are easily ignored by teams.

Trap 1: Treat "rich functions" as "excellent experience." When product managers introduce new functions at review meetings, they often take pride in "we have added XX functions." But users don't care about the number of functions, they care about "whether this function can help me do what I want to do." An App with 200 functions but the core operating path is not smooth is far worse than a product with only 20 functions but each function can be quickly found and started by users. Functional expansion is a natural result of team expansion, but it is a chronic poison to the user experience.

Trap 2: Treat "user guidance" as "user education." The first reaction of many products after being criticized by users as "difficult to use" is to add guidance pages, tutorial videos, and prompt pop-ups. But guidance is passive, and users are reluctant to actively learn from your product-they expect the product itself to intuitively tell them how to use it. If a function requires three-screen guidance to be understood, the design of the function itself is problematic. Guidance should be a remedy, not a regular solution.

Trap 3: Treat "good data" as "user satisfaction." Some product designs deliberately induce users to do certain behaviors to make the data indicators look good, but the actual experience of users is negative. For example, the "unsubscribe" button is designed to be extremely hidden so that users can't find it, thereby reducing the cancellation rate. This data is really good, but users will feel a great sense of anger when they discover it. This anger often takes the form of public negative reviews and social media complaints, which far exceeds the loss numbers it "saves".

Trap 4: Treat "all peers are doing it" as "user needs." Competitive product analysis is an important part of product planning, but many teams have turned competitive product analysis into a "function comparison table"-competitive products have this function, and we must have it too. In this mindset, products become an arms race, with users facing a collection of functions that "others have, so we have" rather than a solution that truly understands their needs.

Trap 5: Treat the "internal perspective" as the "user perspective." When the product team reviews the plan, the default perspective is "We know how to use this function," so we think it is clear. But a new user who has never seen this interface has a completely different cognitive path than yours. The easiest way to check is to send the interface you designed to a friend who doesn't know your product, let him explore it for three minutes, and then ask him three questions-"What do you think this interface does? "" What do you do first when you want to complete a task? "" Where are you stuck? "--These three minutes of observation are often more revealing the truth than three days of data analysis.

8. Who should really care about "user frustration"

The product manager is the first person responsible for this matter. User frustration is essentially a product decision issue-are features prioritized correctly? Is the information architecture reasonable? Are key nodes in the user's journey fully considered? The way of thinking that product managers need to establish is not "whether this function can be technically realized", but "what are the user's psychological expectations in this scenario and whether our design meets this expectation."

Designers need to jump out of the single dimension of "visual aesthetics" and participate more in the user research process. The value of design lies not only in making the interface look good, but also in making the interface easy to use-and the standard of "ease of use" is not set by the designer himself, but defined by the user. Designers should incorporate "user observation" into a regular part of the workflow, rather than just doing a competing product analysis once at the start of the project.

Engineers are often excluded from "user experience" discussions, but this attitude is problematic. The root cause of many users 'frustration lies at the technical implementation level-slow page loading, delayed button response, vague error messages, and no feedback on submission actions-these are details that engineers can directly influence and improve. Google research data shows that for every 1 second increase in page load time, the user churn rate increases by about 20%. This number is a result of direct influence by engineers.

Managers and executives need to realize that user frustration is not a problem that can be compensated by adding features or increasing marketing investment. When users feel frustrated, their trust in the brand has been damaged, and the cost of rebuilding this trust is often five to seven times the original cost of acquiring customers (according to industry estimates by the Harvard Business Review). Investing resources in front-end user research and experience design is an investment with a very high rate of return, rather than a "cost item" that can be compressed.

9. Advanced practice: making "user frustration" an actionable signal

It is one thing to know that problems exist, but it is another to truly turn problem identification and resolution into a daily process. Here are some practical methods that have been proven effective in mature product teams.

First practice: Create a "Frustration Log". This does not ask you to build a complex feedback system, but requires the product team to record three factors after each user research, usability test, or customer service communication-what problems have the user encountered? In what scenario did this problem occur? If it is not repaired, what is the worst consequence? After three months of recording, you will have a clear understanding of the distribution of user frustration, and you will see which problems are high-frequency, which are fatal, and which are temporarily acceptable. This log does not require any data analysis tools, a shared document is enough.

Second practice: Introduce the "Five-Second Test". Before launching any new features or new interfaces, find 5 users who are unfamiliar with the product, show them screenshots for 5 seconds, and then ask three questions: What do you think this interface does? What will you do next? Do you think the next step is difficult? This test is extremely low-cost, but it can quickly expose problems that are "too familiar to be seen" for designers. The operating process and scoring standards for this method are detailed in UX Planet's tutorials.

The third practice: Incorporate the "user frustration rate" into the product indicator system. Most product teams have indicators such as Retention rate, conversion rate, and DAU, but none of them directly measures "whether users feel frustrated during use." You can design a simple signaling system: task completion rate (whether users can complete tasks independently without help), help rate (whether users frequently use the help portal or contact customer service), and abandonment rate (at which node users abandon operations). Taken together, these three numbers are a proxy indicator of the "user frustration rate." It's not perfect, but it's much better than nothing.

Fourth practice: Regular "Blind Testing Days"(Dogfood + Mystery Shopping). Let team members use their products just like a normal user-don't open test accounts, don't skip novice guidance, don't use internal feature entrances. You will be surprised to find that users experience ten times as difficult as you yourself at the points of interaction that you find "a little troublesome." At the same time, using competitors 'products regularly is an effective exercise-you will find that the way competitors solve the same problem often brings you new ideas.

10. Conclusion: Translate "frustration" into "action"

Back to that photo. Tom Chi shows that more than a decade has passed, and the technology industry has made great progress in user research methodologies, interaction design specifications, and data analysis tools. But the scene in that photo-a real person frowning in front of the interface, not knowing what to do-still happens every day. In your App, in your website, in the products you are proud of.

This is not a technical issue, not even just a design issue. This is a fundamental question about "how much do you care about your users."

User frustration is not inevitable. It can be discovered, measured, and repaired. The premise is that you are willing to walk up to users, not at their data, but at their faces. Instead of analyzing their behavioral trajectory, listen to their confusion and complaints. Instead of using "users first" as a slogan, we use it as the first filtering condition for every product decision.

The next time you design a new feature or revise a page, ask yourself a question: If the user frowning in front of the screen were your friend or your family, would you think your design was worthy of him? If the answer is no, it's worth another round of change.

This is not the pursuit of perfection, this is the most basic respect.