Communication is a Basic Design Tool
I coach design teams in the use of Contextual Design, a customer centered design process. When I first started this work I thought it was about how to talk to customers and use customer data effectively. But not surprisingly effective design for the customer also hinges on effective face-to-face communication inside a team.
As an observer of work practice, I have wondered why meetings are so dreaded, indicted as time wasting and considered a place where work does not happen. I have watched the development of meeting running tools to control agendas; identify clear owners and action items; formalize asking and refusing requests; and “encourage participation” through electronic voting and simultaneous individual, often anonymous, input. I have pondered the structure of “teams” which rarely work together as a team; management’s concern for clear owners of system parts, defined responsibilities and identified decision-makers to resolve conflict. I have swooned at the reams of linear text produced in the attempt to communicate a design clearly and explicitly and the review structures put in place to find out what is in them and whether they are complete.
How much of our practice comes from our difficulty talking about design in face-to-face settings? Are we creating structures and tools which limit interaction because we have trouble interacting? Are we thereby losing the coherence of our design and the best use of our people?
I am convinced that delivering a coherent system in a competitive time-frame based on understanding the customer is absolutely necessary and completely dependent on multiple people working together in a room. Here are some of the things I have learned about human dynamics and successful face-to-face team design.
Understanding is Slippery
From beginning almost until it is built a design feels like air; the understanding of the customer is air; agreements are air (that is why lawyers are so intent on “exact” words); what people say hangs in the air and is gone. What you hear from what I say is invisible to me; what I understand about what you say is hidden from you, even if we nod. Consider: The team agrees upon a design approach. They agree on the customer’s problem. They agree on a function to implement .They talk in the hall or in a meeting or on the phone. They nod, say yes and are happy. They do the agreed upon work.
“But you didn’t do what we agreed to! ”
“Yes I did! What do you mean? It’s exactly what we said!”
The team goes on a customer visit. They send around mail describing the important things. They debrief in a meeting. They have a breakthrough. They write a list of functions to implement.
“Why is that function here?” someone asks.
“The customer needs it — we talked to big company number one”
“Well my big customer would hate it.”
“My big customer must have it this way.”
Who is right? Where is the understanding of the customer?
And where is the team’s understanding of the design — on a white board, on a napkin, in the head of the lead architect, in the thick specification they are meeting daily to understand or in the unfinished one they are coding to?
Even when people get along and succeed in reaching agreement in the moment they can lose track of what was meant over time. They may search their individual notes which do not capture their shared ideas. They may call for design and requirements documents which are often hard to understand. Usually they resort to talking to people for clarification and buy-in, making the rounds one by one.
All the conversations about customers, requirements and design are slippery, happening over time and often on the fly. These conversations are the very stuff of product design. But hanging on to a shared understanding among multiple people from moment to moment is hard. So conversations happen over and over and over again.
Creative Thought is a Chain of Reasoning
People in a design meeting often feel like they are on an endless path going no where. They can leave frustrated and incomplete; angry or resigned.
Moving from customer data to a design is like moving through a set of implications. One person’s thought in a design meeting for a presentation tool might look like this:
- Make a customer observation: The slides being used in a presentation are different from what was handed out. The presenter is showing an idea in parts building it interactively as they teach one part of the idea at a time. The handouts have the final point all together.
- Hypothesize what it means: Presenting in parts maintains audience attention and makes understanding easier. But the notes to take home just need to capture the final understanding achieved acting as a memory jog for later.
- See the implications of that on how the system is impacting the work: Not everything handed out to the audience corresponds to a slide to be shown. Not every slide shown will be included in the handouts. Having to create two sets of slides or extra slides for presenting versus handouts wastes space and causes logistics problems for the user when printing or running the slide show.
- Generate a set of design ideas: Provide a print function to select slides to show versus hand out; or provide a function to code each slide for presentation only; or provide a grouping function to group different slides for different purposes
- Compare each one to a set of internal design criteria, knowledge about the system being built, other customer data and company politics: Selecting one by one is too time consuming. Tying the function to printing ignores people who run the slide show from the computer. Coding slide by slide lets the user do it in the moment as they have the intention. Letting users group slides afterward in a different view allows them to change slide shows without having to find the slide inside the show. Grouping can be used for any purpose including the creation of new slide shows out of parts. If I make the group in the outline view the user won’t have to wait for the graphics display of the thumbnail view. If I give a thumbnail peephole upon request users can use it as a browser, selector and text creator.
- Pick a design solution: Make the outliner a browser with an optional thumbnail view and allow users to create groups to print or show there.
This line of reasoning [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][I] shows up in a design conversation this way: “Well if the customer is doing that — we ought to put a text-based browser with optional thumbnail access into the product.” Where did that come from? The thought chain is fast and invisible so a challenge is likely. But what is being challenged: the customer observation (what happened in the field), the interpretation of the meaning of that observation (a conversation about the customers intent in their work), the implication for the system (a conversation about how the work might be changed by the system), the design chosen (a conversation about good design principles and how completely it addressed the work). Or is the challenge really because others in the room could not follow the line of reasoning. It all sped without bringing others through the reasoning process.
The chain of design reasoning is invisible even to the generator of it. Often teams members have to go over and over the points, recovering the chain of reason each picking up on a different link in the conversation. They argue with each other, not knowing they are talking about a different link in the chain. The originator feels unheard, misunderstood and irritated that they just can’t get it. Unable to end, they keep trying to get the others to see their “very simple and obvious!” point.
What’s This Meeting About?
The best thing about having multiple people in a room is they listen from many perspectives catching holes and creating new ideas. The worst thing about having multiple people in a room is they flag holes and generate ideas. Consider:
A customer observation reminds Joe that we don’t have function for it. This kicks off a function conversation which reminds Jane of an implementation problem they didn’t resolve upon which the function is dependent. This kicks off an implementation conversation. But the proposed solution shows Jim that doing it that way would constrain a function supporting another part of the customer work. This stimulates talk to resolve the inconsistency and Bill concludes that they do not have the customer data necessary to make the decision which stimulates a planning conversation for another customer visit. When multiple people work face-to-face they keep tugging on the direction of the meeting because of associative thinking. Their ideas can be good but the experience is exhausting; the team starts many things and finishes none. They called the meeting to talk about one thing and ended up talking about another, resolving few of the issues raised. There may be many good ideas but no one has closure or a sense of moving forward.
Associative thinking means the system is likely to hang together because people are examining the implications of all that is said. Each point made reveals holes in the customer understanding, inconsistencies in the design, and new possibilities for supporting the work. Multiple people listening from multiple perspectives means more will be seen and caught. But without a way to deal with associative thought, a design meeting can be destroyed. Giving up, teams may assign one person to resolve the issue alone and report back. But when the team reviews it associative thought happens again. Do they dare tangle again or do they let a hole slide for fear of the chaos?
Making Team Design Work
Understanding is slippery. Design thinking moves rapidly from conversation to conversation and associative thought drags the conversation from here to there. People get angry and irritated. They roll their eyes, tap their pens and walk out. People get frustrated and throw barbs at perceived offenders. They may refuse to meet or insist on clear agendas which allow for no deviation. People feel unheard and unvalued and slowly stop participating or simply push harder! People complain about meetings. They design in twos and threes for teams of 8-30.
But the problem of team design is about how people think not who people are; its a work problem not a people problem. Here’s what we do:
Make conversations concrete and separate them: use a separate graphic representations for each conversation in the design thought chain. This gives each conversation a language and a place and holds the team’s ever evolving agreement and understanding over time.
A good picture, or formalism contains in its symbols the key concepts and distinctions necessary for one unambiguous conversation. A picture has the advantage of being synthetic by nature; it represents parts and relationships between parts. It lets people see the whole design or understanding at once. If it is big enough, all in the room can see them. (We use pictures the size of flip charts and tables.) Diagrams makes understanding tangible and therefore able to be modified, discussed, saved and interacted with. Taken together the diagrams let a team see and separate their thoughts in a design chain as they traverse it.
Stay on the mainline conversation: start the meeting by identifying which conversation is dominant. At any point in the design process one conversation is the true center of the design work. Let a moderator keep the team on the mainline conversation.
Now each conversation is separated from the other by its symbols and by being on a different piece of paper in the room. The location of the page becomes the place (in front of the diagram) for a group to do work on that conversation. Having a physical place helps keep the team on the mainline conversation; the moderator stands in front of it. Everyone has a tangible reminder of what they are talking about. Change in the topic can be deliberate as the moderator listens for a shift in conversations and the team gravitates to a different a diagram. Staying on topic and moving quickly through a chain of reasoning both become possible.
Make room for associative thinking: give team members PostIts. Whenever a thought comes let people raise it. Knowing the mainline conversation and all the other design conversations the team can tell what conversation the idea belongs to. If it is mainline, pursue it; if not, write it down and stick it to the right conversation. (With the person’s initials for later reference. A neat result of this is that everyone feels heard and learns to self-monitor.)
Having all the design conversations physically represented in the room provides a place to put those associative thoughts so they can be addressed later when that conversation becomes the mainline. Nothing is lost and system coherence and completeness is gained.
Why It Works
When creative people are working together they usually design over an idiosyncratic or formal drawing which represents the flow and results of their shared thought . They create one “drawing” between them representing their conversation and their understanding. And they naturally move to another piece of paper or place on the chalkboard when changing their topic.
We have borrowed the informal practice of creative thinkers, defined a set of diagrams that represent the conversations in the thought chain and spread them over the walls of a meeting to support the natural flow of thought. This strategy gives the team a way to manage their meeting and a place for all their thoughts whenever they may occur.
Revealing design thought publicly and physically has allowed us to solve some of the problems of design meetings. The diagrams become the team’s conversational tool. The team learns to attend to their conversations and manage the flow between them. The team creates a living record of their shared understandings which can be returned to time after time leaving a trace of the origins of their designs from customer data. The team can stay on topic and manage associative thought without blaming each other for disrupting the meeting. And everyone has a way to be heard.
Does all this writing seem like it would bog down a design meeting? Losing track of the conversation at hand and the resulting interpersonal chaos slows teams down much more. Our inability to manage ourselves in a face-to-face design meeting is pushing teams away from the quickest and best means of using our human resources: group talk. Structure of the right kind frees us to think productively and creatively. It allows multiple people with multiple perspectives and multiple contributions to work together. We work faster, we work better, and we have more fun. What do we have to lose?
Footnote
[I] No claim to great design ideas here. Checking the line of reasoning with the customer is much of what Contextual Design is about, but that is for another column!
Published in interactions, July 1994, Vol. 1 No. 3, p. 17.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]