What’s the point of usability testing?

来源：互联网发布：js 点击div改变class 编辑：程序博客网时间：2024/06/05 09:11

2006年07月05日 15:11:00

原文：http://blogs.thoughtworks.com/ 作者：Marc McNeill

I've seen a couple of projects recently where the team have invested in usability testing of wireframe mock-ups of application processes. I'm beginning to wonder whether this is effort well spent.

Don't get me wrong. I am a firm advocate of usability testing and incorporating it as early as possible into the design process. I've set up a few usability labs in my time, facilitated hundreds of usability sessions. I even once had the pleasure (is that the right word) of watching users struggling with boo.com. There is always much to learn from seeing users actually using what you are building. But I now ask the question at what point can you learn the most. If you've designed with usability in mind, where is the value in testing the basics of something that instinctively you know as a usability professional to be "right?"

Let me qualify this. The development of an on-line application processes / tools / wizards is now a well trodden path. Any interaction designer worth his or her salt will have experience of building one and will instinctively know what works and what doesn't work.

In the first instance the interaction designer will create wireframes that illustrate the process; a visualisation of the pages representing the flow that has initially been created.

In creating the wireframes the Interaction Designer should be making reference to personas, will have been collaborating with other team members, validating their assumptions, and will probably be doing informal guerrilla testing around the office to confirm ideas that are puzzling them.

If the interaction designer is any good there will be few, if any issues with the wireframe flow that the users walk through. In a usability test the user is more likely to pick up on labels (and if it is not lorem-ipsumed up any copy that the interaction designer will have written - It is unlikely at this stage that the copywriter will have been involved).

That is a lot of cost and effort to validate the work of a professional.

The wireframes in usability test will generally be based upon a set scenario through a "happy path". What the wireframes are unlikely to uncover are issues where the user wanders from the "happy path". Producing reams of wireframes in Visio or PowerPoint and then linking them all up to simulate the finished product is painful and not particularly productive or useful, especially if there is a lot of interactive "web 2.0" stuff going on. To really simulate that you are going to have to build a prototype for real.

Here is something that the devs at ThoughtWorks are pretty good at. Using high productivity platforms such as Django or Ruby on Rails they can pull together a fully featured product that can be usability tested in earnest. It is not a dumb "smoke and mirrors" html prototype; it can have database and "intelligence" behind it. The benefits of this are clear. The business can try and break the process; we can get the business rules right. The developers are able to see how the vision actually functions. Again, they less likely to uncover corner cases that have been missed if a first pass of build has been done already.

Once we have this new avenues of testing are opened to us we can move away from the need to test in a clinical lab environment. Providing a user with a URL to the application form, and using collaborative software such as Skype and Net Meeting we can perform usability testing with greater ecological validity – the user can use the application form on their own PC at home.

SpiderMan From：http://blog.csdn.net/testwin

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=880418