Chapter 2

Doing Design

The previous chapter introduced the idea of design thinking and its influence upon software development. In this chapter we look at what it means to apply this to produce a design ‘solution’. In particular we examine the influence on this of the ill-structured (or wicked) nature of design problems and consider how this might affect the ways that we set about ‘doing design’.

2.1Designing as a creative process

A distinctive characteristic of humans is the ability to use tools to create new artifacts, where these are new in the sense that we end up with something that did not exist before. The meaning of ‘artifact’ is “something made by humans”, so distinguishing an artifact from the things found in the natural world. Indeed, the range of artifacts seems almost endless: clothing, books, furniture, buildings, bridges, ships, machinery, computers…

And those are simply the physical forms of artifact. There are also many examples of procedures that humans devise in order to add structure to our lives, whether it involves the process for getting married, organising the way that passengers should board a plane, or negotiating an overdraft with our bank. The tools used to create these are likely to include a variety of conceptual forms (such as workflows and legal frameworks)—but the procedures that result are still artifacts, helping to organise our lives and businesses in an ever more complex world.

The material in the chapters that follow this one is concerned with largely conceptual tools such as design methods, software architecture and software patterns. Software tools for producing more ‘physical’ aspects of design methods such as diagrams and specifications do exist, but since their purpose is mainly one of recording design decisions rather than helping to create new models, they do not really fit into the scope of this book.

Creativity requires more than the availability of conceptual tools of course. What creativity involves is the ability to “think outside the box” and to find new and effective ways to meet a particular need. While this may occasionally involve coming up with a radically different way of doing something, quite often the creative element will be realising that doing things a bit differently might produce something that is more effective, robust, elegant, or some combination of such attributes.

Our perception of how design is involved in producing new ideas will vary, and probably not always be correct. No-one is likely to deny the importance of using rigorous and well-proven engineering design practices when creating motorway bridges, aircraft and buildings, not least because of the safety issues associated with their role and use. Yet good design is important for everyday things too (Norman 2002), even if the effects of poor design lead to nothing more than the odd stubbed toe, or the irritation of having to restart a transaction on our phone or tablet because some information has been ‘lost’.

A second, and associated, human characteristic is that of communication—although in a design context its importance may arise more from the variety of ways in which it is employed.

Communication usually plays a vital supporting role to creativity, since developing any new form of artifact almost always requires us to formulate in some way the concept of what this artifact is to be and then to tell others about our ideas. Communication has always been necessary to gain approval and assistance from others, whether it be for the purpose of persuading them to join in with building a megalithic barrow; obtaining a commission to paint a mural for a medieval pope; creating a new social welfare system; constructing a steam locomotive; or creating an on-line banking system. And the act of communication can take many forms, spoken or written words, scale models, mathematical formulae, sketches, simple prototypes etc. And obviously it is closely related to the issue of how we represent our ideas.

Communication also plays another, rather different, role in creative activities. This is to act as the vehicle by which experience and expertise about how to do something (in our case, design software) can be conveyed from an ‘expert’ to a ‘novice’, as well as be shared among a community of experts. Indeed, the ability to reuse ideas is a major element in the development of design expertise, and it is the systematic codification and organisation of knowledge for the purpose of its reuse that forms an important characteristic of both craft and engineering disciplines, although these may differ in the degree of formality involved in the codification of their bodies of knowledge.

Both creativity and communication are core concepts that underpin the ideas presented in this book. Indeed, one of the roles for a book like this is that of communication, seeking to explain to others a range of ideas about design and its realisation in a software context.

2.2Ill-structured problems

As explained in Chapter 1, software development tasks are examples of ill-structured problems (ISPs). ISPs cannot be ‘solved’ by straightforward analytical means. Well-structured problems (WSPs) can often be solved by using a reductionist approach, gradually transforming the (possibly quite complex) model of the problem into a model of the solution. A good example of this is mathematic models of three-dimensional motion, where the use of an appropriate system of axes can separate out the components so that they can be solved independently. In contrast, ISPs require some form of design process, where this usually involves iteratively postulating a (increasingly complex) ‘solution’ model, and then evaluating how well this meets the requirements. We discuss this approach more fully later.

An example of the problems posed by an ISP is demonstrated by the way that feature interaction can occur when modifying software systems that need to support many options in their operation (such as the software for a phone). Feature interaction is something that arises when the act of adding a new feature that was probably never even envisaged in the original design model causes some of the existing features to stop working correctly. While it may be possible to use analytical techniques to identify where the interactions occur, a resolution of this may quite possibly require a major redesign of internal data structures and the software used to access these.

Using a slightly different terminology drawn from ‘design as planning’, design problems can be regarded as being examples of what is termed a wicked problem. This term was coined by Rittel & Webber (1984) and arose from their analysis of the nature of social planning problems. A wicked problem demonstrates some interesting properties, and it can be briefly summarised as being a problem for which its form is such that the act of finding a solution for one of its aspects will also have the effect of changing our understanding of the problem¹. (For the discussion of this section, we can largely interpret the term ‘solution’ as meaning a design plan.) For the purposes of this section we will continue to use Simon's terminology and refer to such problems as ISPs.

