Summary: A real-world example of Dan Klyn's structure and strategy approach to client communication, using really dumb models.
How do you explain things so your client can understand and make decisions? At a meta-level, all knowledge worker efforts revolve around this question.
It comes up at TUG all the time. Dan Klyn’s remarkable presentation about strategy and structure has a lot to say about how to approach a structure for developing understanding. He describes four categories of “doing it right”:
Mapped Intentions—Creating explicit models that clients can “adjust”, like a slider.
Control of Meaning—Really the creation of ontologies (particular meaning) and taxonomies (arrangement of the parts).
Dumb Models—Using models—LOTS of models—as metaphors that convey a concept without being wedded to a final design.
Structural Vocabulary—Common language for talking about structure.
These are powerful formative concepts for explaining ideas to clients, particularly that of the “dumb model,” my personal favorite.
Getting to Understanding
Recently I had a chance to see how dumb models could be used first-hand. I was on a project on a web analytics implementation project, a kind of work I have done regularly since 2006 with good success. This project, however, had an exceptionally complex and thorny account structure that the client wanted to migrate to the new analytics structure. After a rough couple of weeks, it was clear that we were not helping our client understand and make decisions.
My first impulse in these situations is to “make a better spreadsheet.” I created a spreadsheet for explaining the data elements and then asked my co-worker Somesh Rahul to have a look and see how to use it in the upcoming presentation:
Somesh walked away for a while, then came back and said, “I don’t really understand it this way. Do you mind if I try something different?”
Boy, did I not mind.
An hour later, he returned with not one, but TWO models for characterizing the client’s current structure and proposed improvements. Somesh dealt with this problem by taking two different frames of reference out of the spreadsheet—one ontological, one taxonomical—and added some common meaning between the two via color.
Here’s the ontological model:
The ontological approach was to organize ideas around current accounts and properties in circles, while the taxonomic approach used a tree:
Neither model is actually used in Google Analytics, but both were amazingly good and conveying the current and future relationships.
Your Concept Model is NOT Your Implementation Model
We used both of these models to drive critical decision-making discussions with the client for the next two weeks. When we’d reached a certain level of understanding, we then converted the models back into a more formal requirements specification, in the form of a spreadsheet, and completed the implementation.
These design concepts were crystallizations of two critical ideas that Dan Klyn explored during his description of the “dumb model concept”:
You’re not talking about how to make anything yet; you’re talking about what would be good to do.
You’re making an argument for how to have the parts come together; you’re not depicting how you’re going to do it.
In other words, we were struggling because our models weren’t “dumb” enough. The metaphors were too difficult to understand and too close to the way the analytics account would be designed.
Somesh created these models almost instinctively, but I was so delighted at the time that I sat down and interviewed him on his thought process. While it looks simple after the fact, it’s not easy. In order for Somesh to make these dumb models, he had to:
1) Determine that the current model was unclear and have the courage to surface its insufficiency.
2) Have the creativity to explore the problem in a different way.
3) Have a sufficiently deep tool box to allow him to create better metaphors that would get the job done.
I still have not gotten used to how often this happens at TUG. It has convinced me that the combination of these three factors is really critical to building “dumb models,” and other parts of structure and strategy, that make effective information architecture possible.