Have you ever been in a design review where instead of talking about the proposed solution you spend half the time revisiting what the user is trying to accomplish in the first place? Keeping the human-centered models of the processes that lie behind your solution fresh in the minds of stakeholders (and designers) can prevent this unwanted rehashing. One way to ensure this is to create a diagram and give it qualities that make it simple enough and memorable enough so that, on a dime, you can whip out a dry-erase pen and sketch it out as a reminder.
I like to call that collection of qualities whiteboardability. It won't work with extremely complex business processes, but for simpler processes or most consumer domains, it works well.
How to encourage whiteboardability
What grants whiteboardability? Of course the first and most important way to ensure the success of your research ideas is through thorough research and smart analysis. This article presumes that these things are already accomplished and you're just concerned about how to represent them.
So what about the form of the diagram? Answering this question takes us into the heady world of memes and memetics, but we'll dip just enough to come back with some meaningful attributes.
A meme can be informally defined as an information structure that replicates between human minds. Examples include songs you hear someone singing that won't leave your head, jokes, and even language. Simple business process diagrams are another. Richard Dawkins introduced the concept of memes in his 1976 book The Selfish Gene, coining the term "meme" to be similar to "gene," further illustrating the thesis of his book. Memetics, in turn, is the study of these memes and how they operate.
Though memetics is still a nascent field, some brilliant work is being done. This article references the 2003 thesis of Klaas Chielens, titled The Viral Aspects of Language: A Quantitative Research of Memetic Selection Criteria. In this publication, Chielens studies the way viral hoaxes propagate via email to develop a set of criteria for what makes them successful. By extension, adoption of similar criteria should help any meme.
In this paper Chielens identifies a number of attributes, four of which are relevant to the propagation of interaction design diagrams across the modern conference room medium, i.e. whiteboards. They are: simplicity, expressivity, distinctness, and formality. Read below for descriptions of each.
1. Simplicity means having few parts. It means not being complex. Simple things are easier to store and recall. So if you have the choice between representing the business process as a circle and a multinode snowflake, the circle is the better bet since it will have fewer parts and fewer connections between those parts.
Simplicity also applies to the labels associated with parts of your diagram. If they are simpler words that share parallel parts of speech, e.g. all nouns, they will be easier to process and recall. If they create a memorable acronym, so much the better, but of course don't force it. Simplicity in labels must be balanced with the accuracy of your terminology, since one can come at the cost of the other.
Simplicity is the most important aspect of the diagram over which you have control.
2. Simplicity, in turn, helps ensure another of the criteria: expressivity. The simpler the diagram, the easier it will be for you and others to recall and express it on the spur of the moment. Here as well you may need to resist pedantic exactitude.
3. Distinctness is the degree to which the structure is unique in its domain. For example, if in your research you discover a Venn diagram that is already frequently referenced by the stakeholders, using a Venn diagram to illustrate your idea may be confusing for the audience, lessening its chances for survival.
4. The most nuanced criteria Chielens provides is formality. He explains it as that which gives the lowest chance for misinterpretation. If the business process it describes is itself distinct this shouldn't be a problem. If it is not, it might be necessary to escalate the scope of what you're trying to model, or put the effort into describing both processes side by side so the difference is part of the communication.
So when you are considering different forms that you could give to a diagram of a business process, use the following three questions to evaluate which one will work the best to ensure whiteboardability.
- Is it simple to understand, remember, draw, and explain?
- Is its meaning unambiguous?
- Is it distinct from other diagrams frequently seen in the domain?
A concluding example
Let's say we're developing a service for a company that supplies fire extinguishers. In the analysis we identify that they have six main phases of the product life cycle that the service must support.
- Learning the need for the product
- Acquiring the product
- If there is a fire, using the product (leading to the need for another)
- Learning when it expires (leading to the need to recycle it)
- Recycling the product when its chemicals expire (leading to the need for another)
An initial diagram might take each of these steps duly into account, with a node for each, explanatory labels for steps that involve the service, an icon for the (unfortunate) event external to the service, and arrows connecting them that show the primary service flow.
While this is accurate and satisfactory, it fails our criteria in a number of ways. It's not simple in its layout or its labeling, it has some extraneous components, and the parts of speech don't match. (While I tried to embody all the criteria, since this is a simple example, we can presume it is distinct from other diagrams in the rich fire-extinguisher-service domain.)
The next iteration aligns the nodes into a stack, and gets rid of some extra words. It also eliminates the fire icon because it is implied in the "using" node.
While significantly easier, the words are a little long and that little reminder bit sticks out. Since the reminder can be subsumed under the "recycling" node as part of the same event, we can make it simpler still.
This drawing additionally simplifies the language, switching the verb tense to the simpler present tense, and swapping "acquire" for the simpler word "get." It may be less exhaustive and accurate than the prior diagrams, but certainly easier to assimilate, retain, recall, and express. In a word, more whiteboardable.
An added benefit is that whiteboardable diagrams, once they reach this stage, are excellent bases for developing more rich, well-produced versions that would be included in documentation and presentations.
During a design review at a client's office earlier this year, I was quite pleased to see someone from the product team pick up a white board marker and replicate a drawing from our research to help answer a colleague's question. Not only did it make me confident that the team had internalized the key issues behind the design, it got us right back on track by quickly reminding the team about what was important. The small moment illustrated the importance of ensuring that diagrams are memetic enough to help propagate the rest of your goal-directed design to the teams that will implement them.