Summary: The Understanding Group(TUG) helps you discover the true intent of a project, and keeps your vision coherent throughout your web development efforts.
People used to traditional web development sometimes struggle to understand what The Understanding Group’s deliverables actually are. It was true for me, too. After ten years in formal software requirements development, I just couldn’t understand how every project seemed to create a new, unique set of delightful solutions—project deliverables like wireframes, personas, taxonomies, and navigation—that were exactly what the client needed, but still unlike anything I’d seen for any other client before.
It was only after numerous conversations with Dan Cooney and Dan Klyn that I grasped that the uniqueness and fit of these deliverables to projects were logical results of TUG‘s underlying goal: discover the true intent of a project, and then model the vision to keep that intent coherent throughout a development effort.
Dan Klyn calls this model of the vision structure: literally, the sharable blueprint of what is intended to be made. For TUG, all strategy, all deliverables revolve around the creation of structure. And since the structure of every client is unique to that client, so are the deliverables used to uncover and understand that structure.
“Design is the rendering of intent.”
– Jared Spool
So in that context, the deliverable uniqueness makes sense. But how it is created can seem pretty mysterious! Fortunately there’s a rigorous underlying set of principles for what the deliverables need to do that is helpful when trying to understand them. Any deliverable that defines structure will be the outcome of one of these four activities:
1. Map Intentions
2. Arrange for Meaning
3. Create Dumb Models
4. Create and Use a Structural Vocabulary
Mapped Intentions
This method should be familiar to anyone who has helped organizations start to map strategy or manage long-term planning. The essence of the methodology is to create ways for people to surface their understanding of the organization’s goals and then help them make choices between competing priorities in a transparent way. If effectively done, that map will reveal a clear understanding of which intentions are actually important to distill into a project’s structure.
“A map is not the territory it represents but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”
– Korzybski
TUG‘s core technique in this context is the Performance Continuum.
Arranging for Meaning
One of the most powerful tools available to information architects is the arrangement of information. This can create profound differences in understanding. Consider, for example, a set of words that is arranged alphabetically—in other words, a dictionary—then another set that is arranged by synonym or concept type—a thesaurus. The same words in both cases become understood in radically different ways.
This can be a powerful way to make sense of complex and conflicting ideas, particularly those discovered when mapping intentions. The effort can also be used to discover candidate intention maps and, of course, to organize site maps or page structures.
Dumb Models
The idea here will be immediately familiar to anyone working in an Agile environment:
create only as much of a model as is needed to gain understanding, and then STOP.
create as many models, in as many contexts, as is needed to gain understanding.
agree that the models are used for UNDERSTANDING AND STRUCTURE, not for IMPLEMENTATION.
This last activity is perhaps the most difficult for many people to grasp. Almost all models in non-agile software environments assume decomposition—that is, the traceable progression of a requirement of one type and grain into something more detailed but still related. Dumb models do not expect or demand that they convert directly to design, but instead are used to make sure the designs, once created, are correct and map to structure. This is a critical distinction that makes models immensely powerful for discovering and defining structure.
Dublin Design Jam Models
Dumb models exist everywhere in software development, but they are usually relegated to white board discussions and never promoted to the level of use for creating understanding to the larger leadership or executive team. The desire to create formality squeezes out the “dumbness” and, consequently, a lot of the nuance and insight that made them useful in the first place.
The Structural Vocabulary
Across models, intention maps, and models is a recurring theme of *language*. A major thing TUG brings to all the projects it is on is a consistent, shared language for talking about a project as it progresses. This consistency allows organizations to take the work they get from the TUG process into the future by ensuring that the terms and language of the structure are consistent and broadly understood.
A Whole Foods “Duck”
Dan Klyn’s favorite example of a structural vocabulary is his use of “Ducks vs. Sheds“, where ducks are structures explicitly created to match a specific set of needs –
– whereas “decorated sheds” are more generic structures with practical modifications that make them applicable to a specific intent.
A Whole Foods Decorated Shed
Dan isn’t invested in one being better than the other; the point of this exercise is to be sure that, if you are building a duck, you are not trying to force it to do something shed-like. If you have a decorated shed, do not to expect it to behave like a specialized duck. The attributes associated with each definition provide the structural vocabulary needed to make the ongoing design effort effective.
If you want to learn more about these ideas, there is a much deeper exploration in Dan Klyn’s brilliant Strategy and Structure presentation. Or, if you have a question about how we might help you with this approach on a project, just contact us! We’d love to hear from you.