Following up on "Seems perfectly sensible to me", which was part of a PDX.pm 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.
Book reviews (and some suggestions)
Adrian on 2007-08-03T09:04:45
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 to the experts. My view is that we should encourage developers to become more expert. Worth reading though.
Cooper's "About Face" is also good.
Other books that would be on my shopping list for developers would be:
- Jenifer Tidwell's "Designing Interfaces" - nice since it uses the language of patterns that many developers are now familiar with.
- Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design by by Larry L. Constantine and Lucy A.D. Lockwood.
- Bill Moggridge's "Designing Interactions".
- Carolyn Snyder's "Paper Prototyping".
(can you tell you've hit a hobby horse of mine :-)
apple and the craft of knowing how people work
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--
- coder-centric: "let's make this work the way we think it should work"
- survey-centric: "let's find out how the user thinks this should work"
- 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 perceive and use tools--as apple does--(3) is a no-brainer. the question is, how do you get better at (3) to begin with, and barring the time to improve in that area, is (1) or (2) actually more of a waste of time?
Re:how about just being logically consistent?
I was replying to this, but it got long.
