Affordances and signifiers in software design and development
An udpate to this post can be found here.
We’ve had a software development team in our organization using Basecamp and Shape Up to plan and execute their design and development cycles for about a year now. I’ve never really been directly involved in this team’s work but at the end of every cycle I still join their “Sprint Review” (term left over from past Scrum days) and observe the work that was completed. I’ve successfully delivered products via Scrum but was never particularly keen on the approach. I’ve never really liked the arbitrary nature of story point estimates, and always felt as though the backlog and any accompanying documentation for the products looked more like an overflowing graveyard than anything else. Particularly discouraging is the fact that I like to write, and key aspects of my complete thoughts and ideas were seemingly lost when the team split them into stories and tasks into the backlog. Recently, I had an opportunity to begin work with a new team, and I wanted to try the Shape Up approach. Both of the teams I currently lead, feeling the same about our not-quite-scrum approach, were happy to try something new, so we switched.
Switching meant reading Shape Up, which I highly recommend. Ryan Singer effortlessly describes his product development process at Basecamp in words that anybody can understand. He creates a new paradigm and language to match, called Shaping, centered around setting boundaries for projects via Appetites and Cycles, providing just enough fidelity for the team by Breadboarding, and writing thoughtfully about the problems that need to be solved via the Pitch. Our first cycles are already underway and I’ll publish another article about my experiences when they finish and I’ve had time to reflect.
When I was reading Shape Up, there was one key aspect of Ryan’s approach, in breadboarding, that I have always generally felt was a source of confusion for software designers. About a month ago I even noted on Twitter, at the top of my list of 100 opinions about product development that I decided to fire off
Affordances are NOT buttons that you can click. The fact that you can click is an affordance. The button is a signifier, it tells the user where to click, not that they can click
I brought this up again to Ryan directly on Twitter after reading something out of Shape Up describing key aspects of Breadboarding
Affordances: These are things the user can act on, like buttons and fields. We consider interface copy to be an affordance, too. Reading it is an act that gives the user information for subsequent actions.
We had a thoughtful conversation on Twitter that even resulted in several other disconnected threads going back and forth about our conflicting definitions. While I felt as though Ryan is far more informed than I am regarding the origins of these words and their uses in industrial design, I also felt as though drawing clear distinctions between these terms can provide more value to the Shape Up process than is currently described. Going to the tweet you can see the full thread and some of Ryan’s responses. (He later retweeted his own response where we continued the conversation)
My view on affordances comes from Don Norman’s The Design of Everyday Things, a book I’ve written about previously and one I highly recommend for those looking to understand the language of design. In the book Don Norman says quite explicitly
How could designers describe what they were doing? There was no word that fit, so they took the closest existing word — affordance. Soon designers were saying such things as, “I put an affordance there,” to describe why they displayed a circle on the screen to indicate where the person should touch, whether by mouse or by finger. “No,” I said, “that is not an affordance. that is a way of communicating where the touch should be. You are communicating where to do the touching: the affordance of touching exists on the entire screen: you are trying to signify where the touch should take place. That’s not the same thing as saying what action is possible.”
So we have a conundrum because in Shape Up, we need language that describes the affordances we’re offering our users, and because we need to speak about these things abstractly during breadboarding without prescribing the actual design, I propose that we stick with Don Norman’s definition using a simple formula to identify our affordances and differentiate them from our signfiers.
If X affords Y, then Y is an affordance
Let’s first look at physical buttons. The physical button affords pressing, then pressing is the affordance. How is that different than a software button? Well, does a software button afford pressing? No, a mouse or a touch screen might afford pressing though. In the context of those physical devices, pressing is an affordance. A software button on the other hand might afford submitting a form. The form submission, then, in the case of the software button, is the affordance. So what is the software button? The software button is the signifier that we place on the screen to help the user understand both the affordance of tapping or clicking, as well as the affordance of form submission.
Now, this doesn’t mean that we can’t design signifiers while shaping. In Ryan’s example of the Dot Grid, a brilliant solution to the problem of quickly knowing when something can be scheduled without implementing a full calendar, part of the solution was in fact the signifier. Little dots on the squares of the grid that signified the affordance — the ability to schedule an appointment on this day.
With this distinction, we can take our breadboarding to another level, when we talk about the affordances offered by our application, we don’t need to prescribe the signifiers that our designers will choose to indicate them to our users unless it’s a key aspect of the proposed solution.
