UI Design Newsletter – June, 2010

On a daily basis, most of us probably repeat to ourselves the psychological truth of Julius Caesar's famous phrase "I came, I saw, I conquered" ("Veni, vidi, vici").

When approaching rush hour traffic, what do we think? (I'm here, I see the traffic, I will survive).

When approaching tax season, what do we think? (It's here, I see the forms, I'll fill them in).

When getting married, having a child, burying a loved one? (I'm here, it's happening, it will all work out).

Sheer optimism has survival value when we deal with topics where we lack expertise.

Research even shows that entrepreneurs tend to have more optimism than the general public. How else to survive the rigors of starting a business that you never started before?

But do we expect optimism alone to solve the problem of providing surgery on a brain tumor? Or solve the issues of global economic contraction?

In the case of specialized knowledge, we know we must step more carefully. We probably can abandon optimism in favor of a humble confession that someone else knows better.

So, now we can ask you this question: when it comes to solving the problems of usability, does your manager invoke "To See Is To Conquer" or do they ask "Give Me Your Expertise".

The challenge of "Expertise" vs "To see is to conquer"

I'm sure we've all had the experience of telling someone a tip about interface design and we hear the response "but that's not the way I see it – we should do it THIS way".

For example, yesterday I reviewed a corporate business application that resided in a Web browser. The home page had a search component along with other functions on the page.

I indicated to my friend who had developed the page that the user would benefit from seeing a dark border around the "action button" that triggers the search. We know this as the "default" action triggered when selecting the Enter key.

My developer friend explained his reluctance to use the darker default border because, as he said, "it's in a browser." "Browsers don't use default indicators like that", he said.

I replied, "but it's clearly an application and our users will expect to know which button gets activated when they press the Enter key."

Without repeating our entire conversation, I must admit there were elements of truth in his observations. For example, I just now checked the Google search page, and see that indeed, there is no default symbol around the "Google Search" button that distinguishes it from the "I'm Feeling Lucky" button.

What was the Google designer thinking? Well – in such a simple case, it just didn't matter! (Or maybe, they just didn't think about it.)

Do I get nervous? Should I revise my theory about putting a dark border around the default button just because Google didn't do it?

There is an answer. But first I need to share some facts about human nature that help you address similar issues with your own development team and managers.

Is the Dunning-Kruger Effect at your job site?

It turns out that we can expect untrained colleagues and co-workers to draw wrong conclusions when talking about usability issues dear to our hearts. And we can expect them to feel their opinions have the weight of truth and justice.

Research published in 1999 by Justin Kruger and David Dunning shows that individuals who fell within the bottom 25% of those reporting knowledge in a given topic still tended to place themselves in the "above average knowledge" category. Does that sound familiar?

For example, participants were given quizzes that separately tested their sense of humor, grammar, and logic. These are general skills for which we all have "experience" and presumably some competence to judge.

They were also asked to estimate their skill level compared to other people taking the same set of quizzes.

When looking at the 25% of the participants who scored the lowest, their average quiz scores fell around the bottom 10-12th percent of the possible scores. Meanwhile, those very same participants predicted their own scores would fall above average – their scores would rank as high as 58 to 67 percent of the other participants' scores. Quite a contrast.

Does this remind you of "To see is to conquer"? These individuals were quite optimistic about their skills in humor, grammar and logic.

The authors suggest that "Not only do they reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the ability to realize it."

Meanwhile, what about those participants whose quiz scores fell in the top 25% of scores? How did their self-estimates compare with their scores?

Expertise brings modesty
(in this research, anyway)

It turns out the Kruger and Dunning found that participants scoring in the top quarter gave more modest predictions of their performance.

Their actual average scores were ranked as high as 85 to 90 percent of all participant scores, yet they predicted they would only get as high as 72 to 74 percent of the participant scores.

This is a definition of "modesty". Or better put, as the authors suggest: "those in the top quarter again tended to underestimate their ability."

Where do you fall in this spectrum of usability knowledge?

Since you have read this far, I would guess you have enough expertise to be modest – or in other words, you tend to underestimate your true knowledge about usability when compared to others.

Understanding usability politics

Do the charts and research above remind you of the adage: when a teenager, your parents know very little. But as an adult, you marvel at your parent's wisdom?

Or, recall the proverb, "a little knowledge is a dangerous thing". Perhaps you run into this every day at work. It's called the "politics of usability". Perhaps this is the competition that provides the hardest challenges.

How do you handle this form of competition – the politics of usability?

So far, it looks like we can answer this question by choosing "To See is to Conquer" or we can be modest and ask if there is more to be learned in solving this problem. The choice is ours.

Our two authors oblige with further research that shows us a useful solution. Let us learn.

Make your competition competent

In this context, the authors studied the effect of training participants in logical reasoning skills. They wondered if the lack of self-knowledge about poor performance on the quiz could be corrected by training in the topic.

The authors administered a short logic test to 140 participants, collecting both the actual performance scores and the participant estimates of their comparative skills.

Then the authors instructed 70 of them using a standard logic reasoning packet while the other 70 engaged in a filler task that took the same amount of time (about 10 minutes – not much time if you think about it).

Subsequently, all participants reviewed their own tests and indicated which problems they had answered correctly and which incorrectly.

• Among those who received training, participants with the bottom 25% of scores gave more realistic estimates of their skills.
   
• Results showed that before training, they felt their ability was as good as at least 55% of others, whereas after training, they changed that to being as good as at least 44% of others.
   
