Bias is an outcome of human thought and often based on rules of thumb. Cognitive biases are instances of evolved mental behavior. Some are presumably adaptive, for example, because they lead to more effective actions in given contexts or enable faster decisions when faster decisions are of greater value. Others presumably result from a lack of appropriate mental mechanisms, or from the misapplication of a mechanism that is adaptive under different circumstances.

Though cognitive bias falls under the realm of Psychology, cognitive bias plays a vital role in user research. Understanding the various forms of cognitive biases will help a usability analyst when performing contextual inquiries and user interviews.

Wikipedia lists all the cognitive biases that makes for an interesting read. The list of biases allows a researcher understand the context behind user’s approach to tasks. For example, understanding the Hawthorne Effect – which is about the tendency to perform or perceive differently when one knows they are being observed – will help during a contextual inquiry. An understanding of the Planning Fallacy effect is useful in calculating the task completion times.

Bullshit. Every one seems to have forgotten the basic tenet of usability: “Know the user, and YOU are not the user.”

If a car designer tries to create a similar steering wheel for a production vehicle, I can understand the uproar. But for a customized piece of machinery like a formula 1 car, the discussion is moot.

Most people don’t understand what a motor racing car is. Comparing it with an ordinary road vehicle is idiocy. A casual driver never deals with issues like configuring the fuel mixture, adjusting down-forces and wings. He never drives at speeds of over 300 kmph. He never experiences g-forces of over 4. A Formula 1 car is a complex piece of machinery… Trying to apply ‘iPod style’ usability principles will not work…

The definition of usability is ‘The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.’ And I see no reason why the F10 steering wheel doesn’t adhere to this definition. It is designed for

• a ‘specified users’ – a Formula 1 racing driver
• ‘achieve specified goals’ – win the race
• ‘effectiveness’ and ‘efficiency’- the various functions available to the racing driver to win the race
• ‘satisfaction’ – a F1 car is built around a single person, customized to his needs.
• ‘a specified context of use’ – the car and its components are built for one thing only – speed and maneuverability.

As a formula 1 aficionado and a UX practitioner, I belive the F10 steering wheel does what is supposed to do — help the driver race his vehicle.

Steve Krug’s Don’t Make Me Think has been the book I recommend for anyone interested in understanding usability. His second effort, Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, expands the idea of one of the chapters in Don’t Make Me Think. Staying true to the book’s subtitle of The Do-It-Yourself Guide to Finding and Fixing Usability Problems, the book is a DIY guide to identify usability issues; though the fixing part is glossed over in the book. Steve Krug guides us through a process of conducting a small usability test and provides guidelines to run one such test in the book.

Rocket Surgery Made Easy by Steve Krug

The key ‘maxims’ according to Steve Krug are:

• A morning a month, that’s all we ask. [Conduct a simple three-person usability test frequently.]
• Start earlier than you think makes sense. [Begin your testing as early as possible in your product development.]
• Recruit loosely and grade on a curve. [Try to get people who match your end-user profiles closely. Improvise if required.]
• Make it a spectator sport. [Involve everyone associated with the project and get them involved.]
• Focus ruthlessly on a small number of the most important problems. [Fix the important issue first.]
• When fixing problems, always do the least you can do. [The smallest changes are the most easiest change to make.]

At the end of the book, you get an idea on how to conduct a small usability test. The book tries to limit itself to a DIY approach and hence skips a large-scale usability testing process. But once one gets experience conducting usability tests on a smaller scale, it is just a matter of scaling it up to encompass a large usability test scenario.

If you have read Don’t Make Me Think and Designing the Obvious and you are still interested in getting your hands dirty with usability, then this book is definitely a must-read and a must-have in your bookshelf and I would rate it as 4/5.

]]> http://paperarrow.com/blog/2010/04/rocket-surgery-made-easy/feed/ 0 http://paperarrow.com/blog/2010/01/is-techcomm-ux/ http://paperarrow.com/blog/2010/01/is-techcomm-ux/#comments Mon, 25 Jan 2010 08:50:48 +0000 Xavier http://paperarrow.com/blog/?p=85 Continue reading →]]> Is technical communication a part of user experience?

Absolutely. Without Doubt.

One major interaction that a user has with a system is the documentation accompanying the product, either as printed manuals or their electronic cousins. In fact, any text that a user sees on the screen in the form of labels and copy is a form of technical communication – another source of interaction with the user.

I’ve had many people ask me about transitioning from technical communication to usability/user experience. All I can say to them is that you might already be doing it; only that you aren’t aware of it yet.

Another question I get to field often is how to ‘get into’ it. The answer that I give mostly is Volunteer. Volunteer to check screens/copy text for clarity/disambiguity. Volunteer to check every interaction a user would have with the system. Provide clear and meaningful copy for error messages.

