Site FeedPalimpsest has moved. Please visit our blog in its new location for the most recent posts from Scriptorium.
Palimpsest
DocTrain: Keynote from David Platt
Thursday, October 18, 2007 — posted by Sarah
I'm at DocTrain East in Boston this week.We're starting out with a keynote from David Platt, author of Why Software Sucks...and what you can do about it.
Internet users in 1994 were almost exclusively academics/researchers; about 2 million total. Lots of technical support; no deadlines.
In 2006, we have 1 billion WWW users and almost all of them are using personal computers. New computer users and no support.
Platt's First, Last, and Only Law of User Experience Design:
Know Thy User for He is Not Thee72% of adult population doesn't have a college degree, but of course software is developed almost exclusively by people with college degrees.
"Normal people don't drive stick shifts". But a lot of programmers prefer them -- inconvenient but more control. Software developers like the process of driving the car; normal people prefer to just get there.
Software applications tend to sacrifice ease of use (which developers don't care about) for fine-grained control (which developers do care about but users don't).
Users just want the software to work.
Interfaces matter -- the example is ups.com, which is pain to navigate. However, you can drop a UPS tracking number into a Google toolbar and get the tracking information in one click. Thus, Google is a better UPS tracker than ups.com.
Constant friction -- extra clicks cost money because they take time.
Catastrophic error -- Mars Orbiter, medical errors...
Personal public ridicule -- People publish lists like "web pages that suck"
Five ways to make a project suck less:
1. Add [a person who does not know the internal workings of the software] to the design team. I think he might have lost some of the audience when he said that tech writers would be ideal for this.
2. Break convention when needed (Quicken/MS Money never offer to save your content; they just do it.)
3. Don't let edge cases complicate the mainstream
4. Instrument -- carefully. Use feedback agents to get information about how software is being used.
5. Always ask: is this design decision taking us closer to "just working" or farther away?
Entertaining, but he's used to presenting to nearly all-male, all-programmer audiences, and much of what he's doing here was preaching to the choir.
Labels: conferences, doctraineast07, humor
7:56 AM Permalink |
|
<< Home
