The Behavioural Evidence Check

You don’t need a research department.

You just need some signal.
Something to hold onto.

To do this we can use 4 filters:

1| Describe it

Can you clearly explain what the behaviour looks like in action, without using vague language?

Why it matters:
If you can’t describe it, you can’t design for it. General statements lead to general (ineffective) solutions.

Example:
❌ “People don’t like the tool.” → Vague
✅ “People skip the tool and use spreadsheets instead.” → Specific, observable

2| Seen It 

Have you or someone else directly witnessed the behaviour?
This could be through:

• Analytics
• User testing
• Observation
• Behavioural logs
• Playback sessions

Why it matters:
This confirms it’s not just an idea: it’s happening.

Example:
✅ “I’ve watched recordings, users drop off at the ‘Create Account’ page.”

3| Repeatable

Is this behaviour happening regularly, or was it just a one-off incident?

Why it matters:
You don’t design systems for rare behaviours. You design for patterns.
You want to solve repeat problems, not outliers.

Example:
✅ “Users have been dropping at the same point for 3+ months.”
❌ “It happened once during a demo.”

4| Any Evidence

This is anything else that strengthens your case, but might be less direct:

• Quotes from user interviews
• Survey comments
• Support tickets
• Team feedback
• Observational notes

Why it matters:

Sometimes, you don’t have hard data, but you’ve got multiple signs pointing in the same direction. It might not be hard proof, but it shows there’s smoke... and maybe fire.

Example:
✅ “Several support tickets mention the feature being confusing.”
✅ “Three teams flagged the same workflow issue in retros.”

If the answer is “no” to any of those, pause.
Don’t solve it yet. Go get clarity.

Example

Assumption:

“People don’t trust our checkout process.”

✅ Clear description?
→ “Users drop off after the price summary.”

✅ Seen it happen?
→ “Analytics shows 60% bounce rate on that page.”

✅ Repeatable?
→ “Trend’s held steady over three months.”

✅ Data?
→ “User tests show people worry about hidden costs.”

✏️ DO IT NOW

3-Minute Check

Take your behaviour from the previous lesson.
Now run it through the checklist above.

• Can you describe it?
• Have you seen it?
• Does it happen regularly?
• Do you have even rough evidence?

If anything feels shaky, pause.
Don’t polish a maybe.

Either:
Go find proof.
Or change the behaviour.

Flash Recap:

• You don’t need a lab, just signs that it’s real
• Don’t design around assumptions
• Real behaviours leave evidence
• Validate before you act, or you’re gambling, not designing

What’s Next:

You’ve validated the behaviour. But is it new, or part of a deeper pattern you’ve seen before?
Let’s look at its history. Because past behaviour isn’t just a clue, it’s often the cause.