From Pain Points to Opportunity Briefs

Journey maps, service blueprints and ecosystem maps each surface pain points from a different vantage point. A journey map exposes friction in a single user’s path towards a goal, stage by stage (Gibbons, 2018). A service blueprint adds the people, technology and processes behind the scenes, showing where a customer-facing failure actually originates in a backstage handoff or missing process (Gibbons, 2017). An ecosystem map steps back further, showing how multiple services, organisations and stakeholders interact, useful when a pain point cannot be explained by looking at one journey alone (Grimes, 2019). Kalbach (2020) frames all three as complementary: choose whichever map, or combination, matches the scope of the problem ay hand, then read pain points off it as evidence rather than opinion.

A well-run mapping session produces more pain points than any team can act on. Affinity mapping is a practical way to bring order to this: related observations are clustered into themes, so 20 or 30 individual pain points on sticky notes become a handful of clear patterns a team can discuss and prioritise together (Krause and Pernice, 2024). Once clustered, each pattern can be scored rather than argued over. A simple prioritisation framework can then be applied to the resulting themes. One common approach is to assess each theme against three criteria: severity, frequency and business impact, each scored on a 1-5 scale and summed for an overall priority score. How bad the moment is when it happens, how many people hit it, and what it costs the organisation to leave unresolved (Allen, 2026). Scoring individually before discussing as a group helps stop the loudest voice in the room deciding what gets fixed first.

The clusters that score highest are opportunity areas: not the pain point itself, and not a solution, but a defined space worth designing against. Getting that space right matters. Too broad, such as ‘improve onboarding’, gives a design team nothing to grip; too narrow, such as ‘fix this button’, risks missing the upstream cause the blueprint actually revealed. An opportunity brief is the document that carries a chosen opportunity area from research into design work. Its purpose is to give a design team everything it needs to start without re-running the research: what the opportunity is, why it matters, who it affects and what a good outcome would look like, so effort goes into designing rather than re-establishing the evidence.

A useful opportunity brief covers a small set of fields. The opportunity statement names the problem and who it affects, written from evidence rather than assumption. An evidence summary lists the map, data and research behind it, including the prioritisation score. Affected users and stakeholders record whose experience is involved, staff as well as customers, since a service failure is rarely one-sided. A success measure states what should change if the opportunity is addressed well. Scope and constraints mark the boundary of what is and is not included, so a brief does not quietly expand mid-project. Known risks and assumptions flag what still needs testing, a structure close to the opportunity brief fields used in product and service teams more widely (Productfolio, 2021).

For example, a blueprint for renewing a professional certificate might show applicants repeatedly phoning a support line because a status update never arrives online. A brief built from that evidence could read: Opportunity, applicants cannot see where their renewal stands, driving avoidable phone contact. Evidence, 40% of support calls relate to status queries, and the blueprint shows no customer-visible touchpoint between submission and outcome. Affected, applicants awaiting renewal and the staff absorbing the call volume. Success measure, a fall in status-related calls. Scope, status visibility only, not the wider renewal process. Handled this way, a brief keeps the line from mapped evidence to finished design intact, so what gets built is what the map actually showed.