Miskeeto

Design criteria in action

A miskeeto byte from Robert Hoekman, Jr. Posted on May 26th, 2009

Criteria, as defined, are rules or reference points by which something can be evaluated. A criterion for a city government is that it conceive of and implement positive changes for the people living within that city. Whether or not this occurs is, of course, debatable, and probably depends a great deal on which city you live in. Regardless, criteria serve the same purpose in design. Design criteria, essentially, are rules for a design that express what the design needs to accomplish or achieve for users.

Design criteria is an incredibly powerful tool for anyone charged with influencing a user’s experience with a site or application, but it’s also an idea that hasn’t yet well caught on in the mainstream. So to help further the cause, here’s a story of design criteria in action from a recent project.

As part of a larger application design, I was tasked with designing a Likert survey containing statements to which people would respond with a varying level of agreement — a user could either strongly agree, strongly disagree, or land somewhere in the middle simply by clicking the button that corresponded with her response. The obvious solution was to create a page that showed each of these statements alongside a set of radio buttons, asking users to select one to respond. This is how many other Likert surveys have been designed in the past, and many survey applications support exactly this solution. In this case, however, there were over 100 statements in the survey, which meant I was about to create a really ugly page. And it didn’t stop there. Web-based Likert surveys suffer from a myriad of other issues: radio buttons have tiny hit areas, long lists of statements requiring individual response can be demotivating, and since the format of a Likert survey naturally calls for a tabular design in which the labels for the possible responses would be listed along the top of the page and nowhere else, users would likely have to memorize the order of the responses to get through the survey with any efficiency. These are all unappetizing notions, to say the least. Just the act of moving your mouse from one question to the next would be annoying enough to abandon the process entirely.

Another option was to split it up and show only one question per page. Many Likert surveys have also been designed this way. But this meant the user would have to wait for each new page to load and would get no hint about what question was coming next. It would ask the user to respond to each statement out of context — without being able to see any of other statements in the survey. This wasn’t appealing, either.

To counter these issues, I headed to my wall-sized whiteboard and started writing. There were several things I knew the design needed in order for people to enjoy the process of getting through it. Here’s the list of criteria I wrote:

• It needs to feel fast, even if it’s not actually fast
• It should require minimal mouse movement
• Choosing a response should be fast and intuitive, and should not require memorization

With this criteria and a little bit of poking around design pattern libraries for inspiration, I devised a solution that met all of these goals.

• The questions slide upwards into position, ala the iPhone menu interface, so the user never has to move her mouse up or down the page
• Putting Fitts’ Law to work, responses are chosen via large buttons, to minimize the effort of moving the mouse to the right position
• Only four statements are shown at once — the previous statement, current statement, and the two upcoming statements. This gives the user a sense of where she’s been, where she is now, and where she’s going. And the user is more likely to stay motivated if she can see what statements are coming next
• For editing purposes, Back and Forward arrows are offered to allow users to go back to a previous statement and change her response
• The response buttons were color-coded. In the Western world,  green means Go (or Good), and Red means Stop (or Bad). To help the user infer which button to click without having to explicitly read the labels, the Strongly Agree button is green, Strongly Disagree is red, and the answers between go gradually from one end of the spectrum to the other. 
• To better give the user a sense of her current status, a counter is shown in the upper-right that indicates the number of the current statement and how many there are total (e.g. “You are on statement 46 of 103“).

Simply by taking a few minutes to establish a set of design criteria, I was able to break away from all the bad habits of previous Likert designs and devise a quick and painless interaction that would be easy (and hopefully enjoyable) to use.

Try this on your next project. Try writing design criteria for your application as a whole, for individual interactions, or even just for the copy you’ll inevitably add to the homepage. Take the time to figure out what you really need to achieve to make users fall in love with your site, and then base all your decisions off of that list. Later on, just go back over your design and see if it meets all the criteria. (Of course, you should stick it in front of some users as well, just to be sure.)

Questions? Comments? Suggestions?