by Nigel Cross
Collaboration
One thing we are able to do with a teamwork experiment is to observe how designers work in collaboration with one another. We have already seen in that experiment how the three designers tended to play different roles. Some researchers who analysed this experiment noted the different approaches to design that were shown by the three, and especially the differences between Kerry’s and John’s approaches. Particularly in the early part of the session, Kerry tended to want to gather specific information and to engage with the hardware and some of its details, whereas John tended to want to step back from details, work at a more general level of the overall process and gain a broad view of the problem. The different approaches of Kerry and John were summarised by Margot Brereton and her colleagues as wanting to pin down a solution (Kerry) and wanting to preserve ambiguity (John) (Table 7.1). Having two such emphases within a team can be good, but of course it has to be managed to avoid conflict and achieve a constructive outcome. Brereton et al. pointed out that, to resolve or avoid conflict, ‘The designers masterfully invoke the support of neutral parties such as common sense, higher principles or theories, and expert or standard practices to support their opinions. These serve to depersonalise the debate, in addition to being means of persuasion and explanation of rationale.’ These experienced designers seem to have had some effective strategies for working together that built on each other’s preferences for ways of approaching the design task. Brereton et al. concluded that ‘the collaboration is successful because the group is well balanced in their roles and manages their negotiation well. Kerry seeks to pin down solution alternatives, John seeks to preserve ambiguity and characterise the ongoing process, and Ivan keeps the solution progress on track and acts as an arbitrator between John and Kerry’ (see Table 7.2).
Table 7.1 Different design approaches of Kerry and John.
Table 7.2 Different roles adopted by the three designers.
Despite the differences between the individual designers, analyses of the experiment have shown that their individual contributions to the session, while different in content, were often similar in terms of quantity. While John produced more solution variant ideas, equal to those of the other two together, all three contributed equally in analysis comments on solution variants, and John and Kerry each contributed exactly the same number of decisions in choosing between solution variants (Ivan rather less). Ivan, as we might now expect, made many more comments on organising the process, in contrast to Kerry who made very few such comments. Several analysts of the experiment have suggested that John was the most influential member, acting as team leader and being the ‘ideas person’. However, this is not just a matter of being a dominant personality, and ‘having the most to say’. Andy Dong made a very detailed analysis of the conversational patterns of this and other teams in similar experiments, and suggested that the constructive influence of a member in a design team is due to the way he or she interacts with the others and articulates shared concepts. He observed that, ‘while John is a productive individual idea generator, he also builds upon Ivan’s and Kerry’s ideas’. For example, Dong refers to points in the conversation where John ‘accumulates the discourse’ and characterises a shared concept at that point, such as ‘maybe it’s a pack conversion kit’ or ‘maybe it’s a little vacuum formed tray’. To ‘accumulate the discourse’ means not just to sum up, but to make a constructive contribution that focuses the previous discussion onto a type of solution concept and suggests a way forward. Dong referred to this as ‘deriving a representation of the team’s shared language that frames the design concept.’
However, in successful team design work, this constructive approach is not due to just one member of the team. Dong also looked at other teams and found that, in the more successful teams, the whole pattern of their conversation was more focused. A successful team’s discussion showed more ‘coherent’ development, in which the team members built upon each other’s contributions, progressing in a coherent form of conversation. The evidence for this lay in measuring how closely team members’ contributions to the discussion followed on from previous contributions, rather than diverging from them.
An individual designer working alone has no one to collaborate with, so how does the work of an individual designer compare with that of a team? These two experiments, using the same design task, allow us to make such a comparison, and the question was explicitly addressed by Gabriela Goldschmidt. She pointed out that the cognitive tasks within design can be shared out between team members, whereas designers working on their own have to produce the full range of tasks of inquiring, formulating, suggesting, evaluating, modifying, and so on. She compared several key sequences of activity between Victor and the team, and found some significant similarities, with Victor’s activities often ‘shadowing’ those of the team: ‘He oscillates between overviews and technical details, between functional aspects of the design product and issues related to human factors. He thinks of features, product identity and aesthetics along with stiffness, strength and ease of production. Team members do the same, but they can let a colleague answer a question they raise, or pick up someone else’s line of thought and build on it. The single designer has only him or herself to rely on, and he or she must act as a team and give all the answers while also asking all the questions.’
These comments indicate some of the complexity that there is in the task of designing. Goldschmidt’s conclusion is that Victor implicitly ‘plays’ several roles, and acts as ‘a team of one’, as in this extract from his think-aloud comments about adding some plastic clips to his rack design, that would grip and hold the backpack frame: ‘Why do we want clips? Because we want to take advantage of the fact we’re using an external frame backpack. An internal frame can’t use clips.’ Here, she suggests, Victor1 asks, Victor2 answers, and Victor3 gives the design rationale. In this, there is an echo of designers ‘talking to themselves’ implicitly through their drawings and in their scribbled comments.
In both the individual and the team processes there is also an echo, and perhaps a confirmation of Donald Schön’s characterisation of design as ‘a reflective conversation’, to which I referred in Chapter 1. According to Schön, this kind of reflective, or coherent, ‘conversation’ proceeds through acts of naming and framing: ‘we name the things to which we will attend and frame the context in which we will attend to them’. He suggested that: ‘In order to formulate a design problem to be solved, the designer must frame a problematic design situation: set its boundaries, select particular things and relations for attention, and impose on the situation a coherence that guides subsequent moves.’ This seems to characterise well what we have observed in these examples of designers at work. The designers select features of the problem space to which they choose to attend (naming) and identify areas of the solution space in which they choose to explore (framing).
For success, these activities of naming and framing have to be balanced. Rianne Valkenburg and Kees Dorst studied successful and unsuccessful teams of student industrial designers. The successful team developed a sequence of five framing concepts during the project, in contrast to the single frame used by the unsuccessful team. And the unsuccessful team spent much greater amounts of time on ‘naming’ activities – i.e. on identifying potential problem features, rather than on framing and developing solution concepts. It seems clear that designing requires sophisticated skills in gathering and structuring information, and judging the moment to ‘accumulate’ and move on to solution generation.
For example, Henri Christiaans and Kees Dorst found, from protocol studies of junior and senior industrial design students, that some students became stuck on information gathering, rather than progressing to solution generation. They found that this was not such a significant difficulty for junior students, who did not gather a lot of information, and tended to ‘solve a simple problem’, being unaware of a lot of potential criteria and difficulties. But they found that senior students could be divided i
nto two types. The more successful group, in terms of the quality of their solutions, ‘asks less information, processes it instantly, and gives the impression of consciously building up an image of the problem. They look for and make priorities early on in the process.’ This is the activity of framing. The other group gathered lots of information, but for them, the activity of naming, or simply gathering data, was sometimes just a substitute activity for actually doing any design work.
Design Process
Experienced designers know that it is possible to go on almost forever gathering information and data about a design problem, but that they have to move on to generating solution proposals, which in themselves begin to indicate what is relevant information. In a design project it is often not at all clear what ‘the problem’ is; it may have been only loosely defined by the client, many constraints and criteria may be un-defined, and everyone involved in the project may know that goals may be re-defined during the project. In design, ‘problems’ are often defined only in relation to ideas for their ‘solution’, and designers do not typically proceed by first attempting to define their problems rigorously. Of course, this can mean that important information is overlooked, or is discovered only very late in the design process, causing disruption and delay. For these reasons, there have been attempts to set out models of an ideal design process, and suggestions for methodologies or structured approaches that should lead designers efficiently towards a good solution.
It is therefore interesting that, in this experiment, the team did set out a ‘model’ of their process and tried to stick to it. Their model process consisted of the following stages:
Quantify the problem
Generate concepts
Refine concepts
Select a concept
Design
Present
Some analysts have looked at the actual process that they (and Victor) followed. For example, Joachim Günther and colleagues analysed the individual statements in the protocols into three types, concerned with (1) clarifying the task, (2) searching for concepts, and (3) fixing the concept. Their analysis of what actually happened in the team is given in Figure 7.1. We can see that the three types of activity became considerably mixed together. Throughout the first half of the session there was a lot of iteration between ‘clarifying the task’ and ‘searching for concepts’. What the team was actually doing through this period was generating lots of partial concepts and then considering the implications of those concepts. In that way they were exploring the problem through possible solutions. They did not spend very long on their initial task of ‘quantify the problem’ in isolation from generation of concepts, but after about twenty minutes they began to consider specific aspects of solution concepts, and then (thanks to Ivan) organised this into searches for ‘joining concepts’, divided into joining ‘pack to rack’ and ‘rack to bike’.
The graph in Figure 7.1 shows clearly that ‘searching for concepts’ dominated most of the team’s process, but came to a fairly quick stop soon after they identified the ‘tray’ concept, at around 80 minutes. Overall, they followed the activities that they had set out in their model process, but not in a strict sequence of separate activities.
7.1 Principal phases of the team’s design process.
It might seem surprising that ‘clarifying the task’ is an activity that recurs throughout so much of the session, as it did in the team’s process. But this pattern has been found in other studies and is not atypical. Vinod Goel found, in protocol studies of architectural design, that ‘problem structuring’ could constitute as much as 30 per cent of the overall task time, and although it was concentrated near the beginning of the task it could recur constantly until almost the very end of the session. It seems quite normal in design work that there is an ongoing interactive exploration of both the problem and the solution, in the process of development that has been characterised by Dorst and Cross as the ‘co-evolution’ of problem and solution.
The graph of Victor’s process (Figure 7.2) shows more clear-cut separation of activities, especially in the first half-hour, in which he concentrated on ‘clarifying the task’ by reading the brief and the evaluation report on the previous prototype solution, and telephoning a company that makes similar products. Victor spent some time in familiarising himself with the task, including considering his own personal experiences of riding with a backpack as well as collecting information from others. A concern with user issues was more evident in Victor’s process than it was in that of the team. He ‘internalised’ the problem information, rather than making externalised lists (perhaps because he did not have to share and agree it with anyone else), decided on a preferred mounting position for the rack and implicitly on its material (tubular steel), and began a process of designing by drawing – making sketches of the bicycle and evolving a structure that met his user requirements for stability and stiffness (and the client’s requirement for uniqueness). In fact, much of his design activity was similar to that of the team, in that he made progress by proposing a partial solution concept and then analysing its strengths and weaknesses.
7.2 Principal phases of Victor Scheinman’s design process.
Victor commented at one point that ‘scheduling my time on these things, that’s the hard part,’ and he frequently commented on the time constraint he was working under. Organising a design process is quite a difficult task, because there has to be allowance for free-flowing activity within an overall schedule of things to be done within a time limit. The team’s design process seemed quite complex; it was free-flowing, but it was also quite controlled. Brereton et al. concluded that ‘the designers are continuously engaged in multiple activities at different levels. Although they focus in on issues, they continuously monitor the progress of the solution from the point of view of various requirements and solution alternatives. They reflect on their course of action, monitoring and modifying their process.’
The differences, such as they are, between the design processes of Victor and those of the team seem to be more to do with the differences between individual and team working processes. Victor was ‘a team of one’ and he was not subject to the pressures and constraints of working with other people, such as we considered in the analysis of teamwork in the previous chapter.
Some other studies have identified that designers usually start with a structured plan for their design process, as our team did, but frequently slip from the plan into ‘opportunistic’ pursuit of issues or partial solutions that catch the designer’s attention, again as our team did. For example, Willemien Visser made a study of an experienced mechanical engineering designer who claimed to be following a structured approach, but Visser found frequent deviations from this plan. She noted that ‘The engineer had a hierarchically structured plan for his activity, but he used it in an opportunistic way. He used it only as long as it was profitable from the point of view of cognitive cost. If more economical cognitive actions arose, he abandoned it.’ Thus Visser regarded reducing ‘cognitive cost’ – i.e. the mental load of maintaining a principled, structured approach – as a major reason for abandoning planned actions and instead, for example, delving into chasing a partial solution at a relatively early stage of the process.
Raymonde Guindon also emphasised the ‘opportunistic’ nature of design activities, which was evident in her protocol studies of three experienced software system designers. Guindon stressed that ‘designers frequently deviate from a top-down approach. These results cannot be accounted for by a model of the design process where problem specification and understanding precedes solution development and where the design solution is elaborated at successively greater levels of detail in a top-down manner.’ Guindon observed the interleaving of problem specification with solution development, ‘drifting’ through partial solution development, and jumps into exploring suddenly recognised partial solutions, which were categorised as major causes of ‘opportunistic solution development’. However, rather than regarding this opport
unism as a weak feature of design behaviour, Guindon suggested it might be inevitable: ‘These deviations are not special cases due to bad design habits or performance breakdowns but are, rather, a natural consequence of the ill-structuredness of problems in the early stages of design.’ Like Visser, Guindon also referred to ‘cognitive cost’ as one possible explanation for such behaviour: ‘Designers find it advantageous to follow a train of thought temporarily, thus arriving at partial solutions at little cognitive cost.’
Vinod Goel observed from his protocol studies of architects and other designers, that ‘as partial, interim ideas and solutions are generated, they are retained, massaged and incrementally developed until they reach their final form. Very rarely are ideas or solutions forgotten or discarded.’ Both Victor and the team worked in this way. Goel called this a strategy of incremental development. He suggested that ‘a number of factors in the design task environment would seem to favour a strategy of incremental development. First, the problems are large … and cannot be completed in a single [problem solving] cycle. Second, since there are few logical constraints on design problems and no wrong or right answers, there is little basis for giving up partial solutions and starting from scratch. It makes more sense to continue to develop what already exists.’
Creative Design
It seems especially hard in teamwork to follow a tightly prescribed process because individual members have individual preferences for ways of working. Also, for both teams and individual designers, there is often a natural flow to design processes that can run counter to a prescription for what should happen when. In analysing these experiments, David Radcliffe concluded that they demonstrated that ‘the emergence of design ideas cannot be constrained to a particular place or sequence in a systematic design methodology. It is clear that design ideas emerge where they will in the continuum of the design conversation … Ideation cannot be constrained to occur only during the prescribed time for this activity as dictated by notions of due process and proper sequence of phases in design.’ As a specific emphasis, Radcliffe pointed out that the team’s decisive ‘tray’ concept was generated during what was supposed to be the evaluation phase to ‘select a concept’.