The book “How to Make Sense of Any Mess” is written in a simplistic manner to explain concepts of information architecture. True to the name, the author’s attempt to make the subject matter clear and less messy succeeds. She mentions that during the process of writing this book she iteratively applied some practices of “sensemaking” that she herself uncovered. These principles are not canonical, rather I imagine that the author collated information from her past experiences, and is now sharing with the world.
What I Liked About This Book
I liked the book because it is strung up from first principles of how us humans encounter different kinds of varied messes in our everyday lives, different parameters associated with a mess, and then how best to tweak those parameters to resolve the mess as best as possible. The author also explains words that you think you’d know inside out in the context of information architecture. As someone who prefers having all commonly used terms defined clearly, watching the process unfold throughout the book was enjoyable.
For example, a channel transmits information. A commercial on TV and YouTube is accessible on two channels. Reading these two short sentences immediately cleared up my understanding of the word “channel” in this context.
Dense Ideas Made Simple
I admire the quick, succinct way in which the author communicates seemingly dense ideas. For example, I found the bit about user context interesting - how, when we attempt to build systems/softwares for a certain purpose, we must consider the state of mind the user is in, their most likely physical location, and what they are likely doing in the moment - that is, the “user context”. Based on these musings, we can add facets of design that optimise the use of the application to its target audience.
Similarly, the chapter on how a reader can add diagrams to their toolkits, so that they can deploy different strategies to visualise and minimise a mess is helpful. I suspect that I can use the Gantt charts and Mind Maps heavily. On reflection, it is pretty clear that diagrams do help picture a mess, but having this point in writing really reinforces it in my mind.
Mental Models and Requirements
I also like how there is an emphasis on the point that the mental model of an idea/feature is all powerful in determining how we understand new information in the context of this idea/feature - the more the mental models of stakeholders align, the more the software is true to its requirements.
By the way, the book defines strong requirements as a simple sentence with a noun and a verb - no extra frills, no getting into the ‘hows’ since that may give way to ambiguity. I really appreciate the simple, intuitive definition. It is like giving voice to something that I always knew but didn’t quite think about enough to articulate properly.
A Few Critiques
The book seems like it is written at a very basic level - but really, the concepts described here do apply to someone like me, a technical writer, who must make sense of (sometimes) contradicting inputs from multiple teams to write a coherent guide. Also, there is much utility contained in the list of potential measures one can put in place to check the progress of a project.
A slight objection to the writing style is that the author seems to think that the average reader is familiar with many situations that she describes in the book - sometimes, I stumble on an example or an illustration for a point, and wonder where it came from. The context behind some real-world snippet is elusive, and it confuses - much to the dismay of us aspiring sense makers. I also think some crucial parts of the book could have been explained better - for example, the definition of block diagrams does not really do justice to the inherent power of the tool.
Conclusion
In conclusion, I think this book is a good starting point for someone who is aspiring to complete large, messy projects. It reminds us that we must strengthen the base foundation and frame upon which we are building our structure — the structure that everyone sees, but most don’t think beyond.