Topic Archive: Diagnose

If the hat fits–do you wear it?

Elyse Sanchez, Tuesday, June 27, 2006 @ 6:57 pm

I've just completed the first of three days of usability testing for a new educational online subscription product.  The multiple sessions are stacked consecutively; the 45-minute breaks I thought were ample in theory seemed to last as long as a single gasp today, as our team fought--not always successfully--an unfolding series of unfortunate technology events.

Still, I love the opportunity to do usability testing. I've been very fortunate in my career in UXD to have always worked in environments that did not create an unscalable wall between Information Architects and Usability Specialists. 

If research, including usability testing, can be defined as "diagnosis," and creation, including wireframes, site maps, taskflows, and the like, comprise "design," these two complementary, yin-yang aspects support, validate and enrich each other. I love the opportunity to play both of these roles, to wear both hats. I think it's made me better in each, and takes me back to my early education in arithmetic, where we "proved" the accuracy of any single answer through the complementary operation--the division problem was proved through multiplication, the subtraction problem through addition.

Usability testing diagnoses design. It's the analysis of user reaction as opposed to the creation of user action. Diagnosis looks outward to the users, acting upon the design; design looks inward, to the designers acting in lieu of the users.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Breaking the First Commandment

Elyse Sanchez, Saturday, June 3, 2006 @ 9:04 am

The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this.  UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)

If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically: 

Know thy users, and thy users are not thyself

It's a good guideline, of course:  as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.

But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.

And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive:  after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.

To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Biting the hand that feeds us

Sholom Sandalow, Tuesday, May 2, 2006 @ 3:03 pm

Talk about poor design!  The Typepad 'Post' page--the page I’m on right now-- is a great example of a poor interface.  What do I mean by this? 
Well, lets take a look at it.  Now in my opinion, when we get right down to the heart of it, the object of an interface is to help the user accomplish a task.  Weather the you want to obtain the latest baseball scores on espn.com or to configure an electronic substation monitoring system, the interface you use is designed (hopefully) to help you accomplish what it is you set out to do. 
When building a web site, designers usually have to deal with the uncertainty of potentially large numbers of visitors (or 'users' for consistency) and associated tasks.  However, there are pages like this one here were all users are performing the same task. 
The object of the design here should be pretty straightforward, and that it to make writing and posting a blog as painless and efficient as possible.  The buttons that perform functions associated with posting (such as adding pictures or links) should be easy to understand, and most importantly, the act of posting the blog shouldn't cause lots of confusion. 
Here are some examples of the poor design of the Typepad 'Post' page...The "Insert Image" and "Insert File" buttons are icons with no accompanying text despite the fact that there is plenty of room.
The button that adds white space for larger posts is confusing, again, despite the fact that there is plenty of room for a more descriptive button.  Keep in mind that users, afraid of losing the post they are writing, will be hesitant to click on any links, so it becomes even more important to make button actions clear.
The design blunder that causes the most confusion is the positioning and terminology of the button that does the posting.  When the ultimate object on a screen is always the same, and the completion of the task is accomplished with the click of one button, that button should be named for the verb phrase of the task being accomplished.  In this case I am posting a blog entry.  The button is called "Save", which is not what I think of doing when I want to post what I've just written.  More confusing still, the proper term for the button, which of course is 'Post', is the name of the prominently placed clickable link that erases what you were writing and starts over. 

• Digg
• Reddit
• del.icio.us

Comments (1)

user experience design