The Evolution of Impact Mapping

In need of inspiration? Check out our lectures!

The original idea was to give project teams and business managers a technique to explore, discuss and evaluate the impact of a digital service, impact to users and to the business at hand. We were dead tired of business and project managers making priorities based on project cost and skipping evaluation during the early project lifecycle when there was still time to do a better design.  

We soon came up with the basic concept that the Impact Map should give a clear way of reasoning from solution to desired impact and must explain how this impact is generated in use. Thus, the Impact Map was constructed with three levels:

• Impact – the difference that this service brings to the business and its organization.
• Use – needs and behaviors that the service could satisfy.
• Solution – the capabilities that satisfy user needs.

We knew in our hearts that design and development must be based on impact, not features. But how to define impact in a way that can be a solid ground for design? And to support evaluation of prototypes and solutions? I remember us having a three-day (!) intense discussion on whether the User layer should be constructed of actions, situations or needs. 

Best suited for prioritization

The key insight was that the User level was the level best suited for prioritization. Prioritizing some needs more than others makes it clear how the desired impact can emerge, thus giving a great foundation for design and evaluation. Still we had two alternatives: grouping needs into users that were prioritized, or prioritizing needs without grouping by users. We realized that going directly to needs would usually result in a long list. And we did not feel convinced that the technique and model would be useful if the concept of User was omitted. 

In our first descriptions of the Impact Map, we used the concept of: 

• WHY – the impact for business as the result of this service (Impact level).
• WHO – the needs and behaviours that users have (Use level). 
• WHAT – what we will build in order to satisfy users (Solution level).

Unfortunately, when people tried to do Impact Maps, the Use level often ended up being demographic groups. Describing users as “young adopters”, “subscribers”, etc., is an established way for clients to talk about users—marketing, IT and others will understand those. The problem with demographic descriptions is that they do not give guidance when designing and prioritizing. One demographic group often has the exact same behavior as another demographic group. 

Three levels

Soon enough, we understood that the concept of HOW is what was needed, to make every effort to in depth understand and describe how users think, act and behave. This is, in essence, the same concept as Simon Sineks’ “The Golden Circle”. 

The structure for Impact Maps is therefore the three levels: 

• WHY – why this service is meaningful to invest in, the impact for business (Impact level). 
• HOW – how users think, act and behave in situations where the service is present, grouped and prioritized (Use level).
• WHAT – what the solution must provide to users (Solution level).

By expressing Users as behavioural patterns, the Impact Map gives an excellent foundation for innovative user experience design and project management based on impact. It makes it possible to find new solutions to well-known problems. It also reveals business opportunities for needs that have been underserved.

In need of inspiration? Check out our lectures!