by Nigel Cross
As we have seen, it is also normal, indeed necessary, in design to interpret and re-formulate the problem given as the task. The nature of design problems means that analysing and understanding the problem is an influential part of the design process. Individual designers can form their own, possibly idiosyncratic interpretation of the problem, but a team has to reach some shared or commonly held understanding of the problem.
Furthermore, in any design task, information relevant to the task has to be gathered from a variety of sources. A particular feature of the experiment design of this study was that information on aspects of the problem was kept in a file by the experimenter, to be given to the designers if and when they asked for particular items. This helped to make explicit and observable some aspects of the necessary gathering and sharing of information that any team would have to undertake.
Since a design task also means that the goal is to produce a design proposal for some artefact, it is necessary to generate some ideas or concepts for what that artefact might be. An advantage of teamwork over individual work might be that a greater number and variety of concepts are generated. Again, in teamwork it will be necessary to communicate and share such concepts and ideas. It will be interesting to see how proposing and developing design concepts are handled in teamwork.
A disadvantage of teamwork is likely to be that conflicts will arise between team members. Different interpretations or understandings of the problem may become evident, and different design concepts may be favoured by different members of the team. An inevitable part of design teamwork would therefore seem to be identifying, avoiding and resolving conflicts.
These aspects of teamwork will be considered here in the context of the experimental study, drawing on examples of how these issues became manifest in the team’s design activities.
Roles and Relationships
We do not know the normal working background of the team members of this experiment (identified anonymously as I: ‘Ivan’, J: ‘John’ and K: ‘Kerry’). We do know that they all worked for the same design consultancy firm, had approximately equal previous design experience, and had similar job roles within their firm. We can assume that they were all approximately equal in the hierarchy of their normal work situation, and that there were no predetermined roles that they brought with them to the experimental session.
However, it became clear from the video recording that different roles within the team were adopted. Some of this role-adoption was semi-formalised within the team. Some other potential role-adoption behaviour was not acknowledged and formalised within the team. Informal role-adoption is evident through repeated patterns of behaviour or types of comment by an individual.
This can be illustrated by just a few examples of the ways roles and relationships were established and played within the team, and influenced what happened. For example, immediately after reading the brief, Kerry suggested that they begin by reviewing the design of the existing prototype:
K: What do we need? I guess we should look at their existing prototype, huh?
But John suggested a different activity – checking that they all share the same understanding of the problem:
J: Yeah, em, let me think; we could also just sort of like try to quantify the problem, because, what’s your understanding of the problem first of all?
This ‘problem quantifying’ activity (clarifying the requirements in the brief) was then adopted as the first shared activity of the team; Kerry’s suggestion was implicitly overridden. Then, during the problem quantifying activity, Kerry suggested that gathering information from the user evaluation report would be a useful activity:
K: They’re not pleased with it so far, and the users’ tests have some – in fact it would be nice if we could see those users’ tests to see what the shortcomings were
Again, a suggestion from Kerry was ignored by the others. Shortly after, during a time-scheduling activity, Ivan mentioned use of ‘information’ in the context of refining initial concepts. At this, Kerry again suggested that the user evaluation report might be a source of useful information, and again, this suggestion was not acted upon, and was dismissed as irrelevant to the task in hand:
I: Information or
K: Yeah we wanna look at the em customer feedback or the users’ testing
J: Oh, yeah, so maybe, yeah, wherever that comes in, in this list
A little later still (and after meanwhile requesting from the experimenter the information on the target selling price of the product), Kerry eventually got to ask for the user evaluation report, but note that it was now with the addition of Ivan’s intervention:
K: I think I’d also like to get the information on em
I: The user testing
K: The user testing
After the ‘problem quantifying’ discussion, Ivan suggested that they should prepare a process and time schedule, and John and Ivan proceeded to do this. Later, Ivan began to sort out the various documents on the table top, and John took the opportunity to pick up on Ivan’s interest in scheduling:
I: … let’s get this stuff sorted out
J: OK you were talking about schedule stuff before, do you wanna
I: Yeah, I think we should just figure out
J: Just set some time limits for ourselves
Later again, when Ivan was planning the schedule, this role was confirmed for him by John, Ivan adopted the scheduler/timekeeper role, and played it throughout the session:
I: Five-thirty we’ll move on to the final cost and presentation, let’s leave ourselves a little bit of time
K: mm mm
J: Ivan’s gonna be Mister Schedule
I: Yeah … on time, under budget
In these examples, we see that Kerry apparently experienced difficulty in getting the team to proceed in a way that she would prefer; that Ivan apparently accepted quite readily a facilitator role as timekeeper; and that John apparently had a strong influence on what happened in the team. These examples demonstrate some of the patterns of roles and relationships within the team that were evident throughout the session. However, these roles and relationships were not always fixed and simple. For instance, each member at times took a leadership role, although playing that role in a personal style. It seems inevitable that different ‘role playing’ behaviours will emerge in any team activity, depending on personality, experience, and the task in hand, and it seems that team members could be more sensitive to each other’s preferences.
Planning and Changing Activities
Within the team there was a consciousness of planning the design process; members of the team were particularly aware of planning their activities and of keeping their activities to a schedule. This may seem like normal procedure for a team, but in fact not all teams in similar situations construct such an explicit procedure as this team did.
Much design activity, particularly in the conceptual design stage, is unplanned, intuitive and ad hoc. Other studies of designer behaviour have made clear the ‘opportunistic’ behaviour of designers, which occurs when they deviate from current or planned activities in order to pursue ideas as they occur. It has been argued that opportunistic behaviour is appropriate behaviour for designers because it allows the flexibility to deal with design problems and the ‘opportunities’ that emerge in the design process. However, this creates difficulties in teamwork, where activities need to be coordinated, and an opportunistic deviation initiated by one member may be seen as irrelevant by another. In the analysis here we can observe how this team dealt with these aspects of both adhering to and deviating from planned activities.
Explicit planning of the design process was initiated when Ivan suggested that the team should prepare a schedule of activities, rather than just pursuing unplanned activities. Ivan and John then proceeded to list the following design procedure (Figure 6.1):
1. Quantify the problem
2. Generate concepts
3. Refine concepts
4. Select a concept
&nbs
p; 5. Design
6. Present
6.1 The team’s design process plan.
This procedure seems to be derived from conventional models of a design process. Ivan and John seemed to share a view that this is an appropriate design process to adopt, and this process was in fact broadly followed through the rest of the session.
As noted above, Ivan seemed to ‘volunteer’ as the scheduler, and at important points he would draw attention to schedule and time, for example:
I: We have to start making decisions, we’re already at five-fifteen
And towards the end of the session Ivan kept the time pressure on the others; for example:
I: OK um keep moving along, we have fifteen minutes to finish our design
Ivan’s role of scheduler/timekeeper appeared to be important to the progress of the team, and having a plan for their design process meant that individuals could keep a check on that progress and legitimately call attention to the agreed activities when progress seemed to be drifting.
Nevertheless, some activities were initiated tacitly, rather than there being an explicit decision to undertake the activity. For example, when Ivan suggested it was time to move on to the ideation phase, John agreed, but then began reading aloud from the brief in order to check that the listing of requirements was complete:
I: OK shall we move into ideation?
J: Yeah; I think we’ve, have we covered the, all the stuff ? I’ll just read some of this out loud
Although they had seemingly agreed that it was time to move to ideation, there was no overt decision about how to do that, and in fact John began reading from the marketing report. While he was reading, the other two became restless: Ivan got up and went to look at the example mountain-bike that was in the room; Kerry finished her coffee, got up to put the cup in the bin, then picked up the example backpack that was also in the room and went to the bike with it; Ivan lifted the bike down from its stand; Kerry positioned the backpack behind the saddle. Nothing prior was said: there appeared to be a tacit agreement between Ivan and Kerry that they would work directly with the bike and the backpack at this point. They rather ignored John, who concluded reading and then went to join the others at the bike, and immediately entered into the activity.
John sat astride the bike and began to talk about placing the backpack within the central diamond of the bike frame. Kerry pointed out the impracticality of that; instead, she again held the backpack in position behind the saddle. John then suggested positioning it in front of the handlebars. Ivan began to record these suggestions on the whiteboard (Figure 6.2). The team had now entered upon an activity of considering alternative mounting positions for the backpack, but there was no overt decision made to adopt that activity.
One form of opportunistic deviation from a plan is a serendipitous shift of attention. For example, during discussion of weights (of the backpack, and of the product that is to be designed), Kerry asked for information on existing products (presumably to check the weight of comparable products). When this information was made available, it became more interesting as a source of design ideas, as Kerry indicated the structure of one of the existing products and Ivan realised the implication:
K: This looks a lot like the little backpack frame doesn’t it?
I: Yeah; you see we’ve been, it seems like mentally trying to just, because of a similarity in size and shape between the two, thinking of ways to use the same product for the same thing but I dunno that we necessarily – I mean we’re on a target for fifty-five dollars, I mean if they’re able to make that for forty-two ninety-five … and if we just add a plastic part
This discussion then continued into talk based on Ivan’s experience with a child seat on his own bike. These tacit and unplanned, drifting and discontinuous changes of activity mean that it is not always easy to track what is actually happening in teamwork. Some of the activity naturally becomes more like a conversation than a formal debate, and topics drift in and out of the conversation.
6.2 The team’s early ‘Concepts-positions’ list.
Gathering and Sharing Information
The experiment design, with its controlled access to the available information, meant that gathering information was a more overt activity than it might be otherwise. Relevant information not only had to be gathered, as in any design task, but also had to be extracted from its source and somehow shared among the team. In contrast to their rather formal approach to planning and scheduling their design process, the team had a more informal approach to information gathering.
The team relied heavily on any personal experience and knowledge that members had (or claimed to have) that was relevant to the problem. For example, Kerry used her own experience to offer an opinion on off-centre loading:
K: Well I’ve done a lot of lake touring and I’ve done front panniers and I’ve done rear panniers […]
K: Yeah, front panniers, you could, you could set it up so you could have one of these on each side – there’s no guarantee you’d always have two – but it’s actually not as bad as you’d think to have just one
During the earliest, problem-clarifying activity, we saw that Kerry suggested that gathering information from the user evaluation report would be a useful activity. Despite the difficulties she had in persuading the others to agree to gather information, within the first fifteen minutes of the session Kerry asked for, and received information on the target selling price, the user evaluation report, and the prior prototype design. For example, she interrupted the listing of the ‘Functional Specification’ (Figure 6.3) on the board by Ivan and John to ask for information on the target selling price when this was mentioned as an item for the specification:
J: Cost target, we don’t really know what that is
K: Low
J: Low, but
K: Maybe they have a – do we have that information, let’s see do we ask for – do we have any specification on what the reasonable price range is?
In the same way that a scheduler/timekeeper role was instituted, a formal role for an information gatherer/sharer might have been instituted by the team, but was not. Through her emphasis on information gathering, Kerry effectively might have been ‘volunteering’ to be the information-gatherer for the team, in the way that Ivan ‘volunteered’ to be the scheduler/timekeeper. But no formalised method for gathering and sharing information was instituted by the team, apart from the ‘public’ listing of requirements and concepts on the whiteboard.
6.3 The team’s ‘Functional Specification’.
Perhaps because there was no formal role assigned for information gathering, some misunderstandings and errors became evident. For example, there was no suggestion in the design brief that anything other than the specific, ‘HiStar’ external-frame backpack is the backpack for which the carrying/fastening device has to be designed. But both Ivan and John were confused about this, and Kerry had to correct their misinterpretation:
J: OK I missed that
I: Which part did you miss?
J: … I thought I picked up that they were going to, that they were conceiving of making an internal frame pack, but I guess that’s not what they’re saying; you’re saying that they make external frame packs currently?
K: mm hmm they make external
J: Does it say that they want to stick with that?
I: Well it doesn’t say anything about going uh external or internal, so that I think that you raised a good point, that we have that freedom right now
J: OK maybe we could get something that we’re gonna propose to them that if it has any advantage in this application, right?
I: Sure
J: OK
K: But they wanna use it with this external frame backpack it looks like
I: Right, with this, well let’s see
K: Because the HiStar, this is a best-selling backpack – the mid-range HiStar – they’ve decided to develop an accessory for the HiStar
Late on in the session, as details of the concept d
esign were being resolved over a drawing, Kerry and Ivan forgot that a requirement mentioned in the brief was that the device ‘should fold down, or at any rate be stacked away easily’:
K: What, the rack has to fold?
J: Yes the rack has to fold
K: Where does it say that?
J: It says that in our spec
I: Where?
K: Our spec?
J: Says right here
K: (reads from brief) Should fold down or stack away easily
It also became evident that the team members could misunderstand what were apparently shared concepts. For example, throughout the session, Ivan and John made several references to the ‘rooster tail problem’. Kerry did not query this until quite late in the session, when it became evident that she had not shared the same concept as the other two. She asked if they were referring to a particular tail-strap on the backpack, whereas they were actually referring to the spray of water/mud from the rear wheel of the bike onto the rider’s back:
K: We’re calling this the rooster tail, this little tail?
J: No, the rooster tail – when you, when you ride in the rain and it goes whoosh all over you
The errors and misunderstandings suggest that the team did not have a very effective strategy for gathering and sharing information. The fact that this was a short, experimental design session, and that there was relevant personal knowledge available within the team probably significantly affected the team’s strategy. However, the reliance on personal knowledge, rather than public and more formalised knowledge sources, could again create misunderstanding. Even when information is apparently shared, misinterpretations and misunderstandings are evident, which means that common, shared understanding cannot always be assumed in team work.
