Let’s imagine we are the catalyst for starting a new project, some design challenge relating to a new app.
First, we all recognize the value of the participants in a conversation. We all experience the improvement in thinking and outcomes when we work with someone else. This seems to say, “more participants means better outcomes”—hah, you know that’s not such a good idea. Too many voices, too much distraction. So, how would we decide whom to have in that first conversation?
Here is where the concept of “variety in the conversation” comes in. “Variety” is a term with everyday meaning, but it is also a rigorous concept from W. Ross Ashby. In less rigorous terms:
Variety is the capability and capacity of a system to achieve its goals.
Let’s unpack that further:
- capability, in the sense that, does someone know how to make a wireframe? Or code an app?
- capacity, in the sense that, does this person have a wide range of knowledge of wireframe techniques, or less? Does she know iOS as well as Android or only one?
Now let’s apply this to a project to create a new app that will extract the essence from a web page and present a personalized, short snippet to a specific user based on their history. What variety do we need in that first conversation to best frame the problem and proceed from there?
Here are some general guidelines of how to design the first design conversation, based on the concept of variety:
- What set of capabilities do we think we need? (We can change our mind later.) Certainly an IxD designer, a visual designer, an app coder, usability researcher, product manager… let’s start there.
- Whom do we know from our internal colleagues and possibly external contractors and advisors? Make a list of experts in every different category of capability. (Of course there will be overlaps to be considered.)
Now it gets trickier. Let’s say we have 3 possible app coders—Mary, Sandy, and John. Do we invite them all? Could be a waste of their time and of company bandwidth, and just add too many voices to the conversation. So how do we decide?
This is where variety comes in. If we invite Mary, we get pretty much what John knows (iOS) but Mary also knows Android (greater capacity than John). So, at least in the abstract, if we have Mary, we don’t also need John. Regarding Sandy, harder to tell a difference with Mary because both have written code for both platforms and for roughly the same amount of time, and for apps that involved content. So how do we move ahead?
Well, let’s say that we have only 1 possible IxD designer, Tracey, because no others are available (whew, that simplifies it a little). And, Sandy and Tracey have worked together on similar projects a few times, so they are both comfortable with each other and have developed a rapport—a shared language, an ease in working together, and a trust of each other—that ought to make the conversation flow more easily.
We could keep going for the other categories but the basic points are these:
- If we add another participant, do we increase the variety in the conversation?
- If we add this particular participant, do we build on prior conversations and trust?
Designing this first conversation is only the start, obviously. Here’s an approach to the more general issues in designing for collaboration. This is an example of “designing for conversation, more about that in this blogpost of that name.