 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #26 | October 2002 |
|
 |
||
| Subscribe! |
   |
|
|
Contents: || 1. Training: Passing it on Pays! = = = = = 1. Training: Credit for Colleagues Our last scheduled full-week public training on usage-centered design is coming up 11-15 November. Through 11 October, you can save $500 on every registration just for signing up early. Readers of this newsletter get special treatment. Register 3 or more participants together and get the Corporate Rate normally reserved for 5 or more. That's a savings of $700 each off the regular cost. However many you register, you get an extra $150 discount on each. To get these special rates, just enter your email address under Special Instructions. As a little incentive to pass on the good word, for every friend or colleague from another firm or organization who enters YOUR subscription email address under Special Instructions when they register: * THEY get $100 off their registration. To sum it up again: Save $500 by registering by 12 October. Details and registration at http://foruse.com/seminars/. 2. Design: Picking Appropriate Parts. Picking the right user interface component or control for a particular problem is an important step in the later stages of visual and interaction design. Although design dilettantes may be pretty casual about control selection, more careful and conscientious designers can find this process vexing. There are rules that help guide some of the simpler decisions, such as radio buttons versus check boxes, but the rules are few and of limited scope. Abstract prototypes can help designers take this part-picking step without stumbling blindly into haphazard solutions, and the use of canonical abstract components makes it easier to spot patterns in what choices are appropriate under what circumstances. Still, for the most part, designers are more or less on their own to figure out what might work best in each circumstance. Toughest of all are decisions where more complex combinations of controls or non-standard designs are being considered. One of our strong advocates of usage-centered design within IBM recently sent an email query about a particular design. His question concerned a variation of what is sometimes referred to as a “slosh bucket” scheme. The standard scheme uses two parallel lists with command buttons in between to allow users to move objects back and forth between source and target “buckets” in order to create a custom-configured list of items in the target bucket, invariably on the right-hand side. The dialog our colleague sent supports creating a list of scheduled events. The usual source bucket on the left was replaced with a series of selection lists for different aspects of events to be scheduled--such as starting date, frequency, and the like--with buttons labeled Add, Change, and Remove. He wrote: "The dialog extends the 'slosh bucket' pattern (for selecting among available objects) for use in editing list items. The question of interest is, is this an innovative design? Or is this instead an example of inadvisable violating of the conventional design (pattern) for this type of interaction. A more conventional design would display the list with buttons to Add, Properties, Remove. The Add or Properties button would launch a Properties dialog [for the Schedule item]." We have said many times that, from the perspective of usage-centered design, the issue is neither whether a design is innovative nor whether it conforms to a particular pattern or standard, but whether it works for the intended purposes. Does it enable users to fulfill their intentions efficiently, reliably, and without external instruction? Basing design decisions on user tasks, as in usage-centered design, can lead to innovation or to convention, to novel features or familiar ones depending on the tasks at hand. It is the job of the designer to pick what best fits with the work and to design it for transparent use. Adherence to standards and conventions is bad if it leads to awkward interaction that does not closely fit the tasks at hand. In the example, I could see things to criticize and possible room for improvement, but these were not matters of innovation or adherence to standards. As to the standard solution, a "Properties" button may be conventional, but it is a geekish convention; "Change" is closer to the users intention if they want to edit or alter a scheduled event. The modified "slosh bucket" scheme has the advantage of surfacing the tools and materials needed to create new schedules rather than requiring users to invoke a separate dialog that adds another layer of interaction. However, one could question the need for a "Change" button. Why can't the user just edit the fields defining the events within the target list? In fact, the ability to edit-in-place is a simplification that proves to be a user time-saver in many applications. Where screen real estate is sufficient, small "Delete" buttons might be arrayed next to each line in the list, a scheme that is becoming increasingly common in "shopping carts" on the Web. The approach is more transparent because (in keeping with the Structure Principle) it puts the action exactly where it is needed: with the related object. In this scheduling dialog, it is also more efficient and straightforward because it does not require users to follow the more awkward sequence of first selecting an item in the list to the right and then choosing the action of "Remove" from the buttons in the middle. The Structure Principle can also be invoked to argue in favor of organizing the source fields in the same horizontal arrangement as the fields within the target list, which would lead to a decidedly non-standard but very transparent variant of the slosh bucket scheme: the source fields would be arrayed in a line above the corresponding fields in the target list with an "Add" button between. In short, the "best" choice of controls to fit a particular problem may often lead to non-standard variations on standard schemes. The designer has the responsibility of working out the details of the visual and interaction design to make the results as transparent as possible. For example, if edit-in-place is used for fields in a list/grid display, the fields themselves need to have the correct visual affordance--they need to look editable. Attempts to systematize control selection have been made by various writers. Another colleague, Hermann Kaindl at Siemens in Austria, has been working on a process for selecting classes of standard components based on task scenarios. The proposed technique is outlined in his new paper with Rudolf Jezek, "From Usage Scenarios to User Interface Elements in a Few Steps" (http://foruse.com/articles/kaindl.htm). 3. Modeling: Persona Popularity and Role Relationships Personas are everywhere. Although the origins of personas are obscure, Alan Cooper, who appears to have been influenced by our work on user roles, is generally credited with popularizing them for product design. Now other designers and methodologists seem to be lining up to join the personas parade. At the forUSE 2002 Conference, the panel on “Roles and Personas, Task Cases and Scenarios” bordered on a love-fest for personas. When panelists were asked to pick one concept or element worth borrowing from the other approaches represented on the panel, personas came out the hands-down winner. Panelist Karen Holtzblatt subsequently wrote an article on how personas can be developed using the rich data produced by contextual inquiry (http://www.incent.com/community/design_corner/02_0913.html). We made the connection with usage-centered design some time ago and outlined our own use of personas as an addendum to user roles in an earlier newsletter (http://www.foruse.com/newsletter/foruse15.htm#3). We have become convinced that incorporating both UML-style Actors and Cooper-style Personas can actually make things easier in many cases. Sometimes an extra step or two can actually speed up a process by simplifying thinking and cutting through murky waters. Many analysts and designers, conditioned by the ubiquitous UML and convinced by the relentless Rational sales team, think first of Actors. User Roles are actually more to the point for user interface design, but thinking about Actors can make it easier to map out the Roles they play. For this reason, we find it often speeds up the modeling process to begin by mapping out all the players in the story, even those who do not figure directly into shaping the user interface design. The analyst/designer who wants to map out the complete context of use for a particular system must complete a number of activities to identify all the Actors and the Roles they play. For good reasons, Actors and Roles come before Personas. (1) First, identify all the Actors that interact with the system of interest and for which the system must supply some capability, whether or not these are people. (2) Next, distinguish User Actors (people) from System Actors--non-human systems that interact with the system of interest. System Actors are part of the problem to be solved, but they are not part of the user interface design problem. Requirements associated with System Actors shape internal and back-end design, but can usually be set aside for purposes of usage-centered design of the user interface. (3) Among the User Actors, distinguish the Direct Actors who have hands-on interaction with the proposed system from Indirect (or Mediated) Actors who do not directly interact with a system but rather "use" it through intermediaries. These "off-stage" players are involved in the story but, like extras in a movie, are really part of the context within which the interaction takes place. Often they are important stakeholders, so we do not want to forget them, but we need not directly model them in detail for effective usage-centered design. For example, in a telephone sales application, among the Direct Actors are the telemarketers, whereas the customers on the other end of the phone are Indirect Actors whose participation is mediated by the telemarketers. We design the screens for the telemarketer, the on-stage Actor, but we must take into account the off-stage voice of the customer who is on the other end of the line talking with the telemarketer. (4) Now, identify the Roles that Actors play and within which they interact with the system of interest. A Role is a relationship. Exactly as on the stage and screen, an actor may play a number of different Roles, and a given Role may be played by any number of Actors. Because the Role focuses on the relationship of users with a system, it captures most closely what it is important to understand to lead to the most effective visual and interaction design. Telemarketers might have very different relationships to a sales support system depending on whether they are cold-calling or responding to telephone inquiries; we might call these the Telephone-Inquiry-Handling Role and the Telephone-Selling-Role. The Telephone-Inquiry-Handling Role, in turn, might be played by either a Telemarketer or by a Supervisor. (5) Then, rank or prioritize the Roles in terms of the frequency with which they are played and their importance to the business/practical success of the system or application being designed. The top few on these factors become "focal" Roles, ones that assume special prominence in shaping a successful design. In a sense, these are lead roles that take center stage in driving the design to a conclusion, while supporting roles have significant but less central influence. (6) For each of the focal Roles--those that are the most common and most important to the success of the application-- a Persona can be constructed. A Persona is a plausible personification of the archetype or ideal represented by the Role. We develop Personas at this stage rather than to start with because we can be assured of picking the right representative user(s) only after we have catalogued all the relevant kinds--the various Roles--and sorted them into order. Personas enable us to capture the essence of the most important User Roles by fleshing out Roles with gratuitous details that lend verisimilitude to the description. Because Personas seem more "real" and are typically more engaging than User Roles, they can sometimes be more effective for engaging and drawing the attention of designers and developers. A Persona is the personification of a Role. One might say that a Persona has character, while a Role has characteristics. Characteristics focus designer attention, but character promotes identification. The entire usage context can be summed up with a simple variant of the traditional context diagram. A big rectangle or oval represents the boundary of the system being designed. System actors are shown as connected directly to that system boundary, as indeed they are. Direct Actors--the on-stage players--are shown as connected to the system boundary by way of the various Roles they play; arrows run from Direct Actors to Roles and from Roles to the system boundary. Indirect Actors--the off-stage players--are shown as connected to the Direct Actors that serve as intermediaries and through which Indirect Actors are involved with the system. Picking up on a remark made by presenter Chris Armstrong at the forUSE 2002 conference, we have revised slightly our notation for user roles to make them both more metaphorically suggestive and visually more distinct from the UML symbol for Actor. You'll find a sample context diagram using these now standard conventions at www.foruse.com/images/contextdiagram.gif. (The icons are deliberately abstract and simple. The symbolism is fairly transparent. A tongue-in-cheek icon for Persona is thrown in for completeness, but is unlikely to see much use.) The paper and presentation by Chris Armstrong and Bobbi Underbakke on usage-centered design and the UML can be found in the Conference Package (see details below). Perhaps the single most important point about Roles versus Actors versus Personas is that the User Role focuses primarily and exclusively on the relationship between the user and the system. Interaction design is about this relationship between a user and a system. Although other representations or user models may imply or include aspects of this relationship, the Role captures and features it front and center in terms that are most relevant to user interface design. So, by all means, model both System Actors and User Actors, identify both Indirect and Direct User Actors, and build those fascinating Personas to captivate and motivate your team. But, never forget, it's ultimately about relationships, and the Role IS the relationship. 4. Resources: Missing Material If you missed out on the many great presentations at the forUSE 2002 Conference, you can still get your very own copy of all the conference materials. The complete package (www.foruse.com/2002/package.jpg) includes: * Conference Proceedings – a handsome,
professionally edited, 484-page The special conference discount price to newsletter subscribers is no longer available. The price of the entire package is $150. To get details and order, click here. =
= = = To unsubscribe, just click here to send email. |
||
| Subscribe! |
|
|
|
|
||
