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.
The saga begins with our two cats, Pom and Tiddles (names changed to protect the frequently guilty). They like to spend some time in the garden, and some time in the house, so we installed a cat flap to make life easier for everyone involved.
Design 1: The ordinary cat flap
For years, we had a simple, cheap, low-tech cat flap that worked perfectly well. Then trouble arrived, in the form of a tomcat nicknamed Burglar Cat that started coming in through the cat flap and causing trouble.
Design 2: The magnetic cat flap
The novelty of cleaning up after a visiting tomcat soon wears off, so we bought a more expensive new cat flap with a magnet sensor and a couple of magnetic collars for Tiddles and Pom. The magnetic cat flap had a deep entry tunnel. This caused problems. The hold for the cat flap was quite high off the ground. With the old cat flap, that hadn’t been an issue, because Tiddles and Pom could stand on their hind legs, got a hold on the cat flap, and climb up and in. With the magnetic cat flap, that didn’t work, because the entry tunnel was deep and slippery, without anything to hold on to. So we installed a cat step on the back door as an allegedly temporary fix.
The new magnetic cat flap worked for a while, until the tomcat found a way of getting through it, even though he didn’t have a magnetic collar. We suspected it was because the cat flap didn’t always close completely after Pom came through. We bought yet another cat flap.
Design 3: The microchip cat flap
This cat flap was more expensive and higher tech than the magnetic one. Fortunately, it had almost identical dimensions to the magnetic one, so we were able to install it without problems. Everything went well for a while, until Burglar Cat started breaking in again. We couldn’t work out how he was managing it. Eventually, we caught him in the act. The cat flap was extremely efficient at stopping cats from pushing forward into the house. It wasn’t quite so efficient at stopping cats from pulling the flap outward. Burglar Cat had found a way of hooking his claws under the flap and pulling it open. It took a lot of effort on his part, and he did a lot of angry growling in the process, but he managed to open it eventually.
We phoned the manufacturers, who were brilliant. They listened carefully, asked insightful questions, and said they would send us an even higher tech solution. It arrived a few days later. Here’s what it was.
Why a raccoon flap? With hindsight, it makes perfect sense. Manufacturers think about markets, and the North American market is big. The North American market has some requirements that the European market doesn’t have, such as being able to keep out raccoons, which have nimble fingers and are extremely good at breaking in to places where they’re unwelcome. Anything able to keep a raccoon out should also be able to keep a cat out. So, it makes sense that the manufacturers of high-spec pet flaps would produce a raccoon flap, and it makes sense that they would send us one to solve our Burglar Cat problem.
At time of writing, the raccoon flap is working perfectly, and everyone involved is happy, except for Burglar Cat. (Reassurance for any readers who are wondering if he’s a sad, hungry stray: Burglar Cat is a very well fed, well-groomed brute, who is clearly much loved by someone, and who probably gets a huge number of extra meals via his burglaries of homes with lower-tech cat flaps.)
So, that’s the story of why we’re probably the only family in Shropshire with a raccoon flap in the back door. What does it tell us about design rationale?
Design rationale: The key concepts
One important point to flag from the start is that there was nothing actually wrong about the first cat flap. It did its job perfectly well for years, until the situation changed.
That takes us into several concepts at the interface between consumer choice and design decisions.
Optimising and satisficing
This is a concept from the work of Herb Simon on decision making.
For some decisions, you’re looking for the best possible solution. That gets you into a complicated problem where you have to identify all the relevant potential solutions, and then identify all the relevant factors, and then decide how to attribute scores to all of the relevant potential solutions so you can work out which one is best. Simon called this process optimising. It’s usually difficult, and usually requires a lot of time and effort, and usually you can’t guarantee that the solution you find is truly optimal.
For other decisions, you’re looking for a solution that’s good enough, but that doesn’t have to be the best possible. Simon called this process satisficing (with a c – that isn’t a typo). With these decisions, you decide in advance what will be good enough, and then you choose the first option you meet that meets those criteria. There may be better solutions available, but for your purposes, that doesn’t matter. In cases of satisficing, you’re saving time and effort by choosing the first good-enough solution, and you’re making a conscious decision that those savings will more than outweigh the potential losses if there’s a better solution that you’ve missed.
For our first cat flap, we made a satisficing decision, and it worked well for years, until the situation changed. For satisficing decisions, you can use a range of methods from decision theory and from requirements engineering to identify the essential needs.
If you’re optimising rather than satisficing, then you need to think about how to compare the possible choices. That takes you into concepts like measurement theory, which I’ll probably cover in a later article, and Multi-Criterion Decision-Making, which is described below.
This is a popular, simple and usually effective way of choosing the best solution out of several candidates. It’s useful not only to customers, but also to designers faced with several possible solutions.
The usual way of doing it is to open a spreadsheet, and to give each candidate a column, and to give each relevant attribute a row. You then give a score for each candidate on each attribute, and total the scores for each candidate, then choose whichever gets the highest score. Here’s a mocked-up example. It shows pretty clearly that the first cat flap was the best choice when security wasn’t an issue, but when we were up against extreme cat proofing problems, then the fourth cat flap (i.e. the raccoon flap) was the best choice. (It’s usually a good idea to use neutral names for the items being compared, rather than manufacturers’ brand names that are designed to predispose you towards a good opinion of the product.)
I won’t go into much detail about this approach, since it’s widely known, but I’ll mention a few classic points of detail that can make the difference between using it well and using it badly. The diagram below shows the points in question.
The numbers in the cells should normally be on a scale from one to seven, plus or minus two. If you use ten point scales, then people’s ratings are less consistent than if you use a scale of about seven points. This is due to a classic limitation of human working memory, first described in Miller’s 1956 paper on the magical number seven, plus or minus two.
The names of the attributes should all be phrased in such a way that the meaning of a high score is consistent. For instance, the first attribute is currently affordability, so a high score is good. If that same attribute had been called cost, then there would be confusion about whether a high score meant high cost (because of the high number), or low cost (because a high score is good).
The numbers in the cells should all run in the same direction – usually low being bad, and high being good. Also, watch out for the risk of including numbers that aren’t ratings, such as the dollar price of an item; this would completely mess up the calculation of the total.
The totals in this example are from unweighted values. In this example, we’re simply adding the numbers together. Often, though, one attribute will be more important than the others, so you might want to give it a weighting – for instance, by doubling its raw score, so that a raw score of 5 is doubled to a score of 10 in the cell. This is perfectly legitimate if done honestly, but cynical users have been known to decide in advance which of the candidate solutions they want, and then to add weighting factors to the attributes until the spreadsheet produces the answer that they want.
That covers some of the background concepts; we’ll now start on the core concept of this article, namely design rationale itself.
Design rationale is about the reasons for a design choice. This leads into a lot of topics that look messy, but that can often be made cleaner by using the right methods. As usual, there are methods available that are widely known in some fields but almost unknown in others, so I’ve pulled together a range of useful concepts from different fields for this article. I’ll discuss some of them in more depth in future articles.
We can illustrate the concept via some design annotation. This is a simple but effective way of showing the rationale behind each design feature. Here’s an example; it’s our raccoon flap.
Design rationale is well established in many fields of design, but there’s variation in how formally it’s applied.
With the design annotation approach, it’s easy to identify most of the design points and to explain the reasoning behind the solution chosen, which can be very helpful when communicating with clients. It’s also possible, particularly if you’re using ego-free design, to use this to identify places where you don’t have a stated rationale for a decision. For instance, in the cat flap diagram, is there a rationale for the breadth, width and thickness of the cat shelf?
In most fields there are standard constraints that every professional knows and (in theory at least) remembers to include in design decisions. Building regulations and human factors guidelines are two examples of this.
However, when you’re dealing with a large number of possible constraints (as in building regulations) then it’s very easy to forget one. This is also a potential problem if you’re dealing with multifaceted constraints. For instance, in mechanical engineering for medical implants, you have to consider the mechanical strength of the possible materials, and the toxicity of those materials, and the risk of chemical interactions between those materials.
This is where there’s potential for using approaches from other fields to provide new ways of handling the assorted problems that you need to tackle in large-scale design rationale. The sections below give some tasters on ways of doing this.
One approach that helps make sense of large quantities of design constraints is facet theory. You can organise those constraints in terms of e.g. the mechanical properties facet and the toxicity facet and the chemical interaction facet. That doesn’t solve all the problems, but at least it tidies them up neatly.
Moving further into the detail, with design rationale, you’re getting triplets of statements, of the underlying form [I did X] [in order to] [do Y].
That’s easily modeled within graph theory, and fits very neatly with laddering.
When you use this laddering in this context, you often get very interesting insights once you ladder up two steps. A typical pattern is that the first step looks sensible and obvious, but when you reach the second step, you discover that the client hasn’t thought about other paths that reach the same goal; instead, they’ve become fixated on that first step, and lost sight of the bigger picture. A good example of this is the Search Visualizer software. Clients wanted to read the documents as a step towards the higher level goal of assessing the relevance of the documents. However, they hadn’t realised that there was a much faster and easier way of assessing the relevance of the documents, by seeing the distributions of the keywords within each document.
The illustration below shows this diagramatically. The client’s usual route has a lot of disadvantages – it’s slow, and it’s difficult for users with dyslexia, and trying to use it on languages that you don’t speak will involve a huge amount of hassle even with automatic translation software. The Search Visualizer route has a lot of advantages in comparison.
What often happens in such cases is that the client is extremely pleased with the new approach, and immediately abandons the previous approach. This is where your development methodology makes a huge difference. With the traditional waterfall model of requirements handling, having the client drastically change their requirements in this way would cause chaos, even though it resulted in a much better solution. However, if you’re using an iterative approach, particularly one that starts with cheap, fast non-functional mockups, then this sort of change would probably occur within the first iteration, where you could easily and cheaply incorporate it into the next cycle of design, and acquire a happy client in the process.
In practical terms, you can catch a lot of these issues simply by asking “Why would you like that?” a couple of times to get the higher-level goal, and then asking “Can you tell me some other ways of achieving that goal?” once you’ve found what the higher level goal is. (Asking about “some other ways” is more likely to produce some ideas than asking about “any other ways” – sometimes apparently minor changes in the phrasing make a difference.)
This approach won’t always work – in the case of Search Visualizer, we worked out the other route ourselves – but it will catch a lot of cases. When the client doesn’t know an alternative route, then you can try other approaches yourself, such as constraint relaxation.
Constraint relaxation and creativity
Creativity is often treated as some sort of mystic impenetrable mystery, but it isn’t. In practice, it can be handled via two main routes, that correspond with the two computational processing routes of sequential processing and parallel processing.
That won’t mean much to most people, but you can get to the end point without needing to know the details of how the solutions work.
One simple solution via sequential processing is to list all the constraints affecting a problem, one after the other. Here’s a hypothetical list.
Cat flap size constraints
- Must be big enough to let any cat in
- Must be small enough to keep out dogs
What you now do is go through the list, one item at a time, asking yourself what would happen if you threw away that constraint.
Suppose, for instance, you throw away the constraint that the cat flap must be big enough to let any cat in. What happens then? Well, one thing you realise is that tomcats are usually bigger than female cats, so for some customers, like us, who have female cats and want to keep out a large tomcat, this might be a good solution. You could market a “small to medium sized” low tech cat flap where the size alone kept out the problem cat; this would let you solve the problem much more cheaply than by using electronics.
Deep structure pattern matching
Constraint relaxation works neatly and methodically, step by step. Deep structure pattern matching is very different. What you do in this approach is to let the human being do what human beings are very good at, namely seeing underlying patterns and similarities.
A simple and effective way of using this method is to tackle a problem by getting the team to look at lots of images of arbitrarily chosen objects and scenes – for instance, browsing a site like Pinterest.
What happens is that the designer’s subconscious eventually spots an underlying similarity between the image they’re viewing and the problem that they’re tackling. These similarities usually make sense in hindsight, but are very hard to predict in advance. With the Search Visualizer software, Ed de Quincey and I were discussing Roman magical word squares, such as the SATOR AREPO word square, when we realised the deep structure similarity between that and patterns of keywords in online search, that led us into inventing the Search Visualizer. That’s something of an extreme example, but it illustrates the underlying point.
That’s a brief introduction to the concept of design rationale. We’ll be returning to the theme of design repeatedly in later articles.
There are links below to a range of articles and sites that you may find useful.
Notes and links
Satisficing and optimising: http://en.wikipedia.org/wiki/Satisficing
Decision making approaches: http://en.wikipedia.org/wiki/Decision_making
Raccoons versus the raccoon flap: http://www.youtube.com/watch?v=CjeoSqdKLto
The SATOR square: http://en.wikipedia.org/wiki/Sator_Square
The Search Visualizer (free online version): http://www.searchvisualizer.com/
The Search Visualizer blog: http://searchvisualizer.wordpress.com/