Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

  (email not shown publicly)
AOL IM: MichaelSchwern (Add Buddy, Send Message)

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Friday August 03, 2007
02:26 AM

The blind driver

[ #33973 ]

Following up on "Seems perfectly sensible to me", which was part of a thread, here's Austin's quite pragmatic question and my response.

Austin Schutz wrote:
> So.. after all the ranting, what's the proposed solution? Have the
> users take a survey for every minute UI change?

Before you can find a real solution must first understand what the real problem is. With a proposed solution like that, I'm not sure you understand. That's ok, it takes a number of blows to sink in.

User focus groups vetting all your changes doesn't solve the real problem. The programmers are designing unusable features, they're doing the wrong thing. Then the "user interface group" comes along, points out what's wrong and the programmers have to correct their mistakes. Then the programmers do some more wrong things and the UI group fixes them. Its like a blind driver with a guy in the back seat yelling "LEFT!" "RIGHT!" "LEFT!" "RIGHT!" zig-zagging down the road, covering twice as much ground as going straight should, not really understanding why he's turning the wheel, hitting the odd light pole and pedestrian along the way. The solution isn't to develop a better signaling system between the back seat and the driver, the solution it to take off the blindfold.

(This analogy, btw, works quite well for any sort of "I'm going to write crap and let someone else clean up the mess". For example, programmers not testing their code and expecting the QA department to find the bugs.)

A solution is to "Play Dumb". This involves being aware of what you know that the user does not and switching off those parts of your brain while using the product. It takes time and effort. It takes sitting down with the user and seeing how they use the product. It takes more than I can cover in an email. :)

There's an entire discipline for this called Human Interface Design or Interaction Design and Eric can probably tell you more.

To that end, I highly recommend reading "The Design Of Everyday Things" by Donald Norman particularly focusing on the discussion of how a user model is formed. If you ever wonder how devices are designed that don't need instructions, read that book.

The other two which keep getting mentioned, but I haven't read myself, are "Don't Make Me Think" and "The Inmates Are Running The Asylum". And that's someone's cue to fill in about those books.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Go read everything that Don Norman has written. Clever dude.

    "Don't Make Me Think" - good, if a little oriented towards W3 work.

    "Inmates" - I find this a very interesting book. Good at identifying the problems and issues. Massively incorrect solution (IMHO :-). Almost every developer I know whose read it gets angry since the language used about developers isn't the most... diplomatic... shall we say. Cooper's view is basically that developers shouldn't be let near UI design - and that it should be left t

  • apple, of course, is a perfect example of this sort of thinking. no focus groups by design; either to maintain secrecy or to avoid the waddling march to mediocrity. three ways of thinking about this process--

    1. coder-centric: "let's make this work the way we think it should work"
    2. survey-centric: "let's find out how the user thinks this should work"
    3. user-centric: "let's make this work the way we know the user actually works"

    if you're good, and you obsessively practice the craft of learning how people pe