Client requirements: Why clients change their minds, and what you can do about it

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements. This episode looks at why clients often appear to change their minds dramatically, and how you can handle that problem within your development process.

Readers who like the extended metaphor of the client requiring an image of an elephant might like to know that we’re continuing with it in this article. Readers for whom the novelty of that metaphor has worn thin might like to know that we won’t be using it much.

So, why do clients appear to change their minds radically? It’s often because of a very simple reason that is easy to handle.

Continue reading

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.

Continue reading

Design Rationale, part 1: A tale of reasons, raccoons and cat flaps

By Gordon Rugg

Often, a small example can give key insights into bigger, deeper questions. The saga of our cat flap is one of those cases. It’s an apparently trivial problem that leads swiftly into important, difficult questions like how to tackle design decisions, and how to identify design options that you might easily have overlooked, and how to spot design problems in the first place.

That’s how we ended up as one of the few the families in England to have a raccoon flap in their back door, rather than a cat flap. It’s an excellent example of design rationale – the reasoning behind a particular design decision. Like most problems involving design solutions to client requirements, it takes us into the difficult territory where human beings have trouble establishing just what they want and why they want it, and where designers are trying to find a way of tackling the problem that’s systematic but that can also capture the often messy requirements and constraints affecting a particular problem.

I’ll tell the cat flap story first, and then work through the insights that it gives about design rationale.

Continue reading

Knowing the unknowable, revisited: Why clients can’t know their requirements, and some ways to fix the problem

By Gordon Rugg

Why don’t clients and customers make their mind up about what they want?

There are several reasons, all of which make sense in hindsight, but that aren’t immediately obvious.

This article is a short introduction to one of those reasons, that can be handled swiftly, cheaply and easily. I’ll return to this topic in more depth in later articles.

Continue reading

An introduction to graph theory

By Gordon Rugg

Graph theory is an extremely powerful approach that is based on a handful of elegantly simple concepts. It was invented by Euler in the 1740s, and is a central part of modern mathematics and technology. Among other things, it plays a key role in handling traffic on the Internet.

It’s invaluable for representing knowledge, because it combines flexibility with formalism. In particular, it’s useful for representing different facets and viewpoints; for representing hierarchies of goals and values; for representing successive layers of explanations; and for formal taxonomies. Continue reading