One of the tenets of the Office 12 user interface is that we don't want people to have to look "under rocks."

I don't know why we say "under rocks."  Maybe I made it up, maybe I heard it somewhere, who knows.  The picture I get in my head is an insect-eating animal crossing the land, turning over rocks to look for meals.  Occasionally, a rock will be hiding a juicy insect.  Most times, however, there's nothing under the rock.  As a result, the animal spends most of his day looking under rocks.

In a user interface, a "rock" is anything you have to click to see what's under it.  The more rocks you have to look under, the harder it is to find what you're looking for efficiently.  When you have a UI with a lot of rocks to look under, people start to feel like your program is very complex.  It's like the shell game--people start forgetting what rocks they've looked under and which they haven't.  Eventually, people give up ever looking for new things and instead just use the same three rocks they always use.

As you add more features to a product, the tendency is for the number of rocks to go up.  Yet, the more rocks there are, the less likely people are to explore them.  This is a hard issue to solve.  Here are some of the steps we've taken in Office 12 to help people look under fewer rocks:

  • The Ribbon is the starting point for all functionality.  Unlike the old system, in which you had to look under short menus, long menus, toolbars, hidden toolbars, the Task Pane stack, all commands in Office 12 start in the Ribbon.
     
  • Everything gets a label, especially dropdowns.  If you can keep someone from turning over a rock by giving that rock a good name, then that's a huge win.  You don't ever have to open up a can of Sprite to know what's inside it.
     
  • Use specific labels.  Engineers love to name things "Tools" or "Options" or "More" or "Advanced."  This is just like putting a "Turn Me Over" sticker on the rock--the name is so ambiguous and yet so promising that people are going to turn it over every time.  A label for a menu like "Import Data From" is never going to take a click from someone looking for Word Count.
     
  • Contextualization!  I've made the case for contextualization already, so I won't bore you again here.  But contextualization simplifies the core experience by only showing the rocks that are capable of having insects under them.

Looking under the rocks that are left is less inefficient if there's a clear route for the user to follow from the first one to the last one.  Think of 100 rocks lined up in a row vs. the same rocks scattered in a random pattern.  In which case could you look under all 100 rocks faster and be assured that you looked under all of them and didn't forget any of them?  We designed the Ribbon to be the single home for functionality and to have a built-in, simple scanning pattern (chunk to chunk, tab to tab.)  It's finite and you know when you've seen all the rocks.

It's impossible to eliminate all the rocks from all but the simplest products, and of course there are always trade-offs.  But in Office 12, we've tried to be hardcore about resisting the urge to generically categorize or to invent multiple ways to access the same feature.

One of the questions we always challenge ourselves with is: "are we just creating another rock for people to look under?"