The Inmates Are Running The Asylum
The Inmates Are Running The Asylum"The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity" by AlanCooper, PaulSaffo?
(ISBN 0672316498 ) This book about usability is chock full of ideas that need to be discussed by the software community.
One key point is the distinction between the goals and the tasks of a product. The way I understand it, a goal is either a basic need, such as warmth, food and shelter or it is something you might dream about on the beach. You may dream about castles in Spain, getting rich or finding homes for stray cats. You won't dream about printing a report, adding a record to a database or emptying the recycle bin.
The software process binds goals or dreams to tasks that are needed to realize them. Finding a castle in Spain may involve viewing an online map, searching for available hotels and booking an online flight reservation.
AlanCooper believes that a major problem with software is that it focuses too much on tasks and too little on goals. The result is software with whiz bang features that nobody wants.
-- CayteLindner
While you can't do dreams, you can do tasks.
ItDepends on whether you are awake or not. In a dream, you are usually just a viewer or inactive director. Thing happen, you notice, you react, but nothing happens, because you are not awake and can't make things happen. Often in the dream, the things happen over and over until you wake up, and do something about what you have perceived the dream requires. In the midst of such a dream recently, I was in an endless loop of the thing happens, I notice, I reacted, but nothing happened. Until in the dream, I perceived that a cell phone was ringing somewhere. I didn't know why a phone would be in the dream, but for some reason or another, I woke up, remembered the dream and just out of curiosity, I located my cell phone, which was in the same room, and upon flipping it open discovered the message '1 missed call'.''
The point: While often, dreams are about things we can do nothing about, on occasion, occurrence of enabling events make it possible to "do" parts of the dream. It may be that accidents of this sort are more important in the "doing" of things in dreams than the frustrating and ill-defined sensations usually associated with dreams, whether awake or asleep.
Does anyone else have this pattern?
There is no point in doing the wrong tasks. Not only are you wasting time, but, by bloating the product with features you don't need, you are making it less usable. A double whammy.
Cooper was asked to design software for a scanner. By thinking about the key personas, he realised that the majority of users only needed the ability to crop and resize images. There was simply no need to build-in any other image manipulation features because anyone advanced enough to need these features would already have Photoshop (or whatever) installed. So instead of spending their time developing unnecessary features the developers spent their time developing world-class cropping and resizing tools.
There is good news and bad news. The bad news is that Cooper gets the process stuff entirely wrong. p. 120:
The good news is that the InteractionDesign techniques in the book are first rate- more approachable than the techniques in SoftwareForUse?. -- KentBeck
And the reason why Alan Cooper's process is wrong is because???
If you'd actually read the book, you would have realized that Cooper wants developers to no longer be responsible for product quality. -- RichardKulisz
The programmers are rarely (in my experience) the ones forcing the process to produce code before design is done - that belongs to project managers, salesmen who promise products that don't yet exist, and executives who sign up for "tight" deadlines. Most programmers I know would love to have the whole interaction set defined before starting
Btw, I don't think that salesmen promising products that don't yet exist in any way forces the production of code. It really depends on who the salesmen are talking to, don't it? If they're talking to interaction designers, as they should, then their promises merely force design along. If they're talking to programmers, as they do, only then does it force coding.
One of Cooper's techniques is to create an imaginary user (a "persona") and design directly to the persona's needs. This imaginary user is supposed to resemble a real person as closely as possible - the idea is to choose and design features for a specific user, rather than trying to look at the needs of all the potential users for the product. We've used this technique to what appears to be good effect over the past 8 months or so. -- CurtisBartley
My main concern about this technique is validation. How do you validate that your imaginary user is actually representative of your true users, and how do you validate that you have accurately imagined how your imaginary user will act?
This is a good point. We are by no means purists, so we use whatever tools work. One of the tools we use is usability tests with real people. We have definitely made UI changes based on usability feedback on features that were originally designed using personas. -- cb
Isn't marketing and business supposed to know who the user is (KnowYourAudience)? -- ErikMeade
Marketing and business know who is *buying* the product. Interaction Designers find out who is *using* the product -- SteveQuinlan
"The single most important process change we can make is to design our interactive products completely before any programming begins"
This raises the question "What is Design?". I'm totally for evolutionary design of coding. But when it comes to something like an user interface, I'm not so sure that they scale well in an evolutionary way. I think it's worthwhile finding out the goals of the user upfront and designing an interface that solves the user goals in the most efficient way possible. Since the user stories can then be based on this upfront design, Interaction Design techniques can slot nicely into XP. -- SteveQuinlan
I'm no expert at VisualBasic, but it sure looks like the declaration, initialization and operation on a variable must be in three different places. I wonder if this alone accounts for the single most important process recommendation above? -- WardCunningham
VB requires that variable declarations and operations be in separate statements. (Initialization to zero, "", null, or false is implicit in the declaration.) By convention, many VB programmers declare, initialize, and operate on variables in three different places - but they don't need to do so. Some programmers put the variable declaration (with implicit initialization) on the line immediately before the first use of the variable.
With respect to the above, discussion, and coming from an XP point of view, I certainly would have to disagree with "design our interactive products completely before any programming begins". On the other hand, if we could simply change that to "design each story of our interactive products completely before any programming on that story begins", I'd be totally happy with that, and if you say user interface design people should be involved in that process, I can buy that.
To apply XP to the process with most of Cooper's values as summarized above (and I think that would be a good thing), the whole process simply must simply use ConcurrentEngineering?. All the parts of the process are worked on all the time, so the results of each inform the other. For instance, when users are interviewed, it can help to show them a working interface with working code, and see where they get frustrated. Also, when spec'ing out the product, it would be nice to already have rough cost estimates for the features you're trying to decide whether to add in or leave out.
Sorry, but you're completely missing Alan Cooper's point if you think it's at all acceptable (let alone desirable) to have a working product before you talk to the users about the interface. In fact, there must be a whole chapter of the book devoted to tearing down and bashing that particular idiocy. Nobody in the world expects the architect to work "concurrently" with the building engineers. Only in the software world do people expect blueprints to be made after, or at the same time as, the concrete is poured.
It's also clear that you haven't read the book since you're talking about "user stories" which The Inmates Are Running The Asylum never does. You also speak of "interface" instead of interactions, another sure fire sign that you haven't read the book.
I haven't read the book, and I'm not commenting on the book. I'm commenting on this discussion. Frankly, I've been drawn to XP because I've become convinced of the idiocy of trying to design a software product completely before building it. Even from the UI perspective, that assumes that you can correctly predict the user experience before having them actually try to drive the UI. A software program is -not- a building, and user interface can start out simple, and evolve just as a program can. It makes total sense to me to start out with a simple prototype program and UI, then have the UI designers make decisions about how to improve it, and have the programmers write the code to support those changes.
I suppose it's unfair for me to bash someone who isn't here anymore but screw it. The poster here hasn't the slightest clue what the hell he's talking about. And it certainly does not make any sense to have programmers "write the code" without knowing what the hell they're writing it for.
Please note that this phrase is fairly common idiom, at least in the USA.
Insanity is relative. :-) -- top
You wish. ;-)
See the charming 1966 French movie "Le Roi de Coeur", on the same topic as this page title...more or less. http://www.imdb.com/title/tt0060908/
Fun. Recommended. -- DougMerritt
EditText of this page
(last edited October 12, 2006)
or FindPage with title or text search