Entries from June 2009 ↓

Twitter’s all A-Flutter Over Nielsen’s Alertbox: Stop Password Masking

Jakob Nielsen, usability guru, doesn’t look to me like a big trouble maker. However, his latest Alertbox, “Stop Password Masking” proves he’s ready to come out punching.

He’s caused quite a stir amongst some Twitter users – who seem extremely polar, being either pro or con on the subject of password masking. But don’t take my word for it, here’s a few examples of pros and cons from Twitter:

Why All The Password Angst?

So why has Nielsen hit such an apparently tender topic with his recommendation to remove password masking? First, let’s see what he actually said the problem is, and why the solution is un-masking our hidden passwords:

“It’s time to show most passwords in clear text as users type them. Providing feedback and visualizing the system’s status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.”

Seems harmless enough, right? If you’re trying to type your passwords in before your morning coffee has really got you going, or on your tiny Palm Pre, is having the results of your fumbling fingers being un-masked (so you can see if you entered the correct string or not) such a bad thing?

Ahh, but what about that whole issue when you’re at your favorite coffee place and those strangers who are always peering over at your computer from the next table behind you are watching [shivers] – what about then? Here’s what Nielsen says:

“Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.”

So, assuming all our Tweeps actually read the entire article from Nielsen (and we already know that most people on average only read about 20% of the words on a web page) why is there so much angst about removing something that is causing frustration and slower productivity?

I think it can be summed up in 5 general reasons:

5 Reasons Why We Don’t Like Changing Password Masking

1. We are creatures of habit – You and me, us humans, we like getting into routines and sticking with them. We brush our teeth with the same toothpaste every day, we go to work along the same route, and for some odd reason we always end up picking the longest queue when offered shorter or longer ones.

It’s a habit to type a password into a small box and be presented with masked characters in return. It goes against our grain to want to change this habit.

2. Change is frightening – For most of us, change is a rather frightening thing. When things change, it causes us a mild sense of cognitive dissonance. What’s that? We know we should should be doing this usual and customary thing, our brains tell us so, but now we aren’t doing that, we’re doing something different. That causes us to feel ill at ease.

For many of us change means re-wiring our brains to accept and use something new, something different, which takes work. We don’t like work (this kind of work anyway – if my boss is reading this, I LOVE work! Really!).

3. Using password masking, we have a false sense of security – Here’s what we think when entering our passwords in and being presented with a series of round black dots.

“Well, nobody can see my password, including me, so that means it’s secure and I don’t have to worry about somebody stealing my password so I’m safe.”

But meanwhile anyone watching over your shoulder, or from the cube next to you (don’t look around!) can probably pretty easily see the characters you’re typing, and pretty much be able to figure out your password. Personally, I think it’s worse with bank ATMs, they only need to watch you enter 4 digits!

And your security breach may be far worse. You have probably written down every single password you own, including the URL and account name for each and every “secure” login, on a non-encrypted file somewhere in your computer. Or worse, you’ve got your password on a post-it note somewhere near your monitor! How secure is that!?

4. We don’t understand the actual lost productivity – I know what you’re thinking, which is what I was thinking, which was:

“So what’s the big deal? So I have to retype my password sometimes, or have to contact someone because I forgot it, no big loss, right?”

Wrong!

According to the United States Navy, whom I trust to do their homework regarding lost productivity due to forgotten passwords;

“studies have indicated that approximately 40% of all help desk calls are for forgotten passwords.”

If you don’t believe the United States Navy, go do a search on Twitter for “password” and read all the thousands of tweets from tweeps who forgot, then sometimes found, their passwords for various logins. All that “lost my password, but now found it” stuff is lost productivity.

5. Businesses have a false sense of Control – For a business, often there’s a sense of “protecting users against themselves” by trying to manage certain processes or procedures for them. You can almost hear those in control say,

“I can manage your password and make sure you only get it if you do things I want you to do.”

This is why there sometimes are extra hoops to try to get through when obtaining a password that you forgot. In the bad old days, many times if you forgot your password the only way you could get one was to get a new password. Which of course forced you to have to write down your new password because you just knew you were going to forget it.

The Option of Seeing a Password

So here’s my take on the whole uproar issue, the people that are in an uproar may not have necessarily read the entire message.

What Nielsen actually said,

“It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default.”

