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 PizzaNo, 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 SimonYeah, 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.
I have a favorite activity: identifying an analogy, then pushing it beyond useful into the silly. “And it has four stomachs!” No, it doesn’t have four stomachs. But pushing an analogy within a design exercise can bring us to new understandings of our system, user behavior, and more. Ideas that would not have arisen now become clear, even with the now-broken metaphor. And it’s fun!
The problems are twofold:
1. Pushing an analogy too far causes system limitations, unmet user expectations, and more.
2. Many metaphors become unquestioned. The dashboard, in particular, can be baffling. Of course iGoogle is a dashboard! And of course our home page is a dashboard! And of course the idea of an “executive dashboard” is a great plan! Dashboards are great!
I think that dashboards, as implemented, abstract the information at some possibly useful level. (Note that cockpits don’t particularly). But I really like the context-changing nature of all “modern” cockpits. How should an executive dashboard change context? (I heard about executive dashboards all through my MBA program, and still have no idea. Current status of HR? Or cashflow? How well we are doing on strategy? Only this last one makes sense for the CEO of a company larger than around 500 people, and the information quality in any automatic system has an excellent chance of being abysmal. And lagging actual problems, by a lot.)
Many dashboards, as currently implemented, get in the way. The information isn’t the information I need, and as a result it merely generates an extra step. Picking on 37 Signals Basecamp for a moment, “Latest activity” has always been confusing, makes my organized project look terribly disheveled, and systematically destroys all context for the information. The only time I use the dashboard is when somebody loads a file and for some reason I’m not following the link in the email.
Interesting.
Some thoughts (bear w/ me). Cockpits may or not use context. You would think the new digital ones will summary a lot (or abstract a lot), and perhaps this is true in some form, but when it comes to flying, they (the pilot/user) want the basic switches and controls available as is, except now the cockpits are moving into digital form. In the case of the space shuttle (which is the 2nd image above w/ the multi-function displays and is not a B-52) the controls became digital — the same ones that were analog with the additional benefit they can see whose on any physical display. But the essence of the controls remained. So back to the analogy, even dashboards have preconceptions depending on the user of it, the one for the CEO vs. the industry or campaign analyst, all have come kind of expectations on the “controls” they want to see and use, similar to how aircrafts(or spacecrafts) pilots expect certain controls regardless of it being analog or digital. The customer know what they are talking about and want and expect and may not care about automatic or context but about the simple, expected “switches, controls and widgets”. Cheers.
ceo
1) Drat. NASA/Dryden labeled the all glass photo as a B52 cockpit, on their B52 testbed summary page. They have done an upgrade, but apparently this is not it.
2) Indeed. I got to talking about my process a bit more than the decision making part of things, which I do cover elsewhere (another plug for my book!). I think another problem with dashboards is that you have to assume what a user wants. For a real one, you are probably driving, or landing, or parking or some other narrow set of tasks. For data analysis… who knows? I mean, sometimes you’ll have a closely defined set of users (love to do some work on Bloomberg terminals, et. al.) but often, there are several user types, approaching things from several points of view.
I suspect if I did some historical research and analysis, I’d find that this is where portals came from. A way to offer everything to everyone, that is not so evil as to be useless.