Editor’s note: Since writing this column, Steven has done additional user research and has updated his design guidelines for mobile phones accordingly. Read his latest column on this topic: “Design for Fingers, Touch, and People, Part 1.”
As UX professionals, we all pay a lot of attention to users’ needs. When designing for mobile devices, we’re aware that there are some additional things that we must consider—such as how the context in which users employ their devices changes their interactions or usage patterns.  However, some time ago, I noticed a gap in our understanding: How do people actually carry and hold their mobile devices? These devices are not like computers that sit on people’s tables or desks. Instead, people can use mobile devices when they’re standing, walking, riding a bus, or doing just about anything. Users have to hold a device in a way that lets them view its screen, while providing input.
In the past year or so, there have been many discussions about how users hold their mobile devices—most notably Josh Clark’s.  But I suspect that some of what we’ve been reading may not be on track. First, we see a lot of assumptions—for example, that all people hold mobile devices with one hand because they’re the right size for that—well, at least the iPhone is.  Many of these discussions have assumed that people are all the same and do not adapt to different situations, which is not my experience in any area involving real people—much less with the unexpected ways in which people use mobile devices. Read More
Digital products are about content. Even if you think they’re all about interactivity, controls are pointless if users don’t understand their purpose and cannot read about what they do. The most important thing you can do to make a Web site or app usable is to make sure everyone can read its text, on every device, under every condition.
Units and Conversions
First, let’s define some terminology. People often use the term font incorrectly these days. Technically, in the modern world, a font is a digital file containing a particular typeface. In this column, I’ll be using the term type when referring to the characters that make up printed or displayed text—including the content, the font or typeface, and its size and color. Read More
A common complaint about bringing UX designers onto a project team is that they waste time creating design artifacts. This is purportedly antithetical to modern development methodologies that value code over process.
However, this is not my experience at all. I’m not arguing that creating design artifacts is all that design is about. I default to fairly light documentation myself—and not one in 100 project teams or clients wants as little design documentation as I would typically provide by default.
One of my more common jobs is to improve or replace the design for an existing product for a client. All too often, these projects have no historical documentation of any value, which frequently causes projects to take months or even years longer to build.
Good documentation allows consistency in design and execution and serves as institutional knowledge for organizations. It enables us to remember what we’ve built and why, to check reported bugs and new feature requests against the documentation, and to more quickly react to necessary changes or updates. Read More