That doesn’t seem as bad as letting everyone know your passwords by sticking them to your monitor, or putting every password and account number and URL in an unsecure file on your computer, now does it?

It’s been 10 years since Mayhew wrote “The Usability Engineering Lifecycle,” How far has usability come since then?

It sometimes surprises me to find out that my parents were right. I distinctly remember them saying “Boy, time sure does speed up as you get older, where does the time go?” I thought they were crazy. I thought this especially when me and my other 10-year-old friends spent hours on the front porch saying “What do you want to do?” “I don’t know, what do YOU want to do?”

So it’s rather odd that it seems to me like just a few years ago, not ten, that Mayhew brought “The Usability Engineering Lifecycle” to the world. How far have we come in ten years? Do you feel like the last ten years just zipped by? What about usability, do you think it’s come a long way down the maturity path?

I wonder what you think?

Here’s what I think…

Usability Engineering Ten Years Ago

I recall that ten years ago I felt usability testing and user-centered design principals were not very common in development projects. I would say projects that included user-centered design were in the minority, the vast majority being conducted without a thought to usability or user-centered design.

For those of you who were there doing usability at that time, remember that whole Y2K issue and all the major projects to ensure all systems would work after computer clocks clicked over to 2000? For me, it was rather difficult to get web site projects done what with all the hysteria, but when they were worked on luckily I had a senior level Boss that was a champion for usability. Together, we inserted usability testing as part of the process of the major web site redesign projects we were responsible for.

Unfortunately, it was not that easy to insert usability into web and application development projects we were not directly responsible for. There were other business owners and their supporting I.T. staff in different divisions of our company that designed and built web sites or web-based applications with zero usability or user-centered design. Most of the time usability was not even thought of, but sometimes if we cajoled or otherwise influenced them regarding the value of usability we might get lucky, and usability would be included.

The worst case for us was internally developed and utilized applications. Intranets and employee-focused internal apps had zero usability, and there was no interest in “slowing down” to make changes that might impact the delivery dates of said applications.

If you were working in a business or a design or development firm in 1999 did you have the same experiences?

At that time, after pouring through “The Usability Engineering Lifecycle,” I felt like I had a new friend at my side! It was like a breath of fresh air. In this book was a detailed description of exactly how to incorporate usability and user-centered design as part of the Software Development Lifecycle. It provided helpful war-stories of how usability sometimes did and sometimes didn’t make it into the early stages of design and development projects. It gave me lots of good ideas for “selling” usability.

Usability Engineering Today

So here we are, ten years later, and according to a recent User Experience Maturity Survey by Human Factors International 52% of the over 1,000 survey respondents said they have a usability champion at their company that supports user experience design! That’s really good news! We have indeed come a long way baby.

If you are one of those who have an executive champion that pushes the user experience design method and insists it be present for all development projects then congratulations.

Clearly as witnessed by this study, usability and user-centered design have much more support today than they did ten years ago.

For those of us without an executive champion, there’s still more work to do to get user-centered design incorporated into the company.

Even today, ten years later, I’ve seen plenty of examples where there are parts of a company where the usability executive champion has sway, but in other divisions in which the executive champion does not hold sway usability and user-centered design is still not practiced.

For example, I’ve witnessed (and been forced to use) many intranets and internally-built employee-focused applications that are designed and developed with no usability – zero user-centered design! You can tell when you attempt to use them. Ouch.

So, we’ve indeed come a long way in getting usability institutionalized into the corporate fabric. The glass is half full! But (according to the study) we still have about 50% of companies that don’t have a usability champion. The glass is half empty!

If you are one of those toiling away trying to get usability in your business don’t give up! Consider reading, or re-reading “The Usability Engineering Lifecycle.” Even though it was written ten years ago, the concepts are still as true today as they were ten years ago, and the war stories just might help give you ideas you can use at your company to get usability added to development. There is still a considerable amount of helpful information you can put to use with your situation.

Usability Engineering 1999-2009

But that’s just my opinion about the last ten years of usability engineering. What do you think? Is the usability glass half full, or half empty?

Should an Agency, or Designer, Conduct Usability Testing on Their Own Designs?

Among the spam and family emails I get from my mom (hi Mom!) I sometimes receive questions from colleagues about usability. This post is about a question related to design and usability I received, here’s the question:

