Living with complexity

Don Norman's book The Design of Everyday Things has become a touchstone for those of us with a penchant for design.  It has introduced hundreds of thousands to his elegant view of the world and uncanny ability to pinpoint the essence of why some things just FEEL well designed.

His most recent book, Living with Complexity continues along those same lines, though pursuing a contrary tack to popular thinking.  Despite the growing popularity of stripped down, simple designs, Norman argues that simplicity is not always the right direction to take for a design.

Norman references Tessler's law of the conservation of complexity, which states that every application has an inherent level of irreducible complexity.  The only question is who will have to deal with it: the user or the developer.

He argues for a moderate view saying that some complexity is OK, even preferred.  Objects that are too simple can be boring, while things that are too complex are confusing or upsetting.

This discussion of simple versus complex is playing out now in the mobile software space.  Sophia Voychehovski, a UX designer for Turner, says the idea that mobile users are 'on-the-go' and therefore don't want or need the capabilities of the desktop site on their mobile device is false.

She said that users today don't want or prefer a stripped down version for mobile.  They don't want things simple in this context...they want equivalent functionality presented in an intuitive way.

Going further, overly simplified software also faces the danger of feeling too flimsy.  The lean startup concept of the minimally viable product has led to a series of software attempts that are flashy yet flimsy in the hope of attracting further funding.  In some cases, I find that overly simplified interfaces seem to feel more gimmicky than elegant.

It can be too easy for companies to see the work of Google and Apple and assume that a stripped down interface is what symbolizes a modern company.  Their examples, while simplified, reflect deep design work that caters to the well-researched needs of users...and the requisite complexity is just a layer or two away for those experienced users that crave the ability to tinker with the specifics.

Life has no error messages, Norman points out, and in this way software should emulate life more closely.  In life, if you try to fill a five gallon bucket with eight gallons of water, it'll overflow and you'll see water spill out.  There is no error message, you just see the result in front of you.  Instead of scolding the user for not following the parameters of its software, well-designed code should assist the user in how best to continue.

It is specifically in that moment, right as the user has taken a mis-step that they are most receptive to learning: they can learn best when they face the need to learn.

This reminds me of the implementation model Alan Cooper discusses, in which a software interface reflects the inner processes of the software instead of presenting only those options that correlate with what the majority of users are trying to accomplish.  The two men's ideas taken together advocate for software that helps users complete their goals while reflecting the requisite complexity behind the tool being used.

Striking that balance between elegant simplicity and overwhelming detail continues to be a challenge for user experience designers, and Norman's book helps to crystallize those issues into a continuing discussion of the merits of each.

The Inmates are Running the Asylum

Alan Cooper begins with a clear analogy: in all other construction disciplines the architects and engineers plan the construction strategy and the craftsmen execute that strategy.   It is only in software that the craftsman is also the architect.

This becomes the basis for his premise that The Inmates are Running the Asylum. Cooper argues that we are deficient in our development process, not the development tools themselves.

"Programmers aren't evil" he insists, "they work hard to make their software easy to use.  Unfortunately their frame of reference is themselves, so they only make it easy for other software engineers, not for normal human beings."

Alan Cooper, being a former software developer himself, discusses why he believes software developers ill equipped to design usable software:

Clearly, one side of software - the inside - must be written with technical expertise and sensitivity to the needs of computers.  But equally clear, the other side of the software - the outside - must be written with social expertise and sensitivity to the needs of people.  It is my contention that programmers can do the former, but it takes interaction designers to do the latter.

The intuitive thinking here is that since developers know the software at it's most granular, then would be best equipped to ferret out usability concerns.  While intuitive, Cooper shows the fallacy of the argument throughout the book.  The skills that make for excellent programmers are not complementary to those needed to uncover and address usability issues.

Software developers (who he refers to as Homo Logicus) are different from normal humans.  Cooper defines the specific characteristics that make for great software developers work against them when trying to address usability issues.  For example, developers:

• trade simplicity for control
• exchange success for understanding
• focus on what is possible to the exclusion of what is probable
• act like jocks

On the third point he says that obsession with edge cases makes great programmers, but poor usability.  Normal people care most about likely uses/situations, "whereas programming is defined by cases at the edge of the paradigm, design is defined at the center."

I've found that it can often be easy to be lulled into the belief that working with a product on a daily basis means that you instantly know how new people will use it.  While it's tempting to believe that's true, it's also completely wrong.

Jared Spool says that the best companies (Apple, Disney, Netflix among others) are great companies because of their focus on feedback among other things.  He says he tests companies by asking random employees if, in the last 6 weeks, they have spent at least 2 hours watching someone using your design, or a competitor's design.  He asks this of everyone who influences the design.  Not just programmers or usability experts, but the entire team.

Great companies realize how easy it is to lose focus on what your users go through, and these sessions provide the opportunity for everyone on the product to see how people interact with it.  It's crucial to have people from all over the company participate, because those people will notice something that the UX team or the developers may miss from being buried in the details.

While the details can make something ordinary into something transcendent, they can also narrow your focus so much as to lose site of the broader picture.  It's crucial to have developers who obsess over those details...great developers have the genetic code that replays the details of a problem over and over again until the solution works itself out...but that same characteristic can also lead you lose sight of what's important: how typical customers interact with your product.

And no amount of brilliant design can bring back a customer who has tried and been turned off by your product.