Thu Jul 16 23:31:11 BST 2009
Fred Brooks, in his seminal set of essays grouped together as The Mythical Man Month, asserted that conceptual integrity is the most important consideration in system design. This idea makes sense when you think about it: so long as a design has a coherent concept running throughout it is possible for implementers of that design to correctly predict how the system should behave as they implement the nitty gritty details, inasmuch as they can judge what would make the most sense in the context of the system as a whole.
This is a particularly important and challenging idea for a designer: get the concept right and the whole will fall naturally into place. Get it wrong and you'll forever be shoe-horning unfortunate edge cases into an increasingly disparate grab-bag of ill-formed ideas.
However, whilst conceptual integrity is a powerful design tool, it's also a handicap when it comes to understanding how your users will see the output of your efforts.
For example, consider the common phenomenon of desire lines. Desire lines are unofficial paths that people create in landscapes when getting from one place to another, and what they represent, to an extent, is the offset between how the architect understands the landscape and how the people who have to live and move within that landscape understand it. Clearly, however the architect thought of the space, the users of that space see it in a different way: the paths the architect designed aren't in the right place, so people go ahead and make their own.
Similarly, I experienced this kind of concept clash recently when discussing mobile phones with a friend. She was talking about the iPhone 3GS her boss had just upgraded to, and was enthusing about how simple the upgrade was. "She didn't have to change phones, she just went to the store and they upgraded it for her there and then!". This didn't make sense to me initially because I was thinking about the hardware required to support 3G, and wondering whether it was possible to enable with a mere software upgrade. I couldn't really believe what she was saying until I realised that when she described the two phones being the same, what she was referring to was the physical interface of the phone -- the 3GS was just the same in terms of look and feel as the old iPhone. My literal interpretation of the phone being "the same" as in the same piece of hardware was borne of my inbuilt set of concepts as an engineer, thinking of the phone as a hardware platform with set capabilities running more-or-less malleable software. We both had our own completely coherent concept of the iPhone, but nonetheless we could have completely conflicting ideas -- our definitions of the phrase "the same" were in fact completely different.
This kind of concept clash is illuminating for both designers and users as it helps to illustrate the kinds of problems that occur when designers try to talk to users -- if you're indoctrinated in your design-centric conceptual integrity to the extent you need to be to do implementation work, then you're almost certainly going to find understanding the user's view difficult. Similarly, if you view an object entirely in terms of your use of it, it's going to be tricky to second-guess what kinds of trickery have gone into its development, and how that might impact a person's perception.
Perhaps one of the most important things for a designer to absorb is that their concepts, as elegant as they may be, are no better than those of the user. It's very easy to treat users with contempt when they ask for things you deem to be stupid, but at the end of the day the users are the people with the clearest insight into a design at the point that the rubber meets the road. It's an immensely valuable experience, more especially so as it is one that the designer simply cannot have by dint of the complex mental model of the system that she carries in her head.
As a final reference, I was interested recently to read a post on Jeff Atwood's Coding Horror blog which discusses the pitfalls of an engineering view of a successful website as a bunch of html with an sql backend. That view is correct, from the viewpoint of an implementer, but it completely ignores the reality of the site from the view of the user who sees not html and sql but a resource that they can use to learn and to get work done. The implementer's view is something that can be "thrown together in a weekend", but the user's view is something that takes considerably more spit and polish, and considerably more time.
It's a distinction, and a perceptual gap, that designers ignore at their peril.