The Evidence Map | User Interview Fundamentals. Acceptable Patterns

Interviews produce conversation. Decisions need evidence. The bridge between them is the Evidence Map, a structured artifact with three components that translates raw conversations into something engineering, design, and leadership can act on.

The Three Components

1. Who They Are

Not a full persona with hobbies and favorite colors. A focused characterization of the attributes that make this user type relevant:

Role and team context
Tenure with the product
Usage patterns (frequency, features used, recency)
Secondary attributes that produced meaningful variation (company size, platform, geography)

2. What Problem They Have

This is the component most teams underinvest in. It requires:

Problem severity, does it change behavior? Cost time? Money? Emotional energy?
Alternatives and workarounds, what are users doing today to cope?

3. What Success Looks Like

How would users know the problem is solved? Include both:

Goals, what would change in their workflow? What metric would improve? What emotional state would shift?
Non-goals, what will this explicitly NOT address? "This onboarding improvement will not cover enterprise SSO configurations."

Non-goals are scope control. Every feature becomes a kitchen sink without them.

Building an Evidence Map from raw interview notes

Raw note

"Participant said tracking compliance is a nightmare. She forwards training emails to herself as reminders and has a spreadsheet she updates manually every week."

A participant describes an elaborate workaround using Google Sheets and Slack reminders. What does this tell you?

Users will accept any solution, since their current one is clearly broken.The problem is real and painful. Your solution needs to beat the workaround on dimensions the user cares about.Users prefer spreadsheets over purpose-built tools.The problem exists but isn't very painful, since users found a way around it.