Navigate back to Articles page
Read first: Build the Right Thing with Impact Maps
A substantial amount of work done in information technology, the work in our personal lives, the work in other disciplines and domains — can be described simply as problem solving. A particular solution will fix a particular problem or achieve a particular goal.
There is a lot between those ends. There are many opportunities to get it wrong. Much of what prevents or hinders solving problems is assuming a particular solution will result in the desired effect.
An assumption is dangerous in three ways: They can be unexamined, unproved, or unshared.
Unexamined
First, an assumption is unexamined when it is undefined, unclear, or misunderstood. Assumptions can start to be addressed when they are written down.
Use impact maps to expose the assumptions between the problem space and solution space. The assumption is that a particular problem is solved by a particular solution. In an impact map, every deliverable is an assumption against its corresponding impact.
Problem space
- Goal
- Actors
- Impacts
Solution space
- Deliverables (are assumptions until verified)
- Experiments
Unproved
Second, an assumption is unproved when it is not verified that the cause will achieve the desired effect. Research helps to test hypotheses by asking questions, gathering evidence, and analyzing findings. If the hypothesis is proven wrong, adapt and test again. If it is proven right, the hypothesis is verified, and the team can move forward in confidence.
Use impact maps to list and prioritize the experiments that should verify a particular deliverable will result in the desired impact. In prose, ask:
We assume [deliverable] will result in [impact]. We will know this is true if [experiment] results in [outcome].
Unshared
Third, an assumption is unshared when it is not widely known. This breakdown easily happens across disciplines. For example, a designer may hand off a sketch of an interface to a developer. That sketch may include a button that behaves in a certain way that may be obvious to the designer and other designers, but it may not be obvious to a developer. Inevitably, a detail is overlooked which may have been caught earlier in the process. This may cause negative effects on the team or even on the end user experience.
Use impact maps to share and collaborate with the team and stakeholders, so everyone can work together to discuss and manage these assumptions.
Conclusion
As problem solvers, we need some way to define unexamined assumptions, test unproved assumptions, and communicate unshared assumptions. Impact maps help us achieve all these things. When we use impact maps, we can more confidently know that a particular cause will result in the desired effect.
