I was going to call this post, “Thinking the Unthinkable about Microsoft,” but what I’m going to say isn’t really unthinkable. In fact, I’ve thought it several times in the past four years, starting with Office 2007 and the introduction of The Ribbon as a UI element and continuing on through Kinect, and Windows 7 Mobile. What I’m thinking is namely this:

Microsoft is doing some good design work, particularly interaction design work.

I know, right?

Let me preface this piece by saying I’m mostly an OS X user, with occasional forays into Windows 7, which I don’t particularly like. I use MS Office just like most of the planet, however.

What prompted this post was a post on the MS blog about adding The Ribbon to Windows 8 Explorer. It’s a fascinating piece, and kudos to Steven Sinofsky and Microsoft for publishing it. We so seldom get to see design decisions as they are being made and the data—data!—that is being used to make them. Can you imagine Apple or even Adobe doing this? Me neither.

Of course, it being Microsoft, there was an immediate slam that quickly spread around the interwebs. The gist of the criticism is that Microsoft’s own data is showing how their new design is stupid. First, some quick background:

I know a lot of people hate The Ribbon as a UI element. It definitely took me a while to get used to it as well. But if you watch Jensen Harris’ The Story of The Ribbon or read the Office 2007 blog (recommended), it gives you an idea of the kind of constraints they were working under and their reasoning for creating for The Ribbon. Working on software with an established user base in the hundreds of millions is no easy task. Add to that organizational pressures, the hundreds of features you need to include because of business and power-user requests/demands, and you have a difficult design challenge, the likes of which most designers will never face. Hell, most designers within Microsoft didn’t fully address the challenges Office presented, which is how we got Office 2003. It’s a significant challenge, and if you don’t think so, try redesigning MS Word yourself, given what you know about the internal constraints. And then present your radical redesign of a company cash cow to Ballmer and Gates. Most of you would wet yourselves in response. I contend that The Ribbon was a bold, excellent response to the challenges of Office. I’d be proud to have it on my resume.

Now, whether The Ribbon is a good choice to use within the operating system and not within the suite of Office apps (where it was designed to be) remains to be seen. Sinofsky says in the article they explored other UI means, but eventually settled on the Ribbon as the way to go.

Now back to the data. Microsoft anonymously collects user behavior data, which can be illuminating. It basically helps determine what goes into the Ribbon on any given screen. Note that I said helps. Because here’s the thing about data: it can’t design for you. You need a human being—a designer—to interpret the data, and then place it into context. The data needs to be made meaningful, which sometimes means ignoring it.

Ignore it? WTF! Why would you ever ignore data? Here’s the simplest example: most online advertising isn’t clicked on. If you get a .5% clickthrough rate, you’re often doing very well. So should we remove all online ads, since they are so seldom used? 99.9% of users think so (the other .1% of people work for advertising agencies). But getting rid of advertising for some sites would mean basically getting rid of the site itself. Would you like Google to go away? You can’t listen to the data because the data doesn’t understand the overall context: the business and organizational environment and the user base as more than numbers on a spreadsheet.

There are plenty of reasons why a designer wouldn’t just make all the highest-use items visible:

• You’re trying to increase the use of a feature. Some features people clamor for are buried and thus have low usage. Bringing them forward and making them more prominent is a way of encouraging greater use.
• You’re helping power users. A tiny sliver of your audience might be power users, so overall, it looks like the usage percentage is low. But those power users really need that feature and will scream bloody murder if it is hard to get to.
• Clustering the same kinds of commands together. Probably almost no one uses a command like Paste as Hyperlink, but users wouldn’t be wrong to expect Paste as Hyperlink to be near Paste.
• A feature is part of a workflow. Occasionally, several commands will typically be done in a sequence. For example, scaling after importing an image. Now, users might not scale every time (and thus the use data is lower), but a good designer will know the flow regardless of what the data seems to be saying and design for the flow.
• You’re introducing a new feature you think people will like, but there’s no user data for it yet.

In short, data can be misleading and needs human interpretation. It can be a mistake to do a one-to-one mapping of high-use items onto the home screen. If you don’t believe me, look at Office 2003, because that’s the solution they tried there. You can end up with cluttered, non-sensical screens that (especially your power) users will hate.

Note that this is not to say that data cannot be misinterpreted by a designer, sometimes willfully so. (See my talk How to Lie with Design Research for helpful tips on manipulating data.) Designers are all too human and make mistakes too.

But before you look at behavioral data mapped to a UI (which is an amazing giveaway in the first place) and make judgements about how the data was utilized, realize you’re only seeing part of the picture. What you’re missing is the constraints, a knowledge of the users, and the organization and product history that a designer will bring to bear on the problem. Designing with data should mean using data as an input to your decision-making, not as the decider alone.