Rittel and Webber identified ten distinguishing features of ISPs/wicked problems. Most of these can be equally well interpreted as applying to software systems (Peters & Tripp 1976). Here we briefly review those characteristics of an ISP that relate most closely to software design, and interpret them for a software related context.

There is no definitive formulation of an ISP. The challenges involved in specifying what software systems should do are well known, and indeed, because both specification and design can involve modelling of some required functionality as we illustrate in Figure 2.1, they can be difficult to separate clearly. Rittel and Webber make the point that the activity of specifying and understanding a problem or need is also prone to be bound up with our ideas about how it might be solved. This of course is one reason why simple life-cycle models in which the activities of specification (by the customer) are performed in advance and form the basis for the task of design (by the developer) are usually unrealistic.
ISPs have no stopping rule. This emphasises the point that there are no criterion that we can use to establish when the solution to a problem has been found, such that any further work is unlikely to improve it significantly. When designing software it lacks any characteristic we can measure and use to demonstrate that a particular design model is ‘complete’. So, rather inconveniently, we have no reliable way of determining when we should stop working on a design task.
Solutions to ISPs are not true or false, but good or bad. In science, we can often identify whether a ‘solution’ is correct or not, perhaps mathematically, or experimentally. In contrast, there are very many ways of writing bits of software, or structuring them, which will all produce the intended (‘correct’) outcomes. They may differ in many ways (length, clarity, speed of execution) while performing the required task successfully. (Anyone who has marked student programming exercises will be familiar with the wide variation of style and structure commonly encountered—even for the programs that work!)
There is no immediate and no ultimate test of a solution to an ISP. What this effectively observes is that we can't really be sure that what we have produced meets all the identified needs by means of any simple form of test. As we will see, evaluation of a software design is very challenging, and even apparently simple comparisons between design solutions need to be made by using multiple criteria.
Every ISP is essentially unique. In later chapters we discuss ideas about how we can reuse design experience for part-designs through forms such as design patterns and software product lines. But even with these, the designer needs to adapt and interpret the idea in order to apply them to a specific requirement—which of course is why design activities do not lend themselves to being automated.

Figure 2.1: The interaction between requirements and design models

Taken together, these ideas are certainly at variance with the reductionist approaches to problem-solving widely employed in mathematics and science. Such an approach seeks to break a problem down into smaller, more manageable (and solvable) elements, with an implicit assumption that there will be a single solution that this process will converge on.

In contrast, ill-structured design problems require the designer to juggle many different aspects of their ‘solution’ simultaneously. This then requires the development and use of complex models, and making a ‘wrong’ design choice earlier in the design process may make it harder to resolve later choices. The concept of orthogonality, whereby the parameters of a model are independent from each other, doesn't apply to an ISP, where factors may interact in different ways and the best that we can hope to do is to make trade-offs between them. Our choices between options are apt to be driven by the need to find a balance, rather than expecting to find the ‘right’ outcome.

So, these are the types of problems that we will be addressing in the following chapters. Successful designing does not result simply from following prescribed processes or reusing structures that have worked for others. As we will see, these things might well be useful elements in the design process, or in learning about it, but even then, their use will probably involve some degree of adaptation.

2.3What does a designer do?

So, what exactly is involved in designing something? A good starting point is to consider the words of a pioneering ‘design methodologist’, J. Christopher Jones, taken from his classic work, Design Methods: Seeds of Human Futures (1970).

This statement describes an approach to tackling an ISP that is radically different from the reductionist practices of ‘scientific method’ commonly used with WSPs, and involving sub-dividing a complex problem into simpler ones. So in its way the statement from Jones is both challenging and unsettling—we are asked to postulate the form of the desired end result in order to try to achieve it, rather than to proceed through a process of deduction and analysis to determine what its form should be.

One reason for this difference of philosophy is because science is largely concerned with studying things as they are, using observation and experiment as the means of testing ideas. A rather simplified view of the scientific process goes as follows: a scientist observes some phenomenon, builds models of how they think this arises, and then seeks to verify and test those models by using them to make predictions, which are then compared with reality through further observation and experiment. (Of course, this will often be iterative.) In contrast, the description of the design process outlined by Jones is one that is more familiar to engineers, and is one that is seeking to create new things. The focus is upon devising some mechanism that will have a new effect upon the world, rather than upon analysing something that exists. To achieve this, we need to postulate what the end result will be, and then to try to devise the means of bringing it about. So this is where creativity comes into play!

Implicitly, such an approach contains some degree of uncertainty, mainly because the ‘solution space’ for an ISP is potentially very large. And this uncertainty occurs partly because we are usually tackling the whole problem, not trying to use a reductionist approach to resolve it as a set of constituent parts. As a result, we may fail to find an effective means of bringing an effect about, or at least, our early attempts might not find the best ways to do this. (Think about some of the early designs for cars, aircraft, television sets etc.) Although of course, an appreciation that these are not the best ways might not be obvious at the time. And while scientific deduction can lead us down blind alleys too, there are usually better tests that can be used to identify and recognise these than are available for assessing the practicality of design solutions.

