Hello, I’m Jeffrey Dunn (User Experience Designer) with the Office Design Group (ODG). As Shawn mentioned in his “Designing with Customer in Mind” post, ODG includes UX Designers who work to create compelling software. I’d like to share with you a little bit of the design work that went into Office 2010. I hope to give you a sense of the scope of our work and how it’s made 2010 a better experience for you.
UX design defines how software looks and behaves. We’re deeply interested in the interaction models that affect how software is perceived, learned and used. Our goal is to make compelling software that’s usable, useful and desirable. We are not the only discipline at Microsoft that has an active hand in experience design. In fact we are a partner. We work closely with the researchers in ODG (see Tim’s previous post “UX Research Tools and Techniques”) to integrate your feedback into our software design process. We are embedded with engineering teams and also work closely with many of the folks you’ve heard from on this blog: the teams that produce Word, Excel, PowerPoint, Visio, Project, SharePoint etc.
As UX designers we get to exercise many creative muscles you might associate with the word ‘design’. We sketch on paper. We brainstorm new opportunities. We envision interactive flows and innovative ideas. We create wireframes of software interactions, and mock-up the look and feel of our software. Many of these creative tools have one goal in common: they minimize the risk of committing to a particular design direction. The artifacts we produce support discussion with product teams, researchers and you. They help us realize which design proposals are compelling & feasible.
We sketch. We build prototypes. We design the visuals. Though not as concise, the samples below may illustrate what we do with a little more clarity. Since I’ve worked closely with the SharePoint product team to incorporate the Ribbon user interface, I’ll share with you a few samples that highlight the development of SharePoint 2010. It’s important to note, most of these samples represent designs that do not match what you see in Beta. This is important as many of our sketches & prototypes are explorations. We aim to fail early and often such that what you see when we ship is the best that it can be.
Sketching is a tool we use throughout the product development cycle. It’s often helpful in the early phases. Collaborating with researchers and the product teams, designers sketch and iterate on feature design. Sketching is very low cost work. We can explore a myriad of possibilities without committing time to visual polish or code. The quick and loose nature of a sketched designs helps crystalize a vision, teasing out goals and success criteria. It sets the foundation for discussion, iteration and polish.
These early sketches explore possible placement of Ribbon UI in SharePoint 2010. (Click to see larger images)
Sample sketches exploring alternate ways to access site level commands in SharePoint 2010. (Click to see larger images.)
Once a design direction is well understood we often create a prototype. These mock user interfaces are often click-able and rich with interaction. Like the sample below, some prototypes are bare, almost wireframes. Regardless of the fidelity, creating a prototype helps us get a closer look at the intended design. The process of building one removes ambiguity by crystalizing a number of decisions into a design that can be experienced, just like the real software. It is common for us to evaluate the experience of these prototypes in the lab, with people from outside Microsoft. Tim mentioned this in his post “UX Research Tools and Techniques”.
Here is a sample prototype exploring ribbon interaction for SharePoint 2010.
Designing the form and behavior of our applications is another core part of what we do as designers. The visuals or form are closely tied with the interaction or behavior. We carefully consider how the user interface is presented. We also carefully craft the subtle details that make each button hover and transition feel alive. In a future post we’ll spend some time explaining the details of how we develop visuals and branding. Here, I want to share what happens once interaction and visual direction is defined. There is quite a bit of work that goes into specifying interface details. Being embedded with engineering teams means that we play a crucial role in making sure that software matches our specification. This is what we often call a fit and finish stage. The sample below illustrates just how detailed we get about visual.
Above is a sample visual specification of SharePoint 2010 Ribbon user interface.
I hope this quick overview of user experience design helps you understand the impact of our discipline on the software you use. Our work affects the look, feel and behavior of Office products. It’s evident in the icons, themes, visuals and details of each application screen. It also shows through in the bits of delight we hope you experience when you use Office.
Please look for our upcoming posts on the Visual and Branding story for Office 2010. We look forward to hearing what you think! Thanks for reading.
Love it. Please keep posting! Your predecessor did a great job - and you've carried on wonderfully!
I'm very grateful you've stuck with the Ribbon - I know i'm not the sole opinion but i love it and has made my files look a lot better through easier access to tools etc.
I agree with William D... absolutely LOVE the Ribbon interface and have been since the early 2007 betas. Every update just gets better and better.
The Office 2010 beta installer keeps stopping and telling me that there's some Technical Preview code somewhere on my machine. I swear I uninstalled everything and even went into the registry and deleted anything with 14 in it...I'm going mad.
Wow...When will Note Pad get the Ribbon...and why have you overlooked VBE....lets not leave any Menu unturned...lets screw it all...
Why is it that Office 2010 is supported on Server 2003 32-bit, Server 2003 R2 64-bit but not on XP 64-bit? Aren't 64-bit XP and Server 2003 nearly the same? If you are supporting it on Server 2003 R2 64-bit, please support 64-bit XP as well. This is OFFICE! Hope this changes by RTM.
Curious what software do you guys use for your prototyping? Is it done by a UX designer or a front-end developer?
“Designing with Customer in Mind”
Great axiom. But what I missed in almost all Microsoft presentations is the difference between evaluating mouse clicks of thousands of customers" and modeling typical use cases
Let's take as an example the document editing use cases and the implementation of the Ribbon in Word (which is great new UI on principle )
Especially the use case scenarios for structured “long douments” with complex numbering concepts, and the consistent separation of content and formatting by the strict usage of named styles became more and more out of focus of the standard Microsoft Word UX: Microsoft has implemented almost all of the needed functionality but the standard design of the Ribbon does not fit at all to the “long and structured” document use case scenarios and I don’t see an impovement in Word 2010. Some examples:
1. The Quick Styles concept and the other visualized concepts instead of showing names of the styles only is nothing but a superfluous catastrophy!
2. The user interface design for multilevel lists is another catastrophy: Removing the tab accessing the multilevel list styles (as part of the paragraph style dialog) does not reflect at all the typical beavior of Word professionals. The single access to list styles is from Word 2007 up the Button “Multilevel List” only.
As all Word professionals, teaching “creating of long documents in Word”, warn the customers not to use the buttons for direct formatting, removing the access to list styles from context menus, from the Paragraph Style Dialog and from the Styles Pane ist the worst what Microsoft could have done. And do you really want leave the context menu entry naming “Adjust List indents” although this is the only access to edit the standard Multilevel Lists?
3. The “Restart Numbering” function is by design a manual override only and not a style option of the corresponding paragraph style: This is one reason for millions of frustrated Word users (Have you ever read the earlier mailing list on “Word numbering” issues. Why does the Microsoft UX team ignore the informations on the Word MVP website, or Shauna Kelly’s great information on how to use Word?).
4. The Master/Sub document concept is another real malformation and should be exchanged by the well known Book concept you find in professional DTP software.
I see all this as a question of UX and not a real question of "missing functions".
To answer Adam above - we use a variety of prototyping tools and methods. Sometimes it's just paper without any software. Screen mockups and behaviors can be presented in a richer fashion with PowerPoint, which is a pretty common tool. Most folks know how to use it and designers often supply toolkits that help teams prototype a variety of experiences. We sometimes get even more robust and prototype with HTML, Flash or Blend/Silverlight. This work is usually done without a frontend developer. It's often a designer with scripting experience though sometimes we collaborate with the CS experts to the best possible prototype.
Dieter has some great critiques of word functionality associated with 'long documents'. Although I can’t speak to the work that went into these features for 2010, I can say that user scenarios and the use cases that make up those scenarios are well considered throughout the product development cycle. From a user experience perspective we typically model use cases of higher priority scenarios. We also evaluate the experience of those scenarios repeatedly until ship.
Nice to hear that case scenarios for long documents are not out of focus of Word UX Design.
But I checked all official MS documents concerning the use of list styles and I couldn't find any information about the consistent use and managing of list styles together with linked paragraph styles, although list styles (and styles in general) are to be seen as future save, reliable and advanced features.
As I pointed out in
and in http://social.technet.microsoft.com/Forums/en-US/word/thread/44b7af50-ac57-481e-91ce-a178b8458587
I see the UX design that Microsoft realized in 2010 Beta obviously reached the opposite of the intended goals: Microsoft is hiding styles (at least their names) and especially is hiding list styles.
I think all Word professionals urgently need a detailed tutorial/use case scenario how to edit, modify and to manage(!) list styles and their links to paragraph styles.
Additional: MS Sources with regard to Word 2007/2010 list styles:
Multilevel Lists vs List Styles
The Many Levels of Lists
Bullets, numbers, and lists
Your post here was routed to me and I wanted to provide an answer for the wider audience as well as get you a quick reply to one of your key concerns.
I believe that you are confusing the mechanisms of a paragraph style linked with a list with a list style structure containing paragraph styles. The changes made in Word 2007 (most notably, removing list styles from the style pane, removing the UI that let you assign a single level of a list style with a paragraph style outside of the list style structure) were intended to help guide users into correctly structuring their documents without having to have a depth understanding of the features. The key point is that you always manage those relationships via the List Style UI but apply the formatting via the Paragraph Style UI.
I'm working on a more detailed response to your posts on the Word blog and look forward to continuing this conversation there.
That sounds very interesting. I can't wait to read the detailed new information: I work with list styles for for several years and I really hope I am confusing something and not Word :-)
By the way several links about the Word (2003 and 2007) list concept seem to enforce that's not only my confusion.
"The key point is that you always manage those relationships via the List Style UI but apply the formatting via the Paragraph Style UI."
In principle that's ok.
But up to now I don't recognize an overall consistent list style management UI
So I'm interested to see how you define the typical workflow for creating and controlling list styles and their links to paragraph styles as part of a template development.
And what about the compatibility and the stability with regard to editing a document containing lists and mixing Word versions 2003, 2007 and 2010?
Just found the first "best practice guide" on List styles
(archive of microsoft.public.word.numbering)
It's by Stefan Blom:
"In a nutshell, the list style does what 'modifying the numbering formatting via the top-level style' (see
http://www.shaunakelly.com/word/numbering/OutlineNumbering.html) did in previous versions, that is, it ensures (or tries to ensure) that you access the same list template, as you modify the multilevel (outline) numbering in
In another mail Stefan Blom said:
"I wouldn't recommend anyone to use list styles in Word 2003. Instead,carefully set up outline numbering with each level linked to a unique paragraph style, as explained at Shauna Kelly)."
and "Word 2007 is a bit more stable (is such a wording not a symptom for really bad product quality?)"
How can a reliable list styles workflow covering Word 2003, 2007,2010 look like?
Or with regard to "UX Design Tools & Techniques": How do the current UX methods cover the discussed aspects?