Patterns of dialogue
Several weeks ago when Robby and I started discussing how to better interact with clients, one of our goals was a simpler, more effective process. From my experiences as a math student, I knew that a few carefully chosen symbols along with adherence to a fairly simple structure enabled folks from the world over, with different native languages and different cultures, to discuss mathematics, learn from each other, and understand the topics.
The news press is another profession that makes excellent, effective use of a simple structure to interview people and elicit facts to reconstruct an event at which the reporter was not present. We have a rather high degree of confidence (depending on the media outlet) in the accuracy of the method.
These, among other things, encouraged us to focus on the dialogue we have with our clients. We want to examine the dialogue without any special props or artifacts from a particular methodology. What can we accomplish as knowledgeable people, potentially having different vocabularies and areas of expertise, sitting around a table perhaps with paper and pencil? So far, we've mostly posted about these ideas. But our aim is to extend these ideas into identifying patterns of dialogue.
Here's one: You probably noticed that my posts tend to be pretty long. That's because, just like the three paragraphs above, I usually try to take time to lay some groundwork, get on the same page. And this is often what I do when talking with someone as well. Perhaps a good name would be the Misunderstanding Prevention Focused Long Intro dialogue pattern. The problem is, unless you're pretty dedicated about paying attention, I might lose you before I get done painting the whole picture. A different pattern could focus on one small bit of the relevant topic, frequently check understanding, and build out the background to enhance understanding when necessary. To me, that pattern is much more like BDD and follows the principle of not solving a problem you haven't yet encountered.
Another thing we frequently observe is that any little feature of the software we're building acts just like a spark in tinder, setting a client off on a runaway course of, "Wouldn't it be cool if...". Attempting to blow out that flame before it derails the discussion, we often use totally irrelevant data that has less provocative affect. For example, in a recent prototype showing tagging features, we used names of food as tags, which have absolutely nothing to do with the application. The intent was to prevent the client from starting to think about the "right tags" and focus instead on the features of the tagging process.
We are attempting that sort of process on a bigger scale with clients who seem naturally to obsess on features. We try to structure the dialogue about the user's goals without referring to the software at all. At first glance, that may seem to increase the likelihood that we will misunderstand what the client wants. But, we find the reverse is true. Feature focus is more likely to contribute to misunderstanding what the client needs. And it prevents the client from learning as well.
What patterns do you observe in your dialogue? When are they appropriate? What are you trying to change about your client interaction?
