Below are some thoughts on the experience of Design Jams, I’ve been to three events so far, two in London and one in Oxford. Design Jams are one-day events where designers get together to learn and collaborate, the events are run by local volunteers and all results are shared under a Creative Commons License.
I’ll be using a paper published by Nigel Cross and Anita Clayburn Cross in Design Studies 16 (1995) called Observations of Teamwork and Social Processes in Design as a guide for analysing the activity of my teams at Design Jam.
The idea here is to have a better understanding of how the teams articulated a (partial) solution to a design problem in a really short amount of time, it might help designers taking part of such events in the future by giving them a series of items they could pay attention to, helping them make the most out of their team’s time and expertise.
In the experiment observed by Cross, team members all worked for the same design consultancy, were in the same hierarchy within it and brought no pre-determined roles to the experimental session. Their challenge was to design a rack for a specific backpack to fit on a specific bicycle model, the amount of time given to participants was not mentioned (although more than once they refer to it as not being long enough).
Design Jam’s topics are usually much broader, add to it the short amount of time and the fact that team members don’t usually know each other and you’re in for a challenging (but always fun) day.
Cross observes the following aspects of teamwork in his paper, and I will try to relate them to my Design Jam experience:
- roles and relationships
- planning and acting
- information gathering and sharing
- problem analysis and understanding
- concept generating and adopting
- conflict avoiding and resolving
1. Roles and Relationships
When working as a group team members have roles and relationships relative to each other, these can be formal (as in “I’m going to keep track of the time”) or informal (you simply start doing something and from then on you’re responsible for it).
Not knowing each other, the first thing Design Jam teams usually do is a quick introduction of experiences each member can bring to the team. They then go on to read the topic once again to make sure everyone is on the same page before they start discussing it. (more on this in topic 4 problem analysis and understanding)
A few roles usually begin to emerge: someone volunteers to read the topic aloud and might become responsible for presenting the group’s ideas in both the interim and final presentations. Someone else is usually responsible for time-keeping and the general idea for the project is usually based on early sketches by one of the members (more on how this happens in topic 5: concept generating and adopting). As in the experiment, all of the members at some point exercise a leadership position within the group, either by suggesting ideas or by trying to keep the team focused on the task.
2. Planning and Acting
According to Cross the team in his experiment had a great awareness of time and scheduled their tasks, but still the author admits that “conventionally, much design activity – particularly the conceptual design stage – is unplanned, intuitive and ad hoc”, he also cites other studies that reference an “opportunistic” behaviour of the designers, which means they’ll pursue ideas as they occur, diverging from planned activities. A few observations made by the author:
- there was explicit planning of activities and scheduling of time;
- a role of “scheduler/timekeeper” was assigned to one member;
- at times someone will draw attention to what to do next or what they should be doing;
- there are unplanned discontinuities of activities;
- activities may be started without a formal decision;
- there is an opportunistic drifting from the plan
In my first Design Jam, although we were all aware of time constraints, we had no detailed list of activities, we also did try to keep track of time at the beginning of the group work, but it didn’t last long and this surely had an impact on our final solution. This is something that was easily fixed on the next two events simply by making a list of activities we should be aware of and keeping an eye on the countdown timer.
I can recall various situations where we made use of the “opportunistic behaviour” which, being part of the design thinking, is something positive as long as you have an established plan to go back to.
3. Information Gathering and Sharing
Relevant information needs to be gathered, extracted from the source and shared with the team (one interesting aspect of the experiment is that the researcher had in his possession additional information on the project that could be requested by the team as they needed it):
- gathering and sharing of information is not formalised;
- errors in understanding the requirements, misinterpretation of information and forgetfulness of requirements;
- misunderstanding of apparently shared concepts;
- use and reliance on individual experience or knowledge
As in the experiment, our teams had no formal role of information-gatherer or a defined strategy for gathering/sharing information. At some point we all decided we should look for similar products that had some of the characteristics we were identifying for our solution, but no specific notes about each product were made, we relied instead heavily on our individual experiences and knowledge during research and exploration.
In future versions of Design Jam it might help making the topic available a day or a few hours before the start of the challenge, so that everyone can do their own research and then bring some ideas to the table. Another possibility would be for the organisers to prepare some material with references giving the teams a starting point.
4. Problem Analysis and Understanding
According to Cross there are two ways of analysing and understanding a problem: listing and framing.
When listing, you’re summarising and sharing the problem with your group (using a whiteboard, flipchart, etc.); framing is a way of internalizing it, through sketches, notes or verbal exchanges (for example, saying “hmm hmm” when someone explains something to you) before making your understanding of the problem external.
A recurrent behaviour on all Design Jams was not giving enough time to framing as for listing of the problem, a tendency is to try and solve the problem as a group, sharing/discussing a problem with the group is important, but give yourself a few minutes to think about it on your own, making notes and sketches. This was especially true on my first Jam, by the end of the day I had a feeling of not having completely grasped what we were trying to solve, which is a fatal mistake when trying to design something.
5. Concept Generating and Adopting
The experiment is mainly concerned with how concepts are developed together and how team members persuade others to adopt a certain concept.
- concepts are built cooperatively: concepts have to be built up, with ideas being discarded along the way and additions and variations added to a concept;
- persuasive tactics are used to get concepts adopted: it may be necessary to persuade other team members to the value of a concept, it’s also common for designers to become emotionally attached to concepts (usually their own)
On all Jams the teams I was part of we had no major issues cooperatively generating and adopting concepts, we’d probably get better results by using idea generation exercises (the 6-up template, for example), as it was suggested by one of the team members and done by a couple of other teams. I noticed we suffered from what Cross calls the “fixation effect” of a concept, after we saw a particular early sketch from one of the team members we all used that idea as a starting point, not giving much thought about alternative approaches.
6. Conflict Avoiding and Resolving
Disagreement between members of a design team are inevitable, but since they all (at least we hope they do) want to find a solution for the design task, they’ll find ways of resolving or avoiding conflict, according to Cross these are usually expressed by means of:
- noncommittal “agreements”: shrugging shoulders or saying “ok” without really meaning it, when this happens issues usually reappear later in the process;
- arguments that close a disagreement: someone will come up with examples of existing products/situations that prove a certain idea to be inappropriate;
- leaving disagreements unresolved for the sake of finishing the task: usually expressed as “let’s keep going and take a look at this later” or even making fun of an idea as a way of dismissing it (usually when team members know each other reasonably well);
On my first Design Jam we had a few points of disagreement inside the group, especially as we moved closer to the end of the exercise, where we couldn’t quite agree on which format would be ideal when starting to add content to the interface, because of the short amount of time though, we ended up leaving those disagreements unresolved and trying to get as much as we could ready for the final presentation, the normal thing would be of course to look for arguments that could close the disagreement.
Conclusions
Even though my analysis is not as precise as the original experiment (I wrote this based on my memory from the events, Cross recorded his experiment on video), our behaviour matches almost all of the those described, I think it’s a valid exercise to reflect on this and be mindful of them in the “real world”.
I was not completely satisfied with the design solution from my first Design Jam, I think we had some interesting ideas come up but we didn’t explain/develop them very well. The results from my groups in the next two Jams were considerably better, probably because we accepted beforehand that a “perfect” solution was just not possible with the amount of time given, finding a main line of thought and keeping the team focused on it during the whole exercise was vital.
Meeting new people with the same interests, listening to other ideas on the same design challenge, watching different solutions and then reflecting on everything and trying to identify where we could have done a better job surpasses any final result and makes joining an event like Design Jam well worth a Saturday.
I highly recommend other texts from Nigel Cross, he’s written a few on the importance of sketching to design that are especially interesting, take a look at his complete list of publications.
You can watch interim and final presentations from my teams here:
Let me know your thoughts/experiences related to team work on events similar to Design Jam. Thanks for reading!