Technical Communicators often forget a very important fact – they are often the first users of a system. Most of the time, they are just concerned about just documenting the system, rather than looking at it from a user perspective. I’ve seen this happen a lot of times and have been guilty of the same on several occasions.

In a blog post at Adaptive Path, Peter Merholz writes, I believe that user experience is not best thought of as an activity or function, but as a mindset. To varying degrees, every customer-facing person in an organization has an impact on, and, thus, responsibility for the user experience.

That’s something everyone aspiring to be a usability practitioner ought to be taking to heart.

Out of the window, via Flickr user: Squirmelia

We deliver all of our documentation as PDFs to our customers (except for that rare marketing collaterals that get printed and distributed). These PDFs are uploaded to a repository and made available to customers (external and internal). Having observed how people use our documentation these past few years, I noticed that only a few people actually ‘glance’ at the Table of Contents. Everyone seems to like the Search button in Acrobat Reader. Just fire a few keywords and Presto!, here are the results.

All that time and effort I spent in developing that ToC and Index was down the proverbial drain as they never saw the user’s eyes. Not that you can blame them for not looking at my lovingly crafted ToC. Information seeking has moved away from getting to know the structure of a guide from the ToC or narrowing down a selective topic from the Index is no longer the right way to do things. It has evolved to the search box. PDFs are great for searching and you can even search multiple PDFs simultaneously.

In a world when documentation was printed and delivered to customers as printed books, the Table of Contents and the Index made sense as you can ‘run’ a search on a printed book. But do they still make sense in an electronic world where documents are created as searchable PDFs?

Is it time to eliminate tables and indices from the documentation deliverables, especially when they are not being printed?

More than 100%

Wait a minute! 114%!!! Lucky, my phone was nearby and I took this snapshot for posterity.

This Brandon Sanderson-esque progress bar is unacceptable. I have heard of people telling that they will do more than 100%. But this is frankly the first time, I’ve seen a software do it.

I was wondering what would’ve been the reason for the progress bar crossing 100. Some person definitely would’ve forgotten to declare the variable that stored the progress percentage. The maximum limit must have been set as 100, but I guess someone missed it. Correct me if I am mistaken but I thought Ubuntu code went through more eyeballs than any Windows OS code.

When I wanted a name for the site that was about documentation and user experience, I decided to name it as PaperArrow where ‘paper’ would stand for the documentation (manuals) and ‘arrow’ serves as a reference or signpost for help. Relating to the user experience side of business, the references are wireframes and prototyping for ‘paper’ and task flows, user journeys, and flowcharts for ‘arrow’. And the domain name was available, which clinched the deal for me.

All I had was an Excel file with around 20 messages that had the current error message and a description when/how the error message occurs. Feeling it would be a good exercise to spend the afternoon, I made my way towards the product development team. As we started the exercise, I realised that the team had no idea about error messages. They just got in touch with me because I was the technical writer. They had obviously thought that I was there just to correct the grammar and punctuation. I sat down and went through each scenario where the error message occurs and did what was required.

One typical user activity is to create a configuration file into the database by creating one or by importing an existing configuration. The dev team wanted me to look into the errors that occur during the import process. During that process, I identified issues with the sequence of error messages appearing because the inputs were not validated atomically. Rather, they were validated as a batch and you got a bucketful of error messages that should have been caught earlier. Being modal in nature, the user had no choice but to click the Ok or Cancel button to move on, which was too late. And these error messages really weren’t serving any purpose other than the developer’s need to say that the user made a error.

I explained that a good error message consists of three parts: what went wrong (a reason), why it was wrong (the problem), and what to do next (a call for action). Messages that follow this approach help the user move on with their flow with minimal interruptions. I also explained it was better to anticipate possible error scenarios and prevent them from happening rather than display an error message afterwards. As Alan Cooper mentions as a design principle in About Face 3, ‘Error message boxes stop the proceedings with idiocy and should be avoided.’ I suggested some solutions to avoid the error happening in the first place by performing validations then and there, rather than display them as a bunch of dialog boxes that force the user to click a button to get the error message out of the way.

Next up was the language used in the error message, which was the original reason why I was working with them in the first place. A question arose if the word ‘please’ had to be included in the error message like “Please enter an IP address” or should it just read “Enter an IP address”. I felt it was better to go without the word ‘please’ because it felt too patronizing and it did not add any value to the sentence. Finally I had reworded it to read as “The IP address cannot be blank. Enter a valid IP address. The IP address must be of the form of xxx.xxx.xxx.xxx”.

What really irked me was that the developers had no clue to user interface guidelines. They were using a Windows application, but they were not following the Windows User Experience Guidelines, but again even Microsoft doesn’t follow it at times.

Image via Flickr user:twindx

Chip in with your thoughts on error messages and designing for contingencies…