Flaky Goodness

User Intention

January 20, 2013

My father is vexingly difficult to shop for. I think that every brilliant gift idea I've had over my adult life has either been immediately returned or is still sitting on a shelf somewhere. I remember asking him once what type of camera he wanted, and his response was essentially this: small enough to fit in his pocket, and with a single button. But that one button has to take the perfect picture, with the perfect composition, exposure and color balance, every time.

This serves as a pretty good description of the ideal user interface: one button that does exactly what you intend. As software designers we can't ever quite get there, but we have ways of getting closer.

Limiting scope

The less a product does the simpler the interface can be. The stock Camera app on the iPhone has far fewer controls than my Nikon D7000, simply because it does less.

Making decisions instead of providing options

There will always be those of us who want to shoot in Manual or Aperture Priority to express our artistic vision and eke out the best result in any circumstance. But most of the world would rather shoot in Auto. A well designed Auto mode, one that minimizes the downside of giving up all that control, is a design win.

More controls than my car

More controls than my car

Asking the right questions at the right time

If full-Auto gets you 80% of the way there, it might be possible to get to 90% by exposing just a tiny bit of UI-complexity when absolutely necessary. A subtly blinking flash icon when the ambient light is too low, for example, or a similar HDR button when the sensor detects a very high dynamic range in the scene. It might be overkill to have these controls visible all the time, but they might make a big difference if presented conditionally.

Abandoning UI abstractions

As developers we refuse to accept that most of our userbase will never fully embrace the conceptual abstractions that we take for granted and depend on every day.

Modes. Hierarchy. Aliases. Virtual or "smart" collections.

We fool ourselves into thinking that because some of our users are able to use some of these things some of the time, they must understand them and like them. But really, the lion's share of our poor userbase has often just learned the steps or actions to accomplish their tasks without ever understanding what's happening under the hood. And at the first sign of trouble, they'll get lost, confused, and possibly angry.

Doing these things is hard, especially when you're building a product that was originally designed to scratch your own itch. And for every example of a design that takes this advice to heart, there are critics, detractors and disillusioned former fans who jump ship for a more advanced and customizable approach. But this tension between simplicity and power is where software design lives.