Coaching a junior women's volleyball team taught me more about UX than any framework ever did.

I coach a junior women's volleyball team. We train twice a week, compete on weekends, and spend a lot of time figuring out why things that work in practice fall apart in a match.

Sound familiar?

People don't behave like process diagrams

The first thing you learn as a coach is that a drill that worked perfectly on Tuesday will completely fail on Saturday. Same players. Same exercise. Different result.

For a long time, I tried to fix this by improving the drill. Better instructions. More repetitions. Clearer structure.

It didn't help.

What actually helped was watching differently. Not looking for errors — looking for patterns. Why does Player A freeze at the net when the pressure increases? Why does Player B perform better when she sets the tempo herself? What's happening in the team dynamic when the score is close?

This is exactly what user research should feel like. Not validating assumptions. Observing what's actually there.

Different mental models in the same team

One player processes feedback best through movement — you show her, she tries, she adjusts. Another needs to understand the reason first before she's willing to change anything. A third shuts down completely when given feedback in front of the group.

Same information. Completely different receivers.

In UX, we talk about mental models as if users are a monolithic block. They're not. A 34-year-old family manager who checks her banking app at 11pm on her phone has a completely different model of "fast" and "helpful" than the 58-year-old who comes into the branch on Friday afternoons.

Designing for one means failing the other.

Feedback that actually lands

I used to give feedback immediately after a mistake. Direct, specific, well-intentioned. And mostly useless.

What changed: I started asking first. "What did you notice?" Often the player already knows exactly what went wrong — she just needs space to say it. When she articulates it herself, the correction sticks. When I tell her, she nods and forgets.

This maps directly to usability testing. The moment you interpret instead of asking, you lose the most valuable data. "Why did you click there?" beats "I see you were confused by the button" every time.

Psychological safety is not a soft topic

A team that's afraid to make mistakes stops taking risks. They play it safe, stay in patterns that feel comfortable, avoid the move that might go wrong.

This is how most enterprise software gets used. People click the path they know. They avoid the feature they're not sure about. They develop workarounds that feel safer than the actual workflow.

Psychological safety in a product means: users feel confident enough to explore. They're not afraid of breaking something. They understand what's happening. Error messages don't shame them.

That's a design problem, not a user problem.

Iteration during the game

A match is 5 sets. If something isn't working in set 2, I don't wait until next training to adjust. I change the rotation. I call a timeout. I shift who's talking to whom on court.

Agile product development says the same thing — but then ships quarterly releases and holds feedback sessions every six months.

Real iteration is uncomfortable. It means changing something before you have complete certainty. It means trusting the signal you're seeing over the plan you made.

The best coaches I've watched don't have better playbooks. They have better pattern recognition — and the willingness to act on it.

I didn't become a better UX thinker by reading more books about UX.

I became better by standing on the sideline, watching people who are trying their best under pressure, and learning to ask better questions about why things work when they do.