Figure 2.2 shows the difference between these two processes in a schematic form. Both are gross simplifications of course, but they focus upon the essential differences, not the detailed nature. And the implication that the role of science is to provide a better understanding of the world, while that of design is to provide better tools for living in it, is also something of a simplification.

If we examine the quotation from Jones a little more closely, and rephrase it a little, we can identify some of the actions that a designer will need to perform when deriving and specifying a ‘design solution’ (usually termed a design model) to meet a given need. And, as there will be many possible solutions, the designer needs to refer to “a solution” where the scientist can usually refer to their goal as “the solution”. These actions include:

postulating how a solution may be organised;
building a model of the solution (the design model);
evaluating the model against the original need;
elaborating the design model to a level where it can be realised.

Of course it is never as simple as this! While there is an implicit ordering for these activities, they are by no means likely to be performed as a simple sequence. It is usually necessary to perform many iterations at each stage as well as between stages, and quite extensive backtracking may be needed when design choices have to be re-evaluated. Indeed, as Jones (1970) recognises, the position may be even worse, since:

In other words, the act of elaborating the original model may reveal its inadequacies or even total unsuitability, requiring that it be discarded altogether!

2.4A simple example: the house move

At this point, it may be useful to look at a simple illustration of the use of design thinking. Moving to a new house or flat is a fairly common experience, and is widely regarded as one of the major traumas in life. However, within this lies a good illustration of the use of design thinking, so for our example, we briefly examine some of the activities that might be involved when planning a move into a new house. Strictly of course, this is ‘design as planning’ rather than ‘design as adaptation’. However, using this perspective provides a rather easier introduction to, and illustration of, the nature of designing as well as of ISPs, while possessing the same key characteristics.

One of the practices often recommended for organising a move is to begin by measuring the dimensions of the various rooms in the house, then to obtain some squared paper and use this to draw a scale plan showing all of the rooms, with the positions of doors, windows etc. (If this sounds a bit low-tech, just wait…) Figure 2.3 shows a simple example of this. The next step is to measure the dimensions of our furniture and then to cut out pieces of cardboard with shapes that represent this on the chosen scale. Together with the scale plan, these form a ‘model’ of the house and its future contents.

Figure 2.3: Plan of a single-storey house

The following bit of the process is the ‘design’ element, which is also pretty low-tech, and involves trying to identify the ‘best’ positions for all of our furniture in the new house by placing the cardboard shapes on our model and trying to visualise the outcomes. There are some obvious constraints (we don't usually want bedroom furniture in the kitchen), and there may be issues of colour or style which affect how specific items of furniture might go together, but essentially there is really no systematic way of doing this. Nor is there a clear measure that tells us that we have found the ‘best’ plan. And of course, this is really a two-dimensional representation of a three-dimensional situation, so we also have to consider the possibility of furniture blocking windows or radiators, or obstructing access to power sockets ².

The decisions that result from this process can then be regarded as providing a plan that can help the removal team on the day. Indeed, not only will it tell them where items are meant to go, it may also affect the way that they pack the items in their van so that unloading is made easier. So, the outcomes from our design activity may well feed into the way that they go about planning their tasks too.

Compared with designing software, this is a relatively simple process. Yet it is sufficient to illustrate some of the ways that design differs from analysis. As noted previously, when solving WSPs, especially when these are mathematical in nature, we try to separate different variables and simplify our task by deriving a solution for each of them separately (reductionism). In contrast, for design we have to manipulate all or most of the elements of a complex model throughout the process. There are also many possible ‘solutions’; there is no really useful criterion to tell us that we have found the optimum one, and no way of knowing when to stop (other than exhaustion). And there may be trade-offs too: we may need to accept the odd partially-blocked power socket in order to get the layout that we want in a particular room. Finally, it is still a (design) model—on the day, when we see everything in place, there's a good chance that it will become blindingly obvious that it is possible to improve substantially on what we have devised, or even worse, that there is a major flaw in it.

However, in many ways, this provides a much simpler environment than the one that the software designer faces. The model is closely and physically related to the solution, the set of objects being manipulated is a fixed one, and the properties for each of them are known. Also, the design process only involves us in modelling physical objects rather than processes, unlike designing with software. So, while the example illustrates some key aspects about the design process, we should not forget that things are rapidly going to get more complicated when we come to design software applications.

Key take-home points about designing

This second chapter has largely focused on how design thinking is applied to designing new things.

Designing is creative. The aim of designing is to create something that does not already exist. This requires the designer to predict a (desired) outcome and explore ways of bringing this about.
Design is used to address ill-structured problems (ISPs). This means that there will be a large number of possible ‘solutions’ (designs) for a given problem, and that the process of designing has no ‘stopping rule’ that tells the designer that the current state of their design solution is good enough. As an added complication, there are no simple measures that can be used to assess the feasibility of a design plan.
Designers solve problems differently to scientists. Scientists commonly address problems by following a process of reductionism, seeking to resolve a complex problem into separate simpler ones that can be more readily solved analytically. Designing involves exploring all, or most, of the characteristics of the ‘design model’ at once, rather than being able to consider them separately.