Sign up to receive essays, appearance dates, and other news from Adaptive Path.
Our Latest Newsletter: July 29, 2008
UX Week is just two weeks away and the office is buzzing with anticipation. My conference workshop, “Beyond Wireframes -…
UX
Week is just two weeks away and the office is buzzing with
anticipation. My conference workshop, “Beyond Wireframes -
Making Interactive Sketches” is all about prototyping. The
convergence of UX and agile development requires different tools
and I am finding that design prototyping is one of the best
techniques to bridge a gap between designers and developers. This
concept was echoed by Jensen Harris, the Group Program Manager of
Microsoft’s Office User Experience team and UX Week speaker. In the
interview below, you’ll learn some techniques that proved
successful when moving designs into engineering inside of
Microsoft.If you’re interested in learning more about user experience in agile development, be sure to visit some of us at the Agile 2008 conference in Toronto next week.
-Dan Harrelson danh@adaptivepath.com
Jensen Harris Tells Dan About
Microsoft Office’s Ribbon Interface
Microsoft Office’s Ribbon Interface
Dan Harrelson, design technologist at Adaptive Path, recently spoke
with Jensen Harris, Group Program Manager of Microsoft’s Office
User Experience team. Jensen was one of the key designers behind
the new Ribbon user interface introduced in Office 2007. Dan and
Jensen chatted about Office’s redesign and the techniques he uses
to keep the focus on user needs within an organization the size of
Microsoft.
Dan Harrelson [DH]: Hi Jensen, thanks for taking the time to talk with me. You are often credited with designing the Office 2007 Ribbon. Can you tell us what went into the interface redesign and what your role was?
Jensen Harris [JH]: Creating the Office 2007 user interface was a team effort, and there were dozens of designers, usability researchers, developers, testers, and program managers involved in different aspects of the creative and engineering process. So many people contributed great ideas to the Office 2007 design that it is truly impossible to single out any single person as being the “designer” of the Ribbon.
My team was responsible for delivering the shared user interface platform for Office 2007, including the Ribbon, galleries, Live Preview, the Mini Toolbar, and the rest of the new user experience.
I would characterize my role as most similar to that of an architect. I drafted the design tenets, and helped make sure that everyone’s detailed designs gelled together into a harmonious whole.
One of our fundamental goals was to make the UI “feel as if it was designed by a single person” — even though, practically speaking, we knew that it was much too big of a project to actually be designed by a single person. Achieving a coherent design at this scale requires coordinated, consistent decision making as well as a strong design philosophy.
DH: The Ribbon has certainly garnered much attention and has been touted for the success of Office 2007. What other UI enhancements would you also call out as critical to the software’s success?
JH: One of our success metrics for Office 2007 was that normal people would be able to make beautiful, stunning documents and presentations. We wanted the average user to have access to professional-level results with fewer steps than in the past.
To help make this a reality, an awesome new graphics engine was built into Office — one capable of high-quality, beautiful effects, such as drop shadows, reflections, 3D lighting, and surfaces, etc.
We knew that we had to make harnessing the power of this graphics engine incredibly easy because, otherwise, most people would never spend the time to use it. This is where the new UI comes in.
Based on our early user research, we embraced a model for Office’s new UI called “results-oriented design.” The idea is to show people a graphical representation of exactly what result they’ll get as the primary way of surfacing the feature. Compare this to the old model, “command-oriented design” in which you show people a dry list of commands and let the user figure out how to string them together to get a good result.
An example: Imagine that you want to beautify a picture in your document. You click on the picture in Office 2007, and you are immediately presented with a visual gallery of great-looking designs. Each one of these designs technically uses several capabilities of the new graphics engine but, as the user, you don’t have to know anything about that. As you hover over each design, Live Preview shows you exactly how your picture would look, directly in the document — ultimate WYSIWYG. It’s a kind of instant gratification, and it’s very rewarding — and even a little bit fun.
Another small UI feature I’m addicted to is the Mini Toolbar. We wanted to optimize efficient mouse access to the most frequently used formatting commands (such as Bold, Italic, Center, etc.). Taking advantage of Fitts’ Law, when you select text in Office 2007, a little ghosted toolbar shows up directly next to the mouse cursor. If you move towards it, it fades in to reveal the top formatting commands. Because the Mini Toolbar shows up so close to your cursor, you can target the buttons very quickly and accurately — even though the toolbar itself is very compact.
DH: Now that we are over a year into the release of Office 2007 and Office 2008 for Mac is out, what are you using for success metrics? How are you tracking the impact of the UI a year later?
JH: The user interface has been a success on many different levels — the research shows that the new UI positively impacts productivity, increased Office 2007’s success in the marketplace compared to previous versions, and how thousands of other applications are springing up with their own Ribbons.
Measuring the productivity impact of something as broad as a new UI is very complicated. With a user base of 400 million Office users, just slightly changing the demographics of a study can vastly influence the results. Do you want beginners, intermediates, or advanced? Advanced with Office or with computers in general? Which version of Office do they currently run? What region of the world are they in? What kind of work do they do? Do you measure the first day they get the new version — or after three weeks — or after three months? Or a year?
There’s also the question of how you measure productivity. Is it faster time-on-task? Is it using more of the product than you used to (and thus getting better value)? Is it that you create better-looking or more powerful documents? Is it the way you feel when you use the product?
We spend a lot of time thinking about these questions and trying to come up with meaningful methodologies to make sense of all the data. But it’s fair to say that the first year exceeded our expectations.
DH: You describe your design process as starting with research, and with the ubiquity of Office, this means lots and lots and lots of data. What techniques did you find useful in dispersing user research findings to software engineers?
JH: Data is enormously important and interesting, no doubt. But it also tends to be abstract and, with engineers, can sometimes devolve into a discussion about how much we trust the data and skepticism about how it was collected.
When you want to convince a developer to help you make a change to the product, nothing is as compelling as bringing the developer into the lab and having them watch people fail. (Video also works well if you can’t bring the developer to the lab.)
Putting a human face on a failure really drives home why it’s important to improve usability, and helps everyone to visualize concretely whom we’re building the software for. Any developer worth her weight wants to do the right thing for her users, and so you usually just need to show them a test or two, and you’ll find that they are much more willing to help you. We bring developers and testers into our user research labs as frequently as possible.
DH: We sat on a panel together at MIX discussing techniques to “Get It Right” when developing software. You mentioned the use of what you call “Design Tenets.” What are these and why are they so important?
JH: Design tenets are a list of shared design beliefs that a team uses to help them make consistent design choices. Think of it as your team’s design philosophy. It’s the way we were able to end up with a design that has a coherent voice despite the fact that many people contributed to it.
For Office 2007, we had six design tenets. One of them was: “Give features a permanent home — prefer consistent-location UI over ‘smart’ UI.” Another was: “The user’s focus should be on the content, not on the UI; help the user work without interference.”
Before you start designing, you need to explicitly agree on the tenets your team believes in — those which are consistent with the kind of user experience you want to create.
Once you have your design tenets, you can use them to help make decisions when you have several design alternatives to choose from. If everyone consistently makes decisions based on the tenets, your user experience will hold together and feel like it was designed with a single voice
DH: Microsoft is so big that I have to imagine that the number of people working on Office alone is massive. How do you socialize design tenets to be an effective tool?
JH: First of all, you have to repeat them over and over and over again. We presented them at the beginning of every presentation we did for a year. We recorded them in video form and sent them to people via mail. We had them up on internal web sites. We posted them on the wall in paper form.
If you don’t feel like you’re constantly and annoyingly repeating yourself then you’re probably not socializing them enough.
It’s vitally important that everyone knows the design tenets — not just the designers. You need the developers and testers to internalize the tenets too, so that they can make consistent decisions in the engineering and verification phases of the product.
One good idea someone on my team had was to use the design tenets as content in our design prototypes. So when we were working on Word designs, the tenets themselves were the content of the document. As people scrutinized the designs they picked up the tenets through osmosis. We did the same thing with PowerPoint and Excel — you could imagine doing the same thing as content for a web site or mobile UI. It definitely beats “lorem ipsum…” as filler text!
DH: You say that design tenets have to be religion. Doesn’t that limit the creativity of designers and developers?
JH: Design tenets don’t limit creativity: they focus it.
You wouldn’t design a living room without understanding how it relates to the rest of the house. What’s the style of the house: Victorian? Art Deco? Contemporary? Modern? Should the rooms be dense and functional, or open and airy? What kind of color palette do we use? What kind of paint do we use for living spaces — gloss, semi-gloss, or flat? Do we care about childproofing?
Once we all agree on the design philosophy of the overall house (the design tenets), we can independently go off and design our own room without worrying that the house won’t make sense once all the rooms are done.
The alternative — doing the designs without tenets and in isolation — often leads to a situation in which you either have to do a costly and painful set of clean-ups late in the process or, more usually, you just ship an incongruous design and leave the users to sort it out.
DH: Well Jensen, thank you for taking the time to chat with me. I look forward to hearing you present “The History of the Ribbon” at UX Week next month.
Dan Harrelson [DH]: Hi Jensen, thanks for taking the time to talk with me. You are often credited with designing the Office 2007 Ribbon. Can you tell us what went into the interface redesign and what your role was?
Jensen Harris [JH]: Creating the Office 2007 user interface was a team effort, and there were dozens of designers, usability researchers, developers, testers, and program managers involved in different aspects of the creative and engineering process. So many people contributed great ideas to the Office 2007 design that it is truly impossible to single out any single person as being the “designer” of the Ribbon.
My team was responsible for delivering the shared user interface platform for Office 2007, including the Ribbon, galleries, Live Preview, the Mini Toolbar, and the rest of the new user experience.
Word 2007 Ribbon - Click to enlarge picture
I would characterize my role as most similar to that of an architect. I drafted the design tenets, and helped make sure that everyone’s detailed designs gelled together into a harmonious whole.
One of our fundamental goals was to make the UI “feel as if it was designed by a single person” — even though, practically speaking, we knew that it was much too big of a project to actually be designed by a single person. Achieving a coherent design at this scale requires coordinated, consistent decision making as well as a strong design philosophy.
DH: The Ribbon has certainly garnered much attention and has been touted for the success of Office 2007. What other UI enhancements would you also call out as critical to the software’s success?
JH: One of our success metrics for Office 2007 was that normal people would be able to make beautiful, stunning documents and presentations. We wanted the average user to have access to professional-level results with fewer steps than in the past.
To help make this a reality, an awesome new graphics engine was built into Office — one capable of high-quality, beautiful effects, such as drop shadows, reflections, 3D lighting, and surfaces, etc.
We knew that we had to make harnessing the power of this graphics engine incredibly easy because, otherwise, most people would never spend the time to use it. This is where the new UI comes in.
Based on our early user research, we embraced a model for Office’s new UI called “results-oriented design.” The idea is to show people a graphical representation of exactly what result they’ll get as the primary way of surfacing the feature. Compare this to the old model, “command-oriented design” in which you show people a dry list of commands and let the user figure out how to string them together to get a good result.
An example: Imagine that you want to beautify a picture in your document. You click on the picture in Office 2007, and you are immediately presented with a visual gallery of great-looking designs. Each one of these designs technically uses several capabilities of the new graphics engine but, as the user, you don’t have to know anything about that. As you hover over each design, Live Preview shows you exactly how your picture would look, directly in the document — ultimate WYSIWYG. It’s a kind of instant gratification, and it’s very rewarding — and even a little bit fun.
Another small UI feature I’m addicted to is the Mini Toolbar. We wanted to optimize efficient mouse access to the most frequently used formatting commands (such as Bold, Italic, Center, etc.). Taking advantage of Fitts’ Law, when you select text in Office 2007, a little ghosted toolbar shows up directly next to the mouse cursor. If you move towards it, it fades in to reveal the top formatting commands. Because the Mini Toolbar shows up so close to your cursor, you can target the buttons very quickly and accurately — even though the toolbar itself is very compact.
DH: Now that we are over a year into the release of Office 2007 and Office 2008 for Mac is out, what are you using for success metrics? How are you tracking the impact of the UI a year later?
JH: The user interface has been a success on many different levels — the research shows that the new UI positively impacts productivity, increased Office 2007’s success in the marketplace compared to previous versions, and how thousands of other applications are springing up with their own Ribbons.
Measuring the productivity impact of something as broad as a new UI is very complicated. With a user base of 400 million Office users, just slightly changing the demographics of a study can vastly influence the results. Do you want beginners, intermediates, or advanced? Advanced with Office or with computers in general? Which version of Office do they currently run? What region of the world are they in? What kind of work do they do? Do you measure the first day they get the new version — or after three weeks — or after three months? Or a year?
There’s also the question of how you measure productivity. Is it faster time-on-task? Is it using more of the product than you used to (and thus getting better value)? Is it that you create better-looking or more powerful documents? Is it the way you feel when you use the product?
We spend a lot of time thinking about these questions and trying to come up with meaningful methodologies to make sense of all the data. But it’s fair to say that the first year exceeded our expectations.
DH: You describe your design process as starting with research, and with the ubiquity of Office, this means lots and lots and lots of data. What techniques did you find useful in dispersing user research findings to software engineers?
JH: Data is enormously important and interesting, no doubt. But it also tends to be abstract and, with engineers, can sometimes devolve into a discussion about how much we trust the data and skepticism about how it was collected.
When you want to convince a developer to help you make a change to the product, nothing is as compelling as bringing the developer into the lab and having them watch people fail. (Video also works well if you can’t bring the developer to the lab.)
Putting a human face on a failure really drives home why it’s important to improve usability, and helps everyone to visualize concretely whom we’re building the software for. Any developer worth her weight wants to do the right thing for her users, and so you usually just need to show them a test or two, and you’ll find that they are much more willing to help you. We bring developers and testers into our user research labs as frequently as possible.
DH: We sat on a panel together at MIX discussing techniques to “Get It Right” when developing software. You mentioned the use of what you call “Design Tenets.” What are these and why are they so important?
JH: Design tenets are a list of shared design beliefs that a team uses to help them make consistent design choices. Think of it as your team’s design philosophy. It’s the way we were able to end up with a design that has a coherent voice despite the fact that many people contributed to it.
For Office 2007, we had six design tenets. One of them was: “Give features a permanent home — prefer consistent-location UI over ‘smart’ UI.” Another was: “The user’s focus should be on the content, not on the UI; help the user work without interference.”
Before you start designing, you need to explicitly agree on the tenets your team believes in — those which are consistent with the kind of user experience you want to create.
Once you have your design tenets, you can use them to help make decisions when you have several design alternatives to choose from. If everyone consistently makes decisions based on the tenets, your user experience will hold together and feel like it was designed with a single voice
DH: Microsoft is so big that I have to imagine that the number of people working on Office alone is massive. How do you socialize design tenets to be an effective tool?
JH: First of all, you have to repeat them over and over and over again. We presented them at the beginning of every presentation we did for a year. We recorded them in video form and sent them to people via mail. We had them up on internal web sites. We posted them on the wall in paper form.
If you don’t feel like you’re constantly and annoyingly repeating yourself then you’re probably not socializing them enough.
It’s vitally important that everyone knows the design tenets — not just the designers. You need the developers and testers to internalize the tenets too, so that they can make consistent decisions in the engineering and verification phases of the product.
One good idea someone on my team had was to use the design tenets as content in our design prototypes. So when we were working on Word designs, the tenets themselves were the content of the document. As people scrutinized the designs they picked up the tenets through osmosis. We did the same thing with PowerPoint and Excel — you could imagine doing the same thing as content for a web site or mobile UI. It definitely beats “lorem ipsum…” as filler text!
DH: You say that design tenets have to be religion. Doesn’t that limit the creativity of designers and developers?
JH: Design tenets don’t limit creativity: they focus it.
You wouldn’t design a living room without understanding how it relates to the rest of the house. What’s the style of the house: Victorian? Art Deco? Contemporary? Modern? Should the rooms be dense and functional, or open and airy? What kind of color palette do we use? What kind of paint do we use for living spaces — gloss, semi-gloss, or flat? Do we care about childproofing?
Once we all agree on the design philosophy of the overall house (the design tenets), we can independently go off and design our own room without worrying that the house won’t make sense once all the rooms are done.
The alternative — doing the designs without tenets and in isolation — often leads to a situation in which you either have to do a costly and painful set of clean-ups late in the process or, more usually, you just ship an incongruous design and leave the users to sort it out.
DH: Well Jensen, thank you for taking the time to chat with me. I look forward to hearing you present “The History of the Ribbon” at UX Week next month.
Get the FeedAdaptive Path News
Charmr is an IDSA Finalist
We’re excited to announce Charmr as a finalist in the IDEA awards! Charmr is a design concept
generated from our R&D initiative that shows the vision for a
combined glucose pump and monitor for Type 1 Diabetics.
Read more here.
Subject to Change Now Available for the Kindle
Kate Rutter Interviews SFMOMA
Interactive Educational Technologies Team
Interactive Educational Technologies Team
What can the User Experience field learn from the world of museums?
Peter Samis and Tana Johnson of the San Francisco Museum of Modern
Art (SFMOMA) Interactive Technologies Team can help answer the
question. The issues that they grapple with (and solve through
inventive design) are firmly grounded in the goal of providing
exceptional and inspiring museum experiences. Read
the interview here.
Andrew Crow Interviewed by Viewzi
Initially a print and web designer, Andrew moved into information
architecture and interaction design to promote holistic user
experiences to corporate clients. Andrew has over 12 years of
design, technical, and strategic experience in the technology
industry.
Watch here.
Get the FeedSelections From Our Blog
- Kate Rutter
Making My Peace With Museums - Dan Saffer
Adventures in Physical Computing, Part 3 Input Via Sensor - Rachel Hinman
30 Down … from her 90 Mobiles in 90 Days Project - Peter Merholz
Conversation with Michael B. Johnson of Pixar Part 1
What We’re Reading
- InformationWeek
Esquire Magazine publishes first e-ink cover - Wordle
A cool word cloud generator - Tech Crunch
Evite finally gets a facelift - BBC
Say goodbye to the computer mouse - WorldChanging
The iPhone is greener - Today’s Big Thing
Stop Design Innovations
Check out more links at Signposts
Recent Newsletters
- July 29, 2008 [Permanent link]
- July 15, 2008
- July 1, 2008
- June 17, 2008
- June 3, 2008