Affordances and Signifiers
Not Just Semantics
I think the distinction between these two concepts is more than just semantics and looking around I really don't see many people understanding affordances when it comes to software design. All this talk of "buttons" drives me crazy. Here's a better definition and justification for the distinction.
An affordance is a result which you offer someone through an interaction with your product.
A signifier helps your user understand the affordance which you are offering.
The use and definition of the words "Affordance" and "Signifier" can be a point of contention amongst software designers, product managers, and design generalists. I'm offering an explicit distinction between them not to be contentious, but to help draw clean lines through the roles of product management and design.
We want our product managers to worry more about choosing the right affordances for our users and less about choosing the signifiers of those affordances, an area which good designers can be entirely entrusted. At the same time, we want our designers to understand that their job isn't to draw a button on the screen, but to offer the user an affordance.
A simple heuristic to determine whether you're discussing an affordance or a signifier is as follows
If X affords Y then Y is an affordance AND
If X signifies the affordance Y, then X is a signifier
Note that you must identify an affordance first in order to identify a signifier.
For example, the screen affords tapping the button, and tapping the button affords exporting the data. The affordance we discuss when designing our software is exporting the data. Unless a button is specifically required to signify such an affordance, we don't bother prescribing it (for example it's too prescriptive for a pitch in Shape Up). Apple's product management team on the other hand probably talks about the affordance of tapping on the screen.
Further reading: The Design of Everyday Things
On Long Pressed: Affordances and Signifiers
-Justin