Welcome back. In this video, I'm going to make another user interface design case study. This time, having to do with the Microsoft Office Ribbon. So let's review what the ribbon is. So, I'm showing you here just a picture of a screenshot of Microsoft PowerPoint, and the ribbon is this area at the top. It's a toolbar that contains a bunch of buttons and objects that you can click on. And the idea is that the ribbon is this strip across the top of the window that exposes what the program can do. And a key driving idea is that it is the single place to look for all the functionality in the program. Whether it be Microsoft Word, PowerPoint, Excel, etc. And if you think about designing, if you're the person who's designing the ribbon, there's going to be a bunch of design challenges that the design team will face. And there's a really nice blog online from one of the lead designers on the project that really goes through the background of the design of the ribbon. What they were thinking about, the problems they were facing and how they went about it. And then talks through the final design. So if we think about the design challenges the team faced, there's going to be a lot of obvious things. Like, well, how do you design the icons? What is the rendering of the icons? What text they use, what fonts, what colors, how things are laid out, and so on. But I want to focus one other particular challenge they faced. So which commands, which functions of the program should you include as buttons in the ribbon? So this is taking up screen real estate. It's making a commitment, or making an assertion that these are important things for the user to do. So, how do you decide which commands should get buttons? And if you think about it, maybe there's commands that don't need buttons, like, let's say saving a file. That's control+S in Microsoft, well maybe you dont need to put up a button for that because everybody just uses control+S, you might think. Same thing with things like copying and paste. Maybe you don't actually need to put up buttons for those things, because everybody knows about like Ctrl+C and Ctrl+V and Ctrl+x for cut, and so on. So you might think that, at least. Now how would you go about deciding which commands actually required buttons in the ribbon? Well, a good way to do that might be to ask yourself, well which are the most popular commands that people actually use? because those are good candidates for creating buttons for them. And how would you answer that question? Well, this blog that I was referring to goes through the old way that they had been doing things in Microsoft. Which was to basically use the intuition of the designers themselves. Now, you might have heard us already, you might recall that we've already talked about how you as the designer are not the users. That you need to use evidence. And the experience here really reinforced that. So again this blog post says, well, how would you decide which feature people use the most the old way? Well you'd ask experts who'd been around on the team for a long time and the experts might say something like, everybody uses auto text a lot. Or, no normal users like to save all the time, they just save when they're done. So, those are the kinds of things, that intuition might tell you. But by the time they were designing the ribbon, they had a new way of guiding their design decisions. This new way was data-based, and data came in through what they called the Customer Experience Improvement Program. This was basically a feature that was introduced in Office 2003, Microsoft Office 2003. Where users could choose to opt in, and if they opted in a bunch of data about how they were using this system, Microsoft Office products would be automatically uploaded to Microsoft. The data was collected anonymously. It couldn't be traced back to the users, and again, very importantly it was opt-in. So, it didn't happen automatically. And they collected all sorts of data. Including all the commands that were used and how the commands were issued. Were they issued by clicking on buttons? Were they issued through keyboard shortcuts? Many other things. Now, at this point I want to do something that the Microsoft Office designers did in this blog post that they wrote. Which is to challenge you to think about, if you're a user of Microsoft Office products or similar products, what do you think the most popular commands are? And when the designers asked that question, they got a bunch of people who email them in to give them answers. Some of the people said, well Ctrl+z, undo, is very popular because everybody tries things out and changes things. Or changing the format of text, bold and italic and so on. Some people might say, nobody uses cut or copy and paste, that's something people are not familiar with. Nobody likes to do print preview because it's a weird concept. And those are all ideas that people have based on their own experience. Now there is a great quote from this blog. The only difference between your wild guesses, the kinds of things I just mentioned to you, and ours, that is the people on the design team. Would have been that ours would have become reflected in the product. So, designing a product based on guesses doesn't sound like a great way to do things. And indeed, in this case, they didn't have to. They had data from the Customer Experience Improvement Program. And those data let them determine what were the top five most used commands in Microsoft Word 2003. Which had been the previous most recent version of Microsoft Word. And the answer was paste was number one, save was number two, copy number three, undo number four, and bold was number five. 32% of all the commands issued in Microsoft Word were one of these five commands. And paste alone accounted for 11% of all the commands that had been issued in Microsoft Word, so, pretty astounding. Now, more things that they found from the Customer Experience Improvement data. They found that if they looked at Excel and PowerPoint, in Excel, 15% of all commands were paste. And in PowerPoint, 12% of all commands were paste. And after that it was interesting, the data, the usage of commands exhibited what's called a long-tail distribution. Where a few commands are used a lot, like paste and save and the ones I just showed you. And then most of the commands are not used very much. They're only used infrequently by not that many people. That's the so-called long tail. And so if you go back and look again at what the Microsoft Office ribbon looks like. You'll notice at the upper left corner of the ribbon is a Paste button. It's large, it's labeled, there's an icon. And this was put there specifically because they had data that showed that this was the most frequently used command. Furthermore, the data also showed that even though often people used Ctrl+V to paste in a keyboard shortcut, they also still very frequently used a button. They clicked on a button, and therefore, this design decision was informed based on actual usage, rather than designer intuition. So if we collect the insights from this simple case study, the first thing I want to leave you with is that knowledge is power. The Microsoft Office team went from intuition-based to evidence-based design. And this is really crucial, because people's design intuitions oft differ, and that means often people are wrong in their intuitions. And so it's much better to guide design with data. You will make better decisions, and it's easier to convince people, both within and outside your design team that there is grounds for what you're recommending. It's also important to remember this long tail of command usage. And what that means for a product is you might thinkable here's a command that's not very popular, so maybe I can get rid of it. But it turns out, lots and lots of commands, even though they are not used frequently, in the aggregate they are still used by quite a few people some of the time. And that helps explain why it’s hard to simply cut down the functionality of a product. And then finally it helps to be explicit. Once you have data, you can build a model or even an informal theory of how people will use your software. You understand what they do with it. And then that can help you make sure that the design that you create or modify will actually support what people will actually will do with your software. So that's it for the Microsoft Office Ribbon case study. Thanks for joining me and that's it until next time.
