Philip Haine’s articles on Product Vision, Innovation and Design

User Interface Friction

UI friction needlessly wastes the user’s energy on delays and busywork.

“User interface friction” refers to the wasteful delays in the UI or needless overhead work in managing it. User interface friction can take several forms:

  1. Palettes that must be painstakingly re-arranged to get them off the content area (hello Photoshop and many others). When switching display configurations, the user must get all palettes placed appropriately before doing real work. We would like to see systems recognize common monitor configurations and intelligently partition a display into tool areas and content areas. When switching between, say, a laptop screen and a 24″ display, the user should be able to plug in and work without having to reconfigure the workspace.
    Vision to steal: This should be supported at the OS-level, for two main reasons: 1. For cross-app consistency, so the user can get used to finding tools at the right or left of the screen across all applications. 2. So the system can referee window positions and sizing. For example, on the Mac a maximized window knows not to extend under the Dock, so it’s scrollbar and resize handles remain accessible. See also: Making efficient use of big displays.
  2. Often-clicked buttons that are too small and hence difficult to target and click (hello Fitt’s Law). Examples of this abound. In GarageBand, for example, the user must often mute and isolate audio channels, yet the buttons to do are tiny:

    The principle is straight-forward: if the user must click a button frequently, make it big. (Resistance may be expected from visual design quarters: tiny text and controls look cooler, especially surrounded by massive whitespace.)

  3. Unnecessarily modal UIs that require you to put the system in the right state before being granted access to an important function. Try turning down a blaring iPod when it’s in its protected sleeve with the lock button on. Worse: try turning down Nine Inch Nail’s latest while you are navigating the menu structure. The very cool scroll wheel cannot be used as a volume control until you first navigate your way back to the current song. Better to just yank out those earbuds.
    Compare this against a 20-year-old Walkman: its physical volume dial can be adjusted without even having to de-holster it from your cargo pants. (The upcoming iPhone mercifully brings back physical volume buttons. Apple may have clued into this UI issue.)
  4. Gratuitous up-front animation. A Windows XP user wanting to use a menu must first wait for it to fade in. This behavior has reportedly gotten 20% worse under Vista. Mac OS X is not immune: dialog boxes slide down from the titlebar with lovely acceleration and deceleration motions. The taller the dialog, the longer the slide. [Anyone know how I can hack this to make it stop?]
    Before complying with the user’s request to leave, Clippy the insolent paperclip would sarcastically wave Buh Bye. (The stupid bent wire knows that such cloying anthropomorphisms are what did him in to begin with.)
[Update 8/6/08 This problem with up-front animation slowing the user down is rampant.  It's typically associated with attempts to look cool.  The iPhone 2.0 software has lots of it, eg. in stepping from day to day in the calendar, or launching and exiting apps.]

People crave and buy ever faster machines for responsiveness. Yet these up-front animations want you to chill out, take life a little slower. We’re not opposed to elegant animations, but they need to be on the tail end of the user’s operations. The simple principal is: whenever productivity matters, UI elements should snap to attention when called upon but may fade away gently once the user has moved on to something else.

The moral of the story is: when architecting systems, take a moment to isolate the most common and frequent tasks; think of the most efficient theoretical interface to these core tasks and keep comparing your design to this theoretical best. Beware of design solutions that introduce delay or overhead in these core tasks and eliminate this UI friction

Question for readers: what productivity apps have the best palette management UIs? How are Microsoft’s new tool ribbons and Adobe’s new palettes working out?

See also:

Posted by Philip Haine on Tuesday, February 27th, 2007 at 1:25 pm.
See similar articles in: Analysis, Critique, Designs to Steal.

2 Responses to “User Interface Friction”

  1. Philip Haine wrote on April 19th, 2007 at 10:03 am :

    Here is another article about UI friction, that discusses Apple’s Front Row as a bad example and the Palm Pilot as a good example.

  2. Kevin Mullet wrote on August 6th, 2008 at 1:25 am :

    Another great example is the unfortunate Office “Ribbons” vs. the time-tested menu bar. Try getting a quick overview of your application functionality (as you could when “wiping” across the menus with the mouse) using the Ribbon. Now THAT is UI friction. Another great friction example from the Ribbon: Find the Save As command.

    As I predicted there is now an aftermarket product to put the menus back:

    http://www.addintools.com/english/menuoffice/

Leave a Reply