Design by Metaphor

Design by metaphor—or, as is often the case, design by simile—happens when a client provides design and development in the form of a reference to another product. This can occur both in high-level concepts, such as, “MySpace, but for B2B relationships,” and in individual details, like “the login should be just like Gmail’s.”

Spoken language provides an interesting analogue to design by metaphor: If you’re not a fluent speaker of a particular language, you’re often forced to stretch your limited vocabulary into bizarre, descriptive phrases instead of the exact words that say what you mean. Maybe you remember the last time you were overseas and asked directions to the “shop of changing banknotes.” In the same way, you’ll mostly see similes in specifications provided by clients who may not know how to say that they want “database of user registrations with reports X, Y, and Z” or “JavaScript menus that degrade into CSS-formatted lists.”

Metaphors and similes are also excellent ways to summarize multiple, loosely-related concepts in shorthand. After all, the basic behaviors of any web-based discussion forum, contact form, or shopping cart are largely the same as those of any other once you factor out the specific content of the site.

Why put up with comparison-driven design?
When used to pin down abstract concepts or unusual design details, design by metaphor or simile bridges a major gap of understanding. The customer may not be able to pin down what he wants from another site, but in some cases, pointing to that site can be enough to make the features he desires apparent to experienced developers.

Conversely, comparative references can be extremely powerful for explaining design decisions back to a client. Few client-provided specifications are all-inclusive, and you can expect questions when your judgment calls don’t match what he imagined. If you explain that you designed your booking process “like Expedia,” you can easily summarize a wide range of choices through the system, as well as gain added authority by showing that your choices mirror those of a successful system.

When comparisons attack
Unfortunately, the power of this method of communication comes at a significant cost. If a client says he wants his new auction site to be “like eBay,” what does that mean? An artist hears “It has a tacky color scheme.” A developer hears “It’s scalable to 20 million users.” A user hears “It has feedback ratings on all sellers.” Which, if any of these, did the client mean? You may spend dozens of hours writing specs for eBay-esque features that didn’t capture the client’s heart.

Conversely, defining your own work in terms of other products may set up unacceptable comparisons or fixations in your customer’s mind. If you boast that a new shopping cart works 95% like Amazon, the client may grow obsessed with “fixing” the 5% that’s different, or incorrectly believe that his site has acquired the capacity and features of Amazon across the board.

Moreover, the ability to identify a loose aggregation of features via a single comparison may cause clients to accidentally include irrelevant or needlessly expensive features in their specifications. For example, many off-the-shelf shopping systems include extensive support for multiple currencies and tax jurisdictions. This adds many layers of complexity, and if you’re running a single outlet in Chandler, Arizona, you probably don’t actually want to spend $5,000 more on development to ensure your “just like Zen Cart” shop is ready to handle British Value Added Tax.

Finally, a client who can only speak in similes may be unable to bring the best possible choices to the table. If the client is selling merchandise, he’ll probably say he wants a self-contained shopping system styled after his favorite e-commerce site—but his comparison is limited by his experience. Odds are, he hasn’t seen an example of a hosted shopping cart service, or a single-action “Buy Now” button that he can allude to, even if those would suit his needs better. Your experience and expertise comes in there, as you’ll be able to offer your clients choices they didn’t realize they had and rescue them from the tyranny of comparison.

Bounce back to the real world
The ambiguity inherent in comparison-based design communication must be managed, or you’ll end up trying to build mutant websites which work as YouTube plus Newegg multiplied by DeviantArt…on a $750 budget. Fortunately, there’s a practical strategy for controlling runaway scope: limit the use of metaphors and similes to the phases in which they work best.

It makes sense to start with comparisons, especially if you’re about to develop a significant new functional unit. However, if you do so, the second round of specification development becomes critical. Once you understand what the client is asking for on a high level, you should restate that understanding in more concrete terms that will form the basis for binding design documents. You can even walk through the comparison product part by part and ask the client what he really means with his comparisons. There is absolutely no harm in asking “what part of this process do you want to copy?” Developers often over-complicate vague requests, and it may turn out to be a pleasant surprise when it turns out that all the client really wants to lift from the $300,000 commercial backend is its color scheme and menu placement.

You may also be able to control ambiguous comparisons by treating them not just as a design reference, but also as a source of benchmarks. Compare compatibility and performance of the model site: when you bring a focus group in, let them attempt to complete tasks on your site and then on the sites the client presented as models. Direct comparison of user experiences and task success rates are solid evidence that your site matches, or even exceeds, the models. Such a strategy is particularly effective when the client has questionable assumptions about user behavior.

When it’s clear that the client is relying on a poor or inadequate analogy because he lacks a better choice, you can combine his understanding of comparisons with your wide design vocabulary. Speak his language, and propose that “instead of doing it like your example, what if we try doing it like this other example?”

Finally, don’t miss the possibility of the sum of a client’s models being significant as well. If all the sites he idolizes average 700k per page of images and Flash, the unspoken message could well be “a seamless, graphics-intensive look is more important to me than 28.8 modem users.” Reading between the lines is no less important here than it is with a more conventional specification.

One more communication tool: no more, no less
Design by comparison can help to engage your clients in the development process while keeping the discussion at a level they’re comfortable with. However, its practitioners must realize that poorly analyzed metaphors can say too much or too little. The need for this delicate balance keeps the technique from being a panacea, but doesn’t prevent it from being useful.