“Is there a conflict of interest in having the web design team who created a site also do the usability testing post launch? The web design agency has been tasked with ‘improving’ it’s own designs. They have outlined a ‘usability’ test plan that seems to be more about understanding user thoughts and reactions to a site they built for us, rather than measuring specific task-based assignments. And, even if they were to outline concrete tasks to measure, as testers, could they introduce bias into the process?”

Conflict of Interest of Design & Usability

As I sit here sipping my coffee, pushing the cat off the keyboard for the 4th time and contemplating this issue, I’m reminded of a famous saying, “Physician, heal thyself!”

I think it’s a generally accepted principle that a designer is usually too close to their own work to be an effective usability tester. Why? Because the act of designing is based on making hundreds or even thousands of decisions based on knowledge, intuition, context and experience. By making these decisions, a designer has on purpose selected and committed to what he or she sees as being the “best” outcome.

As a designer, it’s very difficult (note that I didn’t say impossible!) to remove yourself from a design 100% objectively. I would add as a side note here that unless the designer has also been trained in usability and usability testing methodology it would be difficult for him or her to conduct a test.

However, if in this case the Agency is using a separate test team for the usability work then that shouldn’t be an issue.

Design Agencies & Usability Staff

Most web site design agencies can’t afford to have full time usability gurus on staff, generally only the bigger ones can. From my experience, most agencies will farm this usability stuff out, and that’s a wise decision, it means there’s a separate trained usability team focusing on the usability testing.

Putting my agency hat on for a second, I’m pretty sure an agency would not want to come back to a client and say,

“Hey, good news! We did the usability testing of our design like you asked us to do (by the way, here’s our invoice) and we have great news! There’s no improvements we can make! The web site design we built for you is perfect!”

Let’s face it, that would cause great alarm with the client – who would probably be thinking

“BS! Now I’m nervous!”

But then again, the Agency wouldn’t want to tear apart their work either, calling it,

“Unusable crap! Holy cow, this thing is more broken than our economy!”

That would most likely cause the Agency & its designers to have a black eye, or at least a bloody nose. And the client would be wondering how they are going to explain all this to their boss.

Usability Testing Should Come Before Web Site Launch

Getting back to the question, first off, although it’s good that the agency wants to do usability testing to improve the web site after launch, it would have been MUCH better if they had done usability testing as part of the design process, from the very beginning of the project.

User-centered design means conducting quick usability tests at critical stages throughout the development life-cycle with your users, not after the design has gone live. This helps to ensure that the web site is going to be user-friendly well before it’s live for the world to see and gawk at.

Usability Testing is Not Asking User Opinions

Asking people to talk about their experiences or their opinions about web sites through focus groups is not usability testing folks, it’s opinion testing.

User thought and reactions are not “task oriented” usability testing, and although helpful cannot be relied upon as solid metrics upon which to base decisions. If the agency is recommending getting user feedback or opinions, I would suggest you should probably couple that opinion testing with task-based testing.

Task-based testing is used to determine exactly what the failure rate is for each critical task on the site, and where those failures are occurring. This is the only way to improve a web site based on actual usability data.

But don’t take my word for it. Here’s a quote from Steve Krug’s “Don’t Make Me Think” which is like the ultimate usability book and is even fun to read:

“… the conversation usually turns to finding some way (whether it’s expert opinion, research, focus groups, or user tests) to determine what MOST users like or don’t like – to figure out what the Average web User is really like. The only problem is, there is no Average User.

…it’s not productive to ask questions like “Do most people like pulldown menus?” The right kind of question to ask is “Does THIS pulldown, with THESE items and THIS wording in THIS context on THIS page create a good experience for most people who are likely to use THIS site?”

And there’s really only one way to answer that kind of question: testing. You have to use the collective skill, experience, creativity, and common sense of the team to build some version of the thing (even a crude version), then watch ordinary people [who match the Persona - Craig] carefully as they try to figure out what it is and how to use it.

There is no substitute for it.”

Powerful words. Hold on for a second while I come out of my zen-like usability trance… ok, I’m back!

Conduct Task-based Usability Testing Post Launch

So the answer to your question is this: Ask your design agency to replace the focus groups and user feedback with an actual set of 1-on-1 performance-based usability tests of the critical tasks. This will provide instant actionable data you can use to improve your web site.

The money (and time) you save in conducting the 1-on-1 performance-based testing will probably be paid back quickly with the improved conversion or related outcomes you are ultimately seeking.

Good luck!