Client requirements: The shape of the elephant, part 3

By Gordon Rugg

This article is part of a series about identifying and clarifying client requirements. Handling client requirements isn’t always easy. However, that isn’t the same as “impossible” or “not worth trying”.  The previous article covered three ways of getting it wrong, and various ways of getting it right; this article follows on from that point.

As a running theme through this series, we’re imagining that you’re dealing with a client who has asked you to produce an image of an elephant. Here’s another inadvisable solution.

Bad solution 4: My design is in a witty dialogue with its environment  

Client’s response: Very funny, go get a job at the circus.

There’s a classic Calvin and Hobbes cartoon which shows Calvin being thrown unceremoniously out of the front door. He’s protesting angrily that if a novelty song is funny the first time, it’s funny the sixteenth time as well.

Humour comes from an unexpected juxtaposition of things that are very different. So does horror. A juxtaposition isn’t unexpected if you see it every day, which is what happens with buildings – there’s a whole genre of buildings that are intended to be visual jokes, rather than places that are good to use, or that bring visual pleasure to as many people as possible, and visual displeasure to as few as possible. Arguing that everyone’s tastes are different isn’t a strong position; yes, at one level, they are, but at another level, there’s enough broad agreement about taste to make some consumer products best sellers while others are very much a minority market, and others again rapidly vanish into well-deserved oblivion.

There are numerous methods for evaluating designs, both in terms of functional requirements, non-functional requirements (a misleading name that should never have been allowed to escape into the world) and subjective opinions with regard to the features relevant to the intended users and/or market. These are well established in some disciplines, and scarcely known in others.

In brief, functional requirements are ones where you can point to the place where that requirement is met (e.g. “This fire escape meets the requirement that the building must have a way for people to get out in the event of a fire”). Non-functional requirements are ones where you can’t do that, because the requirement isn’t met in one single place, but rather via two or more parts of the system (for instance, the requirement that an aircraft can be evacuated within a specified time).  Ironically, non-functional requirements are often much more important and practical than functional requirements, since a lot of non-functional requirements involve safety management, as in the example of aircraft evacuation.

Subjective opinions can be handled via techniques such as card sorts, laddering and think-aloud technique, which are all good ways of finding out which features are important to people. There are articles about all these techniques on this site and on the Hyde & Rugg website. Evaluation is a topic to which we’ll return repeatedly.

Bad solution 5: Sex sells.

Client’s response: Not to this client.

What’s the implicit subtext of this approach? It’s basically saying that the sex in the image is a better selling point than the quality of the product. That’s not exactly flattering to the client or to the intended market.

Also, at a deeper level, the world’s changing. There’s a fine line between sensuality and insidious sexism, and there are a lot of more people now calling out anyone who crosses that line. Those people include clients and the intended market. It’s better to treat them properly, and to design something that’s good on its own terms, not because it has a sultry elephant draped across it…

Bad solution 6: I found some clip art that’s a pretty close match.  

Client’s response: Would any jury convict me?

Yes, some people actually use this approach. Yes, there are probably some situations where it’s appropriate. No, I can’t think of any at the moment.

This approach is a recipe for trouble on two fronts. One is that it shows the client no skill beyond the ability to use a search engine. That doesn’t exactly strengthen a portfolio, or the likelihood of repeat trade with that client. The other is that images in a professional context are often being used to demonstrate important indicators of quality involving apparently minor features that actually send out a strong signal to the intended audience. There’s an entire genre of humour among professionals based on cases where designers haven’t done their homework, and have produced something that’s hilariously wrong to anyone who knows the field.

There’s an easy solution that involves three simple steps. First, ask the client about any key features that need to be included. Second, show a quick and dirty mockup to the client. The client will now notice all sorts of things that they didn’t mention first time round, because of Taken For Granted knowledge (described in previous articles). Third, produce a revised mockup and show that to the client for feedback. You might still need to tweak the design, but usually it’s only a minor tweak, and you’re now ready to move on to the full-scale proper design. This initial check doesn’t take long or cost much, but it can make things go a lot more smoothly downstream.

This approach works best in combination with user centred design and ego-free design. Learning these approaches can be a bit of a challenge if you’re used to the idea of designer as temperamental and egotistical, but if you do learn them, they have a lot going for them; they also make design and development much more productive, high quality and fun.

Links and notes

This series consists of Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8.

The elephant images above are from wikimedia and Wikipedia, and are used here under the creative commons licence.

Advertisement