{"id":6069,"date":"2014-12-18T03:17:56","date_gmt":"2014-12-18T10:17:56","guid":{"rendered":"http:\/\/proxystudio.uxpin.com\/?p=6069"},"modified":"2024-09-09T07:39:22","modified_gmt":"2024-09-09T14:39:22","slug":"bad-ux-makes-users-blame","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/bad-ux-makes-users-blame\/","title":{"rendered":"How Bad UX Makes Users Blame Themselves"},"content":{"rendered":"

We don\u2019t do well with uncertainty.<\/p>\n

When things go wrong, we want to know why as quickly and easily (but maybe not truthfully) as possible. But when technology is thrown into the mix, the problems are more complex. Our perceptions change. When something goes wrong with a user interface, the questions don\u2019t always have easy answers.<\/p>\n

<\/p>\n

It\u2019s the designer’s job to connect and empathize with the user, to teach them the language of design, to put MVPs<\/a> in their hand, test, talk, and arrive at a solution.<\/p>\n

Designers aren\u2019t there just to make digital products beautiful, but to make people feel good when they use them\u2014 especially when things go wrong. Let me explain a situation from my own life in which the design failed, but I ended up blaming myself instead of the website.<\/p>\n

How I paid the government to make me feel stupid \u00a0<\/b><\/h2>\n

A few years ago, when I was working as a freelancer, I used the UK government\u2019s web interface<\/a> to pay my taxes. The term \u201cused\u201d is employed rather loosely here, as most of my time involved clicking everything that might have applied to me until I saw some words that looked vaguely familiar, and then running with it to the best of my ability, hoping an angry letter wouldn\u2019t arrive at my door a few weeks later.<\/p>\n

Throughout this entire process (which was advertised as quick and simple), I was made to feel stupid for not being able to navigate the interface, with robotic language and a journey in which I always ended up where I started. It \u00a0wasn\u2019t my fault and yet, for every error, I blamed myself.<\/p>\n

\"Bad<\/a><\/p>\n

I felt as though, somehow, I should have been able to figure it out.<\/p>\n

Retrospectively, I understand that the responsibility is not mine. An online web service that collects taxes should pride itself on simplicity and ease of use. I should always know where I am, how I got there, why<\/i> I got there, and how to go back. My feeling incapable, lost, and insecure was a failure of the interface\u2014 it overwhelmed me, and offered no help.<\/p>\n

It didn\u2019t have to be beautiful; you don\u2019t need to make taxes sexy or perfectly kerned, but you do need to ensure that users feel taken care of at every stage of the process. After all, I\u2019m trying my hardest to give you my hard-earned money\u2014 surely, this is the time to make someone feel safe and secure. Instead, I felt woefully underprepared, as if I should have studied how to use the interface before using it.<\/p>\n

So who should we blame for bad UX?<\/b><\/h2>\n

When it comes to figuring out who is at fault for the problem and who should fix it \u2014 you would think the answer was easy: it\u2019s the interface designer\u2019s fault, so that person must fix it. Surprisingly, though, users (like me) tend to blame themselves. I didn\u2019t create the interface and had \u00a0very little input. So why the self-blame?<\/p>\n

\"Bad<\/a><\/p>\n

Don Norman<\/a> explains this concept of blame very well in The Design of Everyday Things. He describes how susceptible we are to blaming ourselves rather than designers or developers for interface failures, and why that behaviour is wrong. Trying to restate his work here would be silly (if you haven\u2019t read the book, you definitely should), but the psychological processes are complex, contradictory, and fascinating.<\/p>\n

We hate uncertainty, and we\u2019ll do anything to escape it, as quickly as possible\u2014 even if it means lying to ourselves.<\/p>\n

What\u2019s happening in the user\u2019s mind?<\/b><\/h2>\n

Our brains play tricks on us to make the world easier and more pleasant to navigate.<\/p>\n

One of these tricks, the self-serving bias<\/a>, leads us to attribute negative outcomes to the outside world, \u00a0for the sake of our self-esteem. Conveniently enough, this same bias makes us think that anything good that happens is a result of our own personality. If we fail a test, then the test was too hard. But if we ace the test, then surely it\u2019s because we studied hard. The self-serving bias holds true in employment, in sports, in almost anything \u2014 except computers and their applications.<\/p>\n

\"self-serving<\/a><\/p>\n

In certain human-computer situations, users can sometimes show a tendency to attribute success to the computer and blame themselves for a failure, when they should do the exact opposite. This is complicated by many factors \u2014 age, degree of control, and even gender\u2014 but the \u201cI\u2019m bad at technology,\u201d adage continues to persist.<\/p>\n

It\u2019s so common that it\u2019s accepted as an excuse without question. Instead of allowing themselves to say, \u201cthis isn\u2019t intuitive,\u201d users may feel guilty, taking responsibility for that failure when the fault lies with the designer. \u201cIt isn\u2019t intuitive,\u201d \u00a0isn\u2019t a neat solution that removes the uncertainty, but blame is final.<\/p>\n

It\u2019s not you, it\u2019s the designer.<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Let’s break down exactly why this self-blame still happens:<\/p>\n

1. Computers are still ambiguous to some users.<\/b><\/h3>\n

People have conceptual models (mental simulations) of how computers work that aren\u2019t necessarily true, but they\u2019re good enough. That is, until something goes wrong.<\/p>\n

If your user is confused by the error, and it doesn\u2019t fit anywhere within their conceptual model, that\u2019s stressful. The path of least resistance is to blame themselves. It\u2019s faster than trying to comprehend how the application works, and how they arrived there. They\u2019re a user, after all, not a QA tester.<\/p>\n

2. We are susceptible to the <\/b>aesthetic-usability effect<\/b><\/a>.<\/h3>\n

If it\u2019s pretty, we must be able to use it and if we can\u2019t, it\u2019s our fault. Ello is a recent example: a beautiful, minimal interface that turns out to be a UX nightmare<\/a> due to inconsistent design<\/a>, unnecessary animations, and bugs<\/a>.<\/p>\n

3. Task-selection bias.<\/b><\/h3>\n

If we tell the user to perform a task, then they believe that they should be able to do it. If they can\u2019t \u00a0they feel guilty and blame themselves.<\/p>\n

4. Norman\u2019s concept of taught helplessness.<\/b><\/h3>\n

Because the user fails at one technological task, they now think they fail at anything related to technology. Because the user may also believe that they can\u2019t offer a concrete solution to the problem (\u201cAdjust the line-height for better readability,\u201d etc.), it\u2019s just easier to resort to \u201cI\u2019m bad at technology\u201d. It removes the uncertainty and stress faster, but it also stops them from connecting with your product.<\/p>\n

If we want to make great digital products, we can\u2019t allow users to blame themselves. It will only reinforce the idea that designers (and developers) should be able to read their minds, and prevents the user from realizing that they are one of the most important steps to a great user interface.<\/p>\n

Designers can\u2019t work in isolation. Creating beautiful, usable, intuitive interfaces is now a collaborative process<\/a>, with the end user at its core.<\/p>\n

UCD, MVP, UAT: Acronym all the solutions! <\/b><\/strong><\/h2>\n

So what can we do to prevent this?<\/p>\n

As interface and product designers, we need to humanize our process. After all, we\u2019re building interfaces for people, and they might not realize that it\u2019s actually someone\u2019s job to solve their problems and make their lives better.<\/p>\n

\"User<\/a><\/p>\n

 <\/p>\n