Hey, LiveWhale users. This is a reminder that an upgrade to LiveWhale happened last night. What does this mean for you? You may see some minor changes but if something isn’t working – especially if it impedes your process – please let us know as soon as possible. The developers at White Whale will be on hand, ready to receive any bug reports. And, if you have a moment, come to our Office Hours where we can answer your questions about this particular upgrade.
Latest Updates: user testing RSS
User-testing Starts Monday
On Monday, December 5, we’re beginning user-testing of our search engine prototype. We’ve had a good number of people interested and will be contacting them today to setup a 15 minute window to come in and give the new engine a try. If you didn’t get an email today and would like to join the testing group, please send us an email.
We’ll start with several testing sessions on Mondays, with future sessions as we make revisions based on the feedback we get.
We’re using software specifically designed for user-testing which will record our testers’ interactions with the search engine prototype. We’ll start testers out with ten search tasks to see how they each use it, but then ask them to conduct any searches they wish. (We hope they will bring some of their “standard” searches.) At the conclusion, we’ll simply ask them for their general feedback.
This is something we’ve wanted to do for ages and we’re thrilled that we’re taking the time to do it with this new release.
As we continue our march towards a new layout and functions for the search engine, I spent some time recently dropping in a little feature that gives you an easier means to help us help you.
When you do a search and are looking at the results, sometimes you just can’t seem to get the result for which you are looking. Now, directly beneath the page title, you’ll find a little statement that says: “Didn’t find what you were looking for?”
Click on it and a feedback form appears so that you can tell us what didn’t work for you. When you complete it, it also records what you searched for, how the search engine interpreted it, and how many results were found. It bundles all that up and emails us your thoughts (as well as saving it in a database for aggregate analytics later).
Your feedback will help us find the edge cases that stymie you (and us) and in the aggregate will help us continually improve search engine results.
Thanks in advance for helping us.
SXSWi Report: Delightful Applications
In my second personal “track” for SXSWi, I wanted to focus on easy-to-do methods for better user testing. While a number of my sessions dealt with user interaction and testing, two sessions stood out as the most relevant for me: 1) Stop Listening to Your Customers and 2) Conserve Code: Storyboard First.
Stop Listening to Your Customers
In both, the key element was to reduce the cost of user testing so that it’s easy to do at any time. One of the presenters for Stop Listening was Mark Trammell (twitter) and he outlined the process twitter used in creating the new web version of twitter.
For him, the key was using an app that allowed the developers/designers to place a prototype in front of a tester and watch them interact with it. (It didn’t appear that they provided a set series of tasks, but simply saw them use the service — they were going for a certain degree of intuitiveness.)
Mark made a point of not using “average” people but instead used family and friends. (Yes, they were biased, but Mark knew their biases and figured he could account for them.) Knowing the testers personally helped reduce the cost of testing, since it was much easier to bring them in quickly and easily. In the end, they ran 15 iterations of 4 people each to refine the interface.
Conserve Code: Storyboard First
Intuit held a session on how they develop their products. (Sessions aren’t actually sponsored by a firm, but both people were from Intuit… so it might have well as been.) What was most interesting was how early in the process they get the customer (the term they preferred over user) to talk to them about their product ideas.
In order to do this, they actually used poorly-drawn storyboards of six panels each. They tried better-drawn storyboards, but being better-drawn seemed to make people less likely to tell you the truth, since they perceived that you’d invested a good amount of time into the project already. (Clearly, Simon Cowell was not among their test customers.)
Each storyboard would outline a problem, a solution and the expected benefit. The number of panels dedicated to the problem, solution and benefit could fluctuate as part of providing a good summary of the situation outlined. And once done, they would simply hand the storyboards over to customers and get responses from fantastic to not caring a wit about the problem, much less the solution.
They’d do this repeatedly as they refined the product. And as a result, not code/design around issues they perceived as important, but around the ones that their customers did.
Their “classic” example was that they’d thought that an iPhone tax filing app needed to produce the expected refund as soon as calculably possible, whereas it turned out, their customers didn’t care about the number (so soon) but really questioned whether a phone could do their taxes in the first place. Had they not tested their idea, they would have developed an app that solved the wrong problem and probably would have had a lackluster response.
So why did I choose “delightful” as part of the title for user testing? Simply because a well-designed web application gives you a feeling of delight. You try something new in the application and find some feature that you never expected but is exactly where you need it, when you need it.
So I do indeed hope that newmedia has the opportunity to delight you in the near future.