SXSWi Report: Delightful Applications
By David McKelvey
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.