forUse: The Electronic Newsletter of Usage-Centered Design
#20 | February 2002
|| 1. Events: Deadline Extended.
|| 2. Process: Designing Web Applications.
|| 3. Technique: Invention by Increments.
|| 4. Training: Repeatable Results.
= = = = =
* Watch for us in ACM interactions! We’re being featured
in the upcoming design issue.
1. forUSE 2002 Deadline Extended.
We have received so many requests for extra time, that we have extended the deadline for proposals. So, you have until 8 March to propose a session, panel, demo, or other presentation for the premier conference on usage-centered design. Details are in the Call for Participation at (http://foruse.com/2002/cfp.htm). (You might also notice that the conference has its own sub-site with a distinctive design. Hope you like it.)
Write up your best ideas and send them by email (mailto:email@example.com) by 8 March. We’ll be announcing the final program by the end of March.
2. Agile Web Design
Usability on the Web and in Web-based applications is certainly one of the hottest topics of the day. At its heart, our position is pretty straightforward. We think the most effective way to get highly usable Web apps and sites is to design it right in the first place. Usability testing and customer feedback are certainly important sources of guidance for improvement, but if you have a crappy or even just a so-so design, these are not enough in themselves.
The real “secret” to success is model-driven design. The problem on so many Web projects is that resources are limited and time is even more limited. If you want to model your tasks and model the user interface architecture that will fit those tasks, you had better be quick about it, because the programmers are likely to be racing ahead with their HTML and Java.
Ordinary index cards are a powerful tool for speedy modeling. In fact, ruled index-cards (Oxford) have been nominated for a Jolt award as the best development tool of 2002! (If you don’t believe this, check out the SDmagazine.com site.)
We use index cards to create workable models of user roles and tasks in Web time. In the last newsletter, we wrote about collecting and combining multiple perspectives using card-based models. We also introduced a simple Excel spreadsheet template for calculating concordance: the degree of agreement among multiple rankings. Thanks to the superb work of reader Daniel Maher, the spreadsheet has been improved radically and made more much more robust. (You can download the latest version at (http://foruse.com/resources/tools/ranking.xls)
We’ve summed up our complete approach and latest thinking about doing lightweight usage-centered design in Web-time in a new paper, “Usage-centered Engineering for Web Applications.” It draws on our experience in designing a Web-deployed application for classroom teachers to illustrate usage-centered design based on an iterative modeling-design cycle. You’ll find the unabridged original at (http://foruse.com/articles/webapplications.htm).
3. Inventing Instructive Interaction
Initial response to our paper on making user interfaces self-teaching through instructive interaction (http://foruse.com/articles/instructive.htm) has been astounding. By the time I spoke at the Boston conference of the Usability Professionals Association on 25 January, we had already logged nearly 1,000 downloads--in just the first 36 hours! The paper gives lots of examples of innovative design solutions to achieve instructive interaction, but one question we keep getting is how one arrives at the best solutions for any given problem.
In our design thinking, we find it useful to distinguish between the visual design, how things look on the screen, and the interaction design, how users interact with the visual elements and how these behave. Although these two aspects of user interface design are ultimately inseparable, it can be helpful to think of them independently, especially when trying to come up with something novel to solve a really tough design problem.
In situations where a really good design solution eludes us, we slow down the process and divide it into steps. First, we review what we know about the problem we are trying to solve. What are the task cases to be supported? What materials and tools--in the abstract--are required to support these tasks? If we have written out task cases and a content model, the information we need is right there in the models.
Next, we want to explore the full range of possible solutions, beginning with a list of the conventional or familiar approaches that might be used to solve the problem. We might also brainstorm some more wild-eyed alternatives to round out the list. Each of the ideas on this list has both visual and interaction design implications, so, in effect, we have a three column list: (1) what the possible solution is, (2) its appearance and use of screen real estate, and (3) how users interact with it.
Typically, nothing in the list is exactly what we are looking for, so we start thinking about what precisely is wrong with each of them and how that might be changed. We try to express the problem or limitation in each case as a matter of either appearance or behavior. For example, using two spin boxes to set hours and minutes in an on-screen clock creates a visual problem because the spin buttons for the hours fall between the hours and minutes and break the visual gestalt of the time display. (If you can’t visualize this problem, refer to the example in Figure 9 of the paper: http://foruse.com/articles/instructive.htm)
Once these various shortcomings are expressed, ways to overcome them usually become apparent. E.g., if the spin buttons get in the way visually, then moving them to the outside is a pretty obvious work-around. In many cases, the better features of two or more of the alternative components can be combined. Having a simple inventory of the alternatives and their limitations makes it easy to consider various creative combinations.
In outline, the steps to invention go something like this:
Bingo, you have invented a precise solution to your particular design problem. Now you just massage it to make it “intuitable,” and you are nearly home!
This explanation makes the process sound more tedious than it is in practice. In many cases, the alternatives can be listed and reviewed mentally in very little time. If we are working in a small team, as we often are, we might verbally tick off the possibilities. In the worst cases or in larger groups, we turn to the whiteboard and do a more formal job of brainstorming and filling in the columns.
4. Repeatable Results
We must be doing something right, because innovative high-tech companies like Siemens, Nortel, and Lockheed keep bringing us back again and again to train their people. We can help your design and development professionals produce more usable applications in less time. For as few as 10-12 people, we can design and deliver a training solution customized just for your staff. For details, send an email with information about your group and its training needs to: (mailto:firstname.lastname@example.org).
If you don’t have enough people to justify bringing us to you, join us in New Hampshire for the next public seminar in usage-centered design the week of 6-10 May 2002. Like all our teaching, this seminar is an intensive hands-on experience. We’ll be covering everything from agile card-based modeling techniques to instructive interaction, so don’t miss it. Details are on the Web at (http://foruse.com/seminars/).
= = =
To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:email@example.com>