Summary: The best way to approach "design" is through contextual inquiry to gain a deep understanding of the immediate, physical context in which work will be done.
In part I of our “Built to Last” series, we talked about the power of contextually concise models to help stakeholders understand a project. But in our experience, the journey to the creation of those models is almost as important as the models themselves. Many projects, particularly those where there is pressure to deliver relatively well-realized requirements at a project check point, can generate results that aren’t in alignment with the core framework and identity of an organization.
It’s not surprising if you take a moment to think about it. Any model or requirement specification is an abstraction of a complex world. If that abstraction doesn’t lean on the actual language and operations in organization for its context, it may seem like distracting nonsense or meaningless cliche.
The Understanding Group tackles this problem by bringing the client along in the discovery process, as opposed to working in isolation and producing a final deliverable.
At the core of this approach is the first step of contextual inquiry, as outlined by Hugh Beyer and Karen Holtzblatt in their seminal work “Contextual Design: Defining User-Centered Systems.”
Contextual Design, by Beyer and Holtzblatt
I am a true believer in the power of contextual inquiry, because in fifteen years of developing software, I have never seen any methodology have as big an impact on the success of a project.
Contextual Inquiry for the WIN
Contextual inquiry uses the following principles:
Expose concepts and thought process by following actual work.
Create loosely organized themes based on that work.
Use many preliminary models to confirm alignment and understanding.
Make a promise of formality and integration after a baseline of understanding has been established.
The ideas behind contextual inquiry deserve more time and attention than this blog post. But in short, the approach assumes that the best way to approach “design” (in this sense, the design of a piece of software) is by having a deep understanding of the immediate, physical context in which that work will be done.
At that point, the findings, which are identified as major trends or patterns that facilitate or hinder work, are collected and organized in a process called Consolidation and Affinitization, where the findings for individual users emerge as major themes or ideas. This work is very hands-on, and often uses diagrams, drawings, note cards, and the placement of those cards in stacks, preferably in a room.
The client is heavily involved in this process from the beginning, and is invited to see any of the notes or findings as they evolve. This creates a feedback loop between the discovery team and the client that makes the language and common understanding more robust. These findings are then organized into major emergent themes and shared with the client.
In addition to findings from contextual inquiry, this stage also creates a number of “dumb models” as intermediate deliverables that convey other ideas or concepts. Based on this effort and the client’s feedback, we lay a marker promising formality and integration in a subsequent phase.
Why Does This Work?
I’ve spent a lot of thought on why this approach seems to work so well relative to other methodologies I’ve seen. It boils down to four factors, in decreasing order of importance:
All work happens in a physical place, and that space must be understood.
The requirements are simple enough and transparent enough that there is osmosis and cultural assimilation during the project without the pressure that exists around formal documents.
Contextual inquiry forces a project to include planning and research.
A company that is willing to make the additional effort to do contextual inquiry is more committed to a project’s outcome.
I almost didn’t include the last one, because anyone who has been on a requirements-heavy waterfall death march knows that the willingness to throw money at a project is a pretty minimal requirement, but it is a requirement nonetheless.