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.
Just what is UX Design?
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.
Yeah but what do you really do?
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.