UXD: User Experience Design

Not-So-Great Expectations

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here's an extract:

So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That's it! That's the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise,  self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.

Comments: 4 so far

  1. We are talking way beyond Mac/Win here. I think it’s kind of a facetious argument. It assumes that there is an expected behavior. Which means we should design as if there isn’t? That eliminates any consideration of an expert user, or any familiarity beyond physical conventions that may apply – a pretty limited set of metaphors.

    But to return to the Mac/Win jihad, it becomes a case of the old tautology “That which is good exists, that which exists is good” Must we all be crushed under the yoke of MS oppressive tyranny? Their poorly formed and conceived relationships of use? Freedom! Freedom I say! Right, I’ll stop now.

    Charles

    Comment by Charles Field, Friday, March 31, 2006 @ 4:08 pm

  2. Yikes! This is a load of garbage. Your view is EXACTLY what is wrong with most software today. You think you need to gather all these use cases and process them to create a document how YOU see the software working.

    Too much software is created by people who think they know how the process works by reading a bunch of books by people who can only theorize how users need to be treated.

    Joel is right just by your example. Give me a break.

    Comment by Rob Bazinet, Sunday, April 2, 2006 @ 9:47 pm

  3. Are you suggesting not gathering user requirements? Your apparent disdain for use cases seems to indicate just that. If you don’t talk to users and try to understand what they need, aren’t you guilty of exactly what you are decrying, i.e. substituting your own opinion for that of the end user?

    Our conclusions are based on developing successful, usable software. Often, the mess we are called upon to fix is created by developers and designers who spend too little time thinking about exactly what is expected and by whom. If that is “garbage” then I’m happy to be a garbageman.

    Comment by Dietrich Kappe, Monday, April 3, 2006 @ 8:55 am

  4. No, I am not saying to toss out use cases. My disdain is really for the mound of paperwork most large companies require to produce software, if they ever do. They are of the mindset that there must be followed a “Software Development Process” that is really longer than the development process itself.

    The user MUST be involved in the design, to the point they are part of the team.

    I don’t want to sound like I am against all things organized but I am against the large-company mentality of need reams of paperwork to feel like we are doing the right thing….solving problems.

    Just look at the work done by companies like 37Signals and Fog Creek. Usability is the key to good software, which my original blog post indicates.

    Comment by Rob Bazinet, Tuesday, April 4, 2006 @ 7:50 am

Leave a comment

Powered by WP Hashcash

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com