Recent Blog Posts

Near the beginning of my book on design process are a few sections occupied largely with things not to do. One of them is on how mis-use and over-use of analogy is rampant and probably bad. It's short, so here it is in full:

Analogy – Interactive Design is Exactly Like Making a Pizza

No, its not. At all. Its also not at all like building a house. Or changing the tires on a car while its driving down the road at 60 mph. Or any other favorite analogy your leadership has used to describe the situation.

Sometimes, this analogy work goes quite a bit too far, and is a fairly bad thing. Processes, for example, are picked up from other fields and misapplied to interactive design. Inappropriate analogy or blindly inherited process encourages inappropriate process and methodology. Houses need blueprints, then foundations. Do websites?

It's time that interaction design (or even software development) comes into its own, and can be understood without arbitrary analogies.

Another key point in the misuse of analogy is the assumption that everyone else knows what they are doing.

...I live every day with the vague nightmare that at some point, someone more knowledgeable than myself is going to sit up and pen a massive screed indicating exactly where my work is shallow and fraudulent and rooted in lame, half-assed assumptions.
— David Simon

Yeah, pretty much everyone has those fears. Individually, organizationally and as whole fields. Architects, and builders and factories and pretty much any industry is chock full of seeking out improvements in their own process due to inefficiencies, inaccuracies and half-assed implementation. You can be an expert in your field and believe it is able to stand on its own. That said, there will be one or two small analogies in this text. Just don’t over use them.

But I missed another point, in that sometimes those other folks do indeed know what they are doing. If you can glean from them the kernel of truth, or the design principle behind their solution, you might learn something.

One of the things I have never really understood is the concept of the "Dashboard." It's something that was highly beloved by every Manager, Director, VP and so on at Sprint, so I heard it a lot. Had to design a few, but even then I never got the point.

Just the other day I am working this large, complex product design and the term comes up again. I had been ignoring it, or rather replacing "dashboard" with "portal" (which has a specific meaning to me, and is not a throwaway term). But something about the way it was said struck me, so I asked for clarification. And the answer was along the lines of "you know an airplane cockpit, with lots of dials and guages and meters and you can see the condition of everything about the plane at a glance."

Okay, I get that. But it also bugged the crap out of me. Because that's what 1960s airplanes look like.

A B52, designed in the 1950s, with all mechanical instruments for the flight controls, including eight engines.

And they look like that because that's the best they could do at the time. By the 70s even, there was a move to the MFD, or Multi-Function Display.

The same aircraft, with all the same systems, upgraded to modern displays.

With these (disregarding the backup instruments for safety) you fly the whole plane with a lot fewer switches, and by looking at anywhere from one to three large flat panel displays. How do they display all the information of the older cockpits? They don't. They use context to display summaries (and needed details) of the information currently relevant.

And while there's plenty of over-rides, it's mostly automatic context. As you approach the airport, these displays automatically tell you that, and switch from cruise to approach. And so on.

So when there was a break a few hours later, I told my client essentially exactly that. And I want to be clear that this all worked. I am not secretly ripping on a client for being dumb. When I went ahead and went off on my apparent tangent about cockpit design, it worked. It sparked some ideas about contextual display as they relate to our product which led (eventually) to a whole new IA, and solving the biggest issue before us.

Much like understanding the problem is key to starting to look for solutions, understanding the possible solutions is key to determining if they are valid solutions. If you have a similar issue, don't trust there will be a nerd for the subject area at hand, but do challenge yourself and go look it up. You might be surprised at how conventional wisdom is behind the times.