Wednesday, February 29, 2012

Taming Complexity and Tesler's Law

I always have a good think when I read Don Norman. Just started reading his Living with Complexity and it's holding true to form. It's worth reading the whole book just to be reminded of Tesler's Law.
Complexity can be tamed, but it requires considerable effort to do it well. Decreasing the number of buttons and displays is not the solution. The solution is to understand the total system, to design it in a way that allows all the pieces fit nicely together, so that initial learning as well as usage are both optimal. Years ago, Larry Tesler, then a vice president of Apple, argued that the total complexity of a system is a constant: as you make the person's interaction simpler, the hidden complexity behind the scenes increases. Make one part of the system simpler, said Tesler, and the rest of the system gets more complex. This principle is known today as Tesler's law of the conservation of complexity. Tesler described it as a tradeoff: making things easier for the user means making it more difficult for the designer or engineer. “Every application has an inherent amount of irreducible complexity. The only question is who wil have to deal with it, the user or the developer.” (Tesler and Saffer, 2007) With technology, simplifications at the level of usage invariably result in added complexity of the underlying mechanism.
If you are a Don Norman newbie, start with The Design of Everyday Things, that's a classic. I liked the first edition's title better, Psychology of Everyday Things. He called it POET for short.

I also just read an article Don wrote for core77: Act First, Do the Research Later, where he demonstrates that pragmatism matters, and there are many paths to good design.
Today we teach the importance of doing design research first, then going through a period of ideation, prototyping and iterative refinement. Lots of us like this method. I do. I teach it. But this makes no sense when practical reality dictates that we do otherwise. If there is never enough time to start with research, then why do we preach such an impractical method? We need to adjust our methods to reality, not to some highfalutin, elegant theory that only applies in the perfect world of academic dreams. We should develop alternative strategies for design.
Why it is not necessary to start with design research: Here are five very different arguments to support the practical reality of starting by designing, not through design research. First, the existence of good design that was not preceded by research. Second, the argument that experienced designers already have acquired the knowledge that would come from research. Third, the research effort of a company ought to be continually ongoing, so that results are available instantly. Fourth, and most controversial, research might inhibit creativity. And fifth, when the product is launched and the team assembled, it is already too late. 
That's particularly fun given that I'm taking a course right now which is all about design research. I do enjoy holding two opposed ideas in my head at the same time. (No one should think F. Scott Fitzgerald was literally setting this as a true, singular test of a first-rate intellect; it's a necessary quality, but not sufficient on its own.)

Hey! I just found the whole quote, and there's two more sentences to it that I've not seen before.
Before I go on with this short history, let me make a general observation – the test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function. One should, for example, be able to see that things are hopeless and yet be determined to make them otherwise. This philosophy fitted on to my early adult life, when I saw the improbable, the implausible, often the "impossible," come true.
Seeing that things are hopeless and yet being determined to make them otherwise. Yup. That's worth doing.

If you want to investigate more about reconciling opposing ideas, I suggest The Opposable Mind.

Sunday, February 26, 2012

Jamming for Joy with Jaco

Watching this is bringing me joy.

Jaco Pastorius is one of my favorite musicians; but I never saw him play live before his untimely death in '87. In fact, I've never even seen video of him playing. Until tonight.

I'm watching him play Montreaux '82 with Randy Brecker. Streaming on Netflix, natch.

You might know Jaco as the bass player on several of Joni Mitchell's albums, like Hejira (the one with Coyote on it).

He also played on several of Pat Metheny's best albums like his debut, Bright Size Life, which some say is one of the 100 Greatest Jazz albums of all time.

Jaco was a member of Weather Report with Wayne Shorter and Joe Zawinul - listen to Birdland on Heavy Weather.

Finally check out his masterpiece, Word of Mouth, with an all-star big band of fusion jazz greats, from Herbie Hancock to Toots Thielman and Jack DeJohnette. I rank it with Sergeant Pepper and Uh-huh as one of my personal favorite albums.

Sunday, February 19, 2012

Business metrics as solution requirements

In my day job, my team has started using a few old-school tools in our infrastructure architecture practice. One of these is Quality Function Deployment (aka QFD, aka House of Quality) which has its roots in Six Sigma manufacturing quality practices.
QFD House of Quality graphic from
While looking for a bit of information, I stumbled across an article titled “Retiring the House of Quality.” Since we're just beginning to use QFD, I wanted to see what the problem was. Turns out the article wasn't critiquing QFD itself, but the (mis)use of QFD in “innovation processes.”

The article ties into many of the themes we’re investigating in my current graduate school class on Evidence-Based Design (aka Human-Centered Design or User-Centered Design).

I liked the distinction made between concept innovation and technical innovation; I found that quite useful.
Distinguishing initial concept innovation from downstream technical innovation - from Retiring the House of Quality
But more importantly, I really appreciated the reframing around requirements where there were existing business processes with defined success metrics.

Consider the traditional approach of assuming that the technical solution team can identify certain technical requirements for the solution, and assuming that what is built meets those solution requirements are met, then the solution will address the business problem.

Instead of that approach, the authors suggest having the existing business process success metrics directly become the solution requirements.

The outcome-driven innovation methodology uses customer-defined metrics (desired outcome statements) to guide the formulation, evaluation, and selection of new product and service concepts. The resulting concepts are tied directly to the customer’s desired outcomes—and the job the customer is trying to get done—increasing the likelihood that the customer will value the new concepts’ features. Because the inputs used to guide concept innovation are tied directly to the customer’s actual inputs, no translation is required.

Taking the business process requirements as the solution requirements rather than having to invent intermediate solution requirements is a great insight.

Literally, this is disintermediation, but instead of disintermediating two parties by removing a middleman, it disintermediates a set of, well, intermediate requirements.

And because its exactly in that translation process of generating the intermediate requirements where technical solutions go wrong so often, it looks very promising for improving overall business satisfaction with solutions.

If you teach people, they have this miraculous capability...

I greatly enjoyed reading Architecture for Humanity's book Design Like You Give A Damn. It is full of wonderful, creative responses to hairy problems, often with incredible design constraints and stakes of life and death. 

One of my favorite lines was this quote from Maurice Cox:
I have come to believe that if you teach people what their options are, they have this miraculous capability to make the decision that is in their best interest. It was amazing to watch this unfold. 
I liked DLYGAD so much, I added it to my list of (physical) architecture books for IT architects

A second volume of DLYGAD is coming out soon. I can't wait to read it.