Measure twice, Cut once

You’re probably familiar with the adage “measure twice, cut once”.  Certainly sage advice for carpentry, sewing, and I might argue usability testing.

I’ve done a bit of testing now and it’s clear that multiple tests can be useful in helping get closer to a good user experience. In the last couple of years, I’ve worked on two website builds. In the first case, we did extensive testing including focus groups (I know, not usability testing but useful in its own way), open and closed card sorts, and scenario based testing. The second site was rushed in regards to testing, and while the intention was to do card sorts, we opted for a survey (I know, not usability testing) and scenario based testing.

In both cases, the results of the first tests (card sorts, surveys) gave us some good ideas and seemed to confirm our suspicions. We thought we were close to where we needed to go with our design/terminology/architecture. However, it wasn’t until the scenario based testing that we truly saw if we were on the right track.  For example, terminology that works well in a card sort or survey, can prove to be more problematic when put into the actual context of a website.

One might argue that you could jump the first step and go right to scenario based testing. There is little better than actually watching your users try to find things on your website. But I think there is value to testing suspicions before putting it in the proper context on a website. We might have missed an issue with terminology if we hadn’t done a card sort and only offered one option on a website scenario based test.

Rule out obvious problems with a small test, such as terminology through a card sort, and confirm these results and explore more intricate issues with a deeper, scenario based test.

Test twice, change once.

 

 

we don’t need no stinking website

I’ve been doing a lot of usability testing as we redesign the library website. It has been both enlightening and unsurprising at the same time. It’s confirming many of my beliefs and biases when it comes to the library website.

Most recently, we did a little guerrilla testing, nabbing folks to take a look at our prototype and see what they thought and how they might use it. Generally, we got some good feedback. Most liked the way we were going with the designing, using terms like user friendly, easier to use, organized, and modern. Yay!

There’s been lots of interesting feedback from this testing that I’m still sifting through. But what surprised me was how often, when asked what they would do on the library website and presented it to them, they simply said they wouldn’t use the library website. They would ask friends, google, ask at the circulation desk. Now, this isn’t terribly surprising – we know that our users often come to the library website as a last resort. There are lots of other ways for our users to find what they need. What surprised me was that they wouldn’t even look at what we were showing them to see what they could do. It simply wasn’t their behaviour, so they didn’t want to bother looking.

So, what does this mean? I’m still working that out. Do we need our users to come to the library website? Certainly not for everything. When they do, it should be user friendly. But I’m still trying to figure out what to do with the answer I wouldn’t use the library website. Definitely more testing in store!