Alan Cooper on Agile

I'm reading Alan Cooper's The Inmates are Running the Asylum, and his outlook on the use (or mis-use) of agile was especially poignant to me.

Alan Cooper, like many other designers, views agile as a potentially valuable, though horribly misused process.  The use of agile methodology as a reason to just throw features at users and let them design your product is insulting, inefficient, and ineffective.  If the design isn't done before the programming starts it will never have much effect.

"Just because customer feedback improves your understanding of your product or service, you cannot then deduce that it is efficient, cheap, or even effective to toss random features at your customers and see which ones are liked and which ones are disliked... 

[This manager believes] that his customers don't mind plowing through his guesses to do his design work for him.  There might be lots of ["power users"] who are willing to help this lazy executive figure out his business, but how many struggling [average users] did he alienate with that haughty attitude? 

As he posted sketchy version after sketchy version of his site, reacting only to those people with the stamina to return to it, how many customers did he lose permanently? 

...The biggest drawback, of course, is that you immediate scare away all [the average users], and your only remaining users will be ["power users"].  This seriously skews the nature and quality of your feedback, condemning you to a clientele of technoid ["power users"], which is a relatively small segment. 

I am not saying that you cannot learn from trial and error, but those trials should be informed by something more than random chance and should begin from a well-thought-out solution, not an overnight hack.  Otherwise it's just giving lazy or ignorant businesspeople license to abuse customers."

Design, he argues, is tasked with creating a product that can be built and perform well; that can be distributed and sold profitably, and that makes a success by being something people really want.

Far too often the paradigm of agile is used as an excuse for managers to get more code quickly...somehow arguing that lean practices and agile methodology are good reasons to forgo the crucial work of considerate thought and design.

These people, while acting on a good faith basis to prevent over-analysis and reams of documents from delaying the actual development work on a project, have failed in the other direction: no planning and no documents at all.  While well intentioned, this is the same mistake just taken to the opposite, perverse extreme.

This is not an improvement, or striking a bold step toward progress...it is blindly fumbling your way toward completion, making completely avoidable mistakes along the way.  I think Cooper encapsulates that nicely in the above selection.

Don't Make me Think!

Steve Krug is as adamant a defender of simplicity as you'll find anywhere:

The point is, when we're using the Web every question mark adds to our cognitive workload, distracting our attention from the task at hand.  The distinctions may be slight but they add up, and sometimes it doesn't take much to throw us...The fact that the people who built the site didn't care enough to make things obvious - and easy - can erode our confidence in the site and its publishers. (Don't Make Me Think, p15)

In their relationships with others, people keep an internal account of good and bad deeds done to them by others.  That account isn't a concrete list of things, but more of a general sense of whether this person has treated him/her well or not.  It's a concept Steven Covey calls an Emotional Bank Account.

The evolution of technology has gone much faster than the biological evolution of the brain.  Because of that, a fundamental portion of our brains can't distinguish between actual faces and faces shown on a screen.

Likewise, that same part of the brain can't distinguish between interactions with technological objects and other people which fosters a tendency to develop feelings about those faces and objects.  (Remember the last time you cussed at a computer? Kinda makes sense now, doesn't it)

One of the ways to help build a positive relationship between the user and your site is to pass what Krug calls the trunk test in his book Don't Make Me Think.

He argues that thoughtfully designed sites should make it easy for you to find most of the following six elements (though not every one is on every page): Site ID, Page Name, Section and subsection, Local navigation, "You are Here" indicator(s), and Search.  On the left is an example from the book.

He calls it the trunk test to equate arriving on a new site to being abducted, blindfolded, thrown into the trunk of a car, then driven to a field and dropped off in unfamiliar territory.

Since Google is responsible for getting most people to new unfamiliar sites, he says the same sense of disorientation happens to people when they encounter a new site, and having most of these elements easily identifiable and available can help ease users quickly feel more familiar with their surroundngs.

I found when designing my first wireframes from scratch that these guideposts were incredibly helpful.  There is a lot of web design that should be new and innovative, but this book helps to ground the beginner in the basics of those helpful conventions that let users feel more at ease.