- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
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.
Topics: Design, Ethnographic Research, Personas, Usability, User Experience
Comments: 4 so far
Leave a comment
About Pathfinder
Recent
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006


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
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
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
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