Archive | March, 2009

The effect of bias in DIY usability testing

26 Mar

DIY usability testing

We’re seeing a lot of people talking about conducting their own usability tests in house. The topic of DIY testing has been around for some time now with advocates such as Steve Krug and Jakob Nielson. The general principle being that any testing is better than no testing which is an idea we fully believe in.

As a company who offer usability testing it will probably come as no surprise that we would put forward an argument against companies doing their testing in house. But, before I do that I’d like to add that I think its excellent that people are taking user centredness so seriously these days and if teams feel that they want to take testing in house then that can only be a good thing for the future of the industry. If internal development teams feel so strongly about getting usability and user experience right, then of course we would fully support them in doing so.

My concern with what appears to be a rise in DIY usability testing is one of bias. One of the main benefits our clients get from using us is that we’re independent (combined with the fact we’ve been usability testing for nearly 10 years now).

Our word of warning to all those people looking to test their own projects is don’t underestimate the power of bias when testing your own stuff. When we come into a project and observe users interacting with a product or service we don’t have any of the baggage of internal politics, why it has been designed the way it has, who made the decision to put that button there, why its not possible to do this. We simply see things from a fresh, independent perspective which allows us to really see what’s going on.

When a project team comes to observe us testing their product or service with users, at the end of the day when we talk about the findings what they saw is often quite different to what we saw. They saw the detail rather than the bigger picture, they picked up on evidence to strengthen their own pre-existing beliefs, they played out discussions and arguments they’d had when designing it. We didn’t. We had the luxury of seeing what was really happening.

Not being able to see the wood from the trees is something we can all identify with at times. When we are in the day to day detail its really hard to step back and see things from a new perspective. Testing the project you’ve been working on carriers the danger that you may just see what you want to see. You may see things that you instantly dismiss because of the history of how it has been developed, but the real key to improving the experience may be hidden here and you simply can’t see it. Sometimes it takes someone else to spot the patterns going on right in front of your eyes.

Overall the increase in DIY testing has to be a good one because ultimately the winners will be the users. An increase in awareness and appreciation for improving user experience is something we would fully support, so for people with no budget to bring in independent consultants we’d fully recommend giving DIY testing a go. But, DIY testers must be aware of the dangers of only seeing evidence to support what they already believe to be true. Sometimes an independent expert review can be more valuable than an DIY usability test, but that’s a post for another day.

Is your perception of usability in your product or service accurate?

Related services: Usability testing, and User experience audit

 

 

Liked this article?

Get more usability insights straight to your inbox

  • We promise no spam, just straight up great insights from our UX experts!

 

 

Damian Rees

About Damian Rees

Damian has worked as a usability and user experience consultant for over 13 years. He has worked in senior roles within companies like the BBC and National Air Traffic Services where he has researched and designed for users in a variety of different contexts including web applications, voice recognition, and air traffic control interfaces. Follow Damian on twitter @damianrees

Top 10 reasons for poor usability – part 2

3 Mar

Poor usability

Following on from part 1, we have another 5 reasons why products and services so commonly deliver poor usability:

6) Too many cooks

When a project team has too many stakeholders or a large team with no clear project leadership or role definition, the team can suffer from too many conflicting opinions on how the product should be designed. Often, the team will argue among themselves to try to implement interface changes they *think* are the best for the project. If this goes unchecked product development is at the mercy of whims, speculation and ego. Project teams have little or no sanity check on their ideas and tend to lose focus on who they are designing for and what they need.

7) Poorly defined project objectives

We are always surprised at how few projects have clearly defined project objectives when we first engage with a new client. When projects have no clear objectives, the product or service is likely to grow in a haphazard fashion. Over time the project team lose interest with it and the users suffer from a mismatch of features and functionality. A clearly defined set of business objectives balanced with a clearly defined set of user/customer objectives is critical to delivering consistently good experiences to customers.

8) There are no incentives for good usability

Very few teams are given incentives for offering good usability in product development. All too often, companies reward teams for more traditional measures or KPIs (customer satisfaction, budget, traffic, output etc.). It stands to reason that if project teams are not rewarded for improving usability, they will place more emphasis upon the aspects they will get recognised and rewarded for. Setting up regular usability tests with a clear benchmark at the beginning of the project will offer an excellent way to measure and incentivise usability in any project.

9) They are simply not aware usability is poor

We’ve heard many clients tell us that they already know what’s wrong with their product/service, yet they are always surprised when we report usability problems they had not even considered. It is very difficult to know you have usability problems unless you actually conduct usability testing on a regular basis. Customer comments, complaints, and website analytics can sometimes indicate that you have a problem, however they rarely give you insight into what the problem is and why it is occurring. This can only be discovered by observing users interact with the product or service, and many project teams have never done this.

10) Can’t see the wood for the trees

We’ve all experienced the feeling of being so close to something, we can no longer make good decisions. This happens all the time in projects where everyone has such an intimate knowledge of the product or service that they can not step back from it and see the bigger picture. They can start to make decisions which result in poor usability because they can no longer see the project from a user’s perspective. Independent, eternal advice is critical to integrate an objective perspective into their decision making processes and eliminate usability issues.

As we said in part 1, it is not easy to develop highly usable products and services. Eliminating poor usability happens throughout the entire project lifecycle from setting objectives at the beginning, right through to getting regular independent user input after the product or service has been launched.

Do you recognise any of our top 10 reasons for poor usability in your projects?

Related services: Customer requirements capture, Usability testing, and User experience audit

 

 

Liked this article?

Get more usability insights straight to your inbox

  • We promise no spam, just straight up great insights from our UX experts!

 

 

Damian Rees

About Damian Rees

Damian has worked as a usability and user experience consultant for over 13 years. He has worked in senior roles within companies like the BBC and National Air Traffic Services where he has researched and designed for users in a variety of different contexts including web applications, voice recognition, and air traffic control interfaces. Follow Damian on twitter @damianrees