WWDC 2017: Designing for Everyone

If I had to guess at an unofficial theme for this year’s WWDC, it would be “Designing for Everyone.” In addition to being the name of an actual session (806: Design for Everyone), the phrase captures the main thrust of what many of the other sessions were about as well. More than one presenter mentioned that while accessibility wasn’t a primary focus when re-designing some of Apple’s first party apps for iOS 10, it became a priority for iOS 11. One presenter (I can’t remember who) admitted that her team still had plenty of work to do on the accessibility front.

The session 802: Essential Design Principles reminded me of the best book I read in grad school: Donald Norman’s The Design of Everyday Things. Apple Design Evangelism Manager Mike Stern outlined many of the same principles that Norman discussed in his book—things like natural mapping and affordances.

In Chapter 2 of The Design of Everyday Things, there’s a little box with questions that designers should ask about their design:

How easily can one:

  • determine the function of the device [or in our case, an app or feature]?
  • tell what actions are possible?
  • tell if the system is in desired state?
  • determine mapping from intention to physical movement?
  • determine mapping from system state to interpretation?
  • perform the action?
  • tell what state the system is in?

(Norman, D. A. (2013). The design of everyday things. New York: Basic Books, a member of the Perseus Books Group.)

The questions are based on seven stages that humans go through when taking an action. When people use our apps, they have a goal in mind that they want to accomplish. They should be able to figure out what actions are available, which ones will lead them to their goal, and how to execute said action(s). Ideally, they should be able to do this without any additional walkthroughs, on-boarding, or tooltips.

They should also be able to accurately predict and evaluate the outcome of their actions. This can be achieved using things like error/success messages, animations, button state changes, view transitions, etc.

An app’s design should clearly communicate what you can do with it. Can you toggle a switch? Press a button? Scroll up and down? All of those things are called “affordances”—things the app allows you to do. 3D Touch is tricky because one of the affordances of a flat piece of glass is NOT that you should be able to exert pressure downward “into” it. Rather, glass, as a material, affords swiping and tapping by its very smooth, flat nature.

AirPods are another example of hidden affordances. Can you tell by their design that you can tap on them to execute additional functions? No. That’s traditionally considered bad design.

State changes are also important. What state is your app in? Is it syncing, or loading something? If you are using a tabbed interface, is it clear which tab the user is currently viewing? These questions are integral to making sure your design is accessible for everyone.

I’m planning to spend the next few weeks updating Nebraska93’s design to be compatible with Dynamic Type. A few days ago I tweeted a video of my successfully re-designed table view cells and I’m really surprised by the amount of favorites and retweets it got. A few people remarked that they didn’t know Accessibility Inspector could adjust Dynamic Type settings on the fly.

My advice to fellow devs is twofold. First, open up Accessibility Inspector and see how your app looks to people who have low vision. Off-hand, I can think of three people that I know in real life who use the larger text size settings, and I suspect it might be way more common than you might think. Second, read The Design of Everyday Things. It’ll make you really mad at a lot of doors and household appliances, but it’s worth it!