A door handle can make pulling possible for someone able to grasp it. Whether that person recognises that they should pull is a related but different question. The first concerns an affordance; the second concerns the cues that communicate how the door works.
In interface design, “affordance” is often used loosely for those cues. Don Norman’s discussion of affordances and design helps distinguish possible actions from perceived ones. The distinction is useful because a control can function perfectly while giving people little reason to discover it.
Separate the action from its signal
A row in a table may open a detailed record when selected. Its shading, label, pointer behaviour, or chevron can signal that action. If the row looks like static text, people may never try it; if every row looks interactive but some are not, the same visual signal becomes unreliable.
A drag handle similarly communicates where dragging is expected, but the interaction must actually support the intended input. A visible cue does not make an operation available to someone using only a keyboard. That requires an accessible way to perform the action.
This is why the relationship includes the person and their circumstances. What one person can operate, perceive, or recognise may differ from another’s experience. Accessibility belongs in the analysis of the action, not just in a later review of its appearance.
Observe discovery without teaching the control
Give participants a goal that requires the action, then watch what they attempt. In an illustrative table study, ask them to check the details behind an unfamiliar charge rather than telling them to click the row.
A first-click test can investigate the initial destination people choose, while a fuller usability test can show whether they complete the action and understand its result. Ballpark’s first-click testing supports the former kind of focused question.
Ask about expectations after the attempt where possible. Explaining the interaction first and then asking whether it seems clear measures the effect of the explanation as well as the design.
Make the result understandable too
Discovery is only part of the interaction. After selecting a control, people need feedback that shows what happened and whether they can recover from a mistake. A row that opens a record should make the new context clear; a destructive action needs appropriate safeguards.
When a control fails, identify whether the problem is availability, discovery, interpretation, or feedback. Those distinctions lead to more useful changes than asking the team to make the interface look generally more clickable.