In this course, you will gain an understanding of the critical importance of user interface design. You will also learn industry-standard methods for how to approach the design of a user interface and key theories and frameworks that underlie the design of most interfaces you use today. Through a series of case studies on commercial systems - many of which you likely use on a regular basis - we will illustrate the benefits of good design. We will also demonstrate how the costs of bad design can often be severe (in user experience, money, and even human lives). You will then gain a high-level understanding of the user-interface design process. You will be introduced to common design scenarios - e.g. improving on existing designs and starting a new design from scratch - and the general design processes that tend to be used for each scenario. Finally, we will begin introducing the large body of existing knowledge on design by providing overviews of core user interface design theories and concepts. This key foundational information will help you avoid “reinventing the wheel” when you are designing your interfaces in this specialization.
Case Study #3: Microsoft Office 2007 Ribbon
Loading...
您将学习的技能
Usability, User Interface Design (UI Design), Design Theory, User Interface
审阅
4.7（674 个评分）
- 5 stars497 ratings
- 4 stars147 ratings
- 3 stars19 ratings
- 2 stars5 ratings
- 1 star6 ratings
SA
Nov 13, 2018
I am so excited about to have gained an introductory knowledge on this course and I really anticipate learning the remaining four of the courses on this specialization.
AL
Dec 31, 2018
It's amazing opportunity to learn something new and get motivated to start your career in this field, 100% will continue to complete all of 5 courses of UI design.
从本节课中
Introduction and Overview
教学方
Loren Terveen
Professor
Haiyi Zhu
Assistant Professor
Lana Yarosh
Assistant Professor
Dr. Brent Hecht
Assistant Professor
Joseph A Konstan
Distinguished McKnight Professor and Distinguished University Teaching Professor
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.