• Similarly, they revised their estimates of correct answers from 5.3 questions being correct (out of 10) to only 1 problem being correctly answered.
   
• Among the untrained group, the researchers found no real changes in estimates of their ability or test performance.
   
• For participants among the top 25% of scores, the training motivated them to change their performance estimate from being as good as 78% of participants to a higher 87% of other participants.
   
• Their actual scores placed them being as good as 90% of all the participants on average.

What does all this mean for you as a usability expert dealing with colleagues and managers?

Simply put, "train them".

"Forewarned is forearmed"

This simple proverb provides us a simple agenda.

1. To get appreciation for your usability expertise and usability work, your colleagues and managers must know what is at stake. They must learn about the impact of usability problems and the ROI of solving them.
    
2. They must see that solutions based on usability science are indeed better than others based on intuition and gut feel. (Show before and after pictures.)
    
3. They must learn that end-users are different than they are. (How do you teach that? Show videos of your usability tests.)
    
4. They must learn that end-user expectations and habits can be met. But you must show examples that this happens only if developers agree to standardization and the extra work entailed in reading those standards. (Show examples of inconsistent button names and button positions, etc.)
    
5. They must learn the science of counting keystrokes and mouse clicks when designing a task-flow. (Less is often more.)
    
6. They must learn that a search page put up by Google is different than a search screen that appears in your flag-ship corporate application. (Recall my experience given early in this article. By the way, the solution is to ask "what expectations have our end-users developed from using Microsoft Office applications like Excel and Word?" Clearly, they expect a default indicator.)

Your self-talk pep-talk

We all have our inner scripting that unreels daily when confronted with frustrating events.

Promoting usability and gaining credibility for your work provides challenges no different than many occupations. Consider the doctor who hopes that their patient takes the blood-pressure medication regularly or enrolls in a meditation program to reduce hypertension.

This doctor faces the same dilemma of the patient being overconfident in their own knowledge about their illness.

Across many occupations, we see the conflicts between these two attitudes: "To See Is To Conquer" confronts "Gives Me Your Expertise".

But, as we saw above, increased knowledge about the domain, whether it be logic, usability, or medical issues of hypertension, brings the client into contact with more realistic thinking.

By the way, that's the same solution Julius Caesar brought when he came, saw, and conquered. He was an expert military tactician, not a novice with a surplus of bravery.

• This means that you, as the usability expert have the right "To See And Conquer". You have a background steeped in a scientific approach. (You read these HFI newsletters.)
   
• Relinquish some of that modesty our two researchers found present among the top 25% of participants. Let your light shine. Your quiet confidence communicates as much as your insights if not more.

Meanwhile, for your usability practice, consider these reminders….

1. Train your clients one way or the other: short conversational tips, short emails with links to usability newsletters and tips, photocopies of articles, before-and-after stories.
    
2. As a friend recently shared with me: focus on relationships. Build friendships first. The advice can follow later. Let people know you are interested in them – not just interested in telling them what to do.
    
3. Appreciate the insights of your clients. Even their "gut feel" stories can have some truth. Accept that truth. Agree with their insight – in the sense that it reflects a genuine insight from their experience. Meanwhile, reflect on the idea that other domains of experience exist – such as the end-user experiences you hear daily. Ask your clients how they feel about those other reported experiences. Everyone has a right to their feelings, even if it differs from yours. Accept those feelings. Deal with remaining issues through usability testing.
    
4. Speak politically. Although this is a big topic, here are some tips:
   • Refer to usability research, best practices, industry standards, and results of your usability testing.
      
   • Avoid saying "I think x, y, and z". If your opinion is the key, then anyone else's opinion is also the key. Usability is not an opinion-based science. Usability is based on data, data, and data.
      
   • Get that data from training courses, usability testing, and reading research. Use sources like HFI's Design Newsletter and Jakob Neilsen's www.alertbox.com. Read the UPA Journal. Read the Wichita SURL Usability News research. E-mail them to others.
      
   • Get data from counting mouse clicks and keystrokes. Create taskflow diagrams where you can illustrate the bad (with many steps) versus the good (with few steps).
      
   • Get credentials that show you know the data behind usability. If you don't have an MA or PhD in psychology or usability-related fields, then at least get your Certified Usability Analyst credential.

The adventure awaits.

Go, see, and conquer.

Be well.

References

Ehrlinger, Joyce; Johnson, Kerri; Banner, Matthew; Dunning, David; and Kruger, Justin, 2008. Why the unskilled are unaware: Further explorations of (absent) self-insight among the incompetent. Organizational Behavior and Human Decision Processes 105, 98-121.

Kruger, Justin and Dunning, David 1999. Unskilled and unaware of it: how difficulties in recognizing one's own incompetence lead to inflated self-assessments Journal of Personality and Social Psychology. 77, (6), 1121-1134. (Republished online, 2009: Psychology 1, 30-46)

Wikipedia. Last update 29 June, 2010. Dunning-Kruger Effect. Downloaded 29 June, 2010.

I've been going around the world helping organizations set up serious UX practices and I see this effect from Washington to Melbourne. It might be the biggest impediment to mature UX.

Executives and managers armed with perhaps a few books decide to charge ahead with some training, or a standard, or some other piecemeal approach. They often ignore their more sophisticated, if lower pay-grade, co-workers who stand by saddened and erroneously humble about their greater knowledge.

Education helps if you can get it in place in time. And EVERY UX professional should collect a handful of counter intuitive examples to share in those educational moments.