 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #9 | November 2000 |
|
 |
||
| Subscribe! |
   |
|
|
|| Contents: = = = = = ForUse.com has become a leading resource for usability and design = = = = = Do your colleagues a favor: forward this issue to them. They can 1. Roles and Real Requirements: Using a Role-Support Matrix Customers, users, and upper management often generate long wish-lists of desired features and functions. In fact, especially on Web-based projects, these fantasies masquerading as requirements are often among the first artifacts to be generated. In many projects, a base of genuine needs and necessities has been generously larded by creative license. Among real requirements and some good ideas are usually more than a few features that will ultimately prove to be of limited or no value even though they may be costly to deliver. Two client organizations that we have been working with have independently developed variations of a useful reality check that can help extract the core requirements of genuine needs and necessities from a plethora of proposed features, functions, facilities, and content. Using this approach, once a list of user roles has been identified, fantasies of system contents or capabilities can be cross-checked against those user roles to be supported by the system or site. We refer to the technique as a Role-Support Matrix. One version of this lists proposed capabilities or contents against the user roles the system is intended to support. Each of the roles becomes a column in a table; proposed capabilities or contents of the software or Web site become rows in the table. The table is reviewed to see which, if any, of the identified user roles is actually supported by each particular capability or content. In each cell of the table, a value from -2 to 2 is entered:
Features, functions, or content that end up with only 0s next to them are clearly not requirements with respect to the work to be performed or the end-user population to be served. Any content or capability without a 2 in at least one column is optional and could be a candidate for being dropped from the project or deferred until a later version or release. Content or capability with -1 or -2 for any high priority role should be carefully reconsidered for possible removal. 2. Professional Proliferation What's your game? Many different professional fields and specialties are involved in designing modern software and web-based applications, and many of these now deal with various aspects of usability. These professional areas include information architecture, interaction design, graphic design, visual design, user interface design, usability engineering, user intelligence, and user experience, among others. Some professionals rather rigidly segregate areas of interest based on academic or historical definitions. The term "usability engineering," for example, has become so strongly associated with Jakob Nielsen and his "discount" techniques, that its usefulness for referring to the broad field of engineering for usability has effectively been usurped. Especially on the Web, newly minted specialties abound. The Web is hailed as the new frontier and new professionals are hanging out their shingles under highly varied titles. Some of the newer coinages even claim to supercede the older professions. For example, you will hear claims that "user experience" is more comprehensive and far more important than "mere" usability because it embraces all facets of the interaction between the user and a site. Some interaction designers by title or temperament proudly pronounce that they go "beyond simple user interface design" and assume responsibility for every aspect of design that could affect the interaction between users and the system; other interaction designers see their field as rather narrowly focused and insist that they do not do layout or graphics. It is hard to sort out the various claims and counter claims in part because there are no accepted definitions for most of these fields and no specified courses of study or certification processes to mark who is and who is not a practitioner of this or that specialty. One talented information architect we have worked with has a degree in literature, specializing in critical theory and literary deconstruction. Go figure. Job titles and territorial claims of professionals aside, the design of an interface between users and a system--whether an application or a Web site--involves resolving issues and making decisions within certain basic dimensions. These include both appearance and behavior, as well as components and layout. As we think of it, visual design addresses the appearance of the interface; interaction design deals with the behavior of the interface and how users will interact with it. However, regardless of how much we might want to simplify and separate issues and to parcel out the work, visual and interaction design are fundamentally inseparable, particularly if the objective is the best fit to the tasks of users. Thus these two aspects of user interface design--each complex in its own right--must always be tackled together. If you have interaction designers and visual designers who insist on keeping to their narrow focuses, then you must make sure they work together closely and from the same guiding design models. Both the components or visual elements of a user interface and their layout within the user interface are design aspects that must be addressed in the course of visual and interaction design. These aspects are also inextricably interwoven. Layout constrains the admissible choices of components, and alternative components will vary in the use of screen real estate. In other words, whatever the titles of your designers, the same basic issues must somehow be resolved, and, like it or not, they have to be resolved together because of their intimate interconnections. If you can't find one person who can master and oversee all these aspects, you need to build a cohesive team in which specialists collaborate closely to produce the best possible designs. 3. Aesthetic Usability or Usable Aesthetics Continuing on this theme of professional specialties and design issues, we usually prefer to have usability drive graphic design rather than the other way around. This is not because we are control freaks but because, in our experience, far better results are obtained when usability is in the driver seat and artistic matters follow behind. For example, on one project we needed a set of icons for top-level navigation in an information management system for classroom teachers. We worked closely with a graphic artist experienced in this area, beginning with a discussion of the usability goals. After we supplied a starting point in the form of some suggested visual concepts for each icon, the artist developed sketches and renderings. These were critiqued and refined through several rounds before being reduced to 24-by-24 bitmaps. The results maintained an appealing and professional-looking aesthetic while serving the usability goals of quick recognition, good differentiation, and easy retention. Recently, we had to cope with a reversal of roles when we were charged with rescuing a web project after usability inspections had revealed major problems shortly before a planned beta release. However, the graphic design and information architecture by a major web design shop had already been enthusiastically approved by our client's upper management. Our challenge was to reach an acceptable threshold of usability without radical redesign and without compromising the aesthetic integrity of the approved graphic design. It turned out to be a fun challenge. The client was ultimately pleased by the results, and we were surprised with how much could be accomplished while "staying within the lines." Our approach amounted to this:
As the team worked to resolve problems and brainstormed solutions, I often found myself taking on the role of defender of the original aesthetic concept. We had to keep trying to stuff things back into the original box, always seeing how little needed to change to accomplish our usability objectives. The most preferred solution was often too far out of line, so we strived to see how close we could get without violating the established look and feel. In one instance, a completely new set of icons was needed, but these had to be designed to be more recognizable and better differentiated without breaking the original "feel" and visual aesthetic of the home page. In another case, when a 3D bevel effect might have been preferred, we settled for a drop-shadow to separate visual components from the background while keeping with the original more-or-less "flat" graphic style of other visual design elements. We also checked our proposed revisions with the lead designer and information architects from the design shop to insure that we had not done too much violence to their original concepts. This check-in process yielded a bonus. The original designers were able to offer useful suggestions, including some drawn from previously discarded design alternatives. 4. Usable Training: Sell-Out Seminar Series Demand for training in usage-centered design continues to outstrip the supply, so we are offering another full-week seminar 5-9 February. This newly revised version of our highly successful series incorporates new developments and reflects the accumulated experience of our work with practitioners around the globe. Each of our seminars has sold out far in advance, so get your registration in early at: <http://foruse.com/seminars/>. =
= = = To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:unsubscribe@foruse.com> |
||
| Subscribe! |
|
|
|
|
||