Mac Mojo : Usability

evolution at work

nadyne — Tue, 18 Sep 2007 20:32:00 GMT

The Merriam-Webster Dictionary defines evolution as 'a process of change in a certain direction'. Software evolves, too. You can see some of the evolution of software when you compare one release of software to the next. The software that you see in the wild is the product of a series of evolutionary steps that are usually only seen in the lab. Let's pull back the curtain and explore some of those evolutionary steps in the lab.

One of our 'certain directions' for Office 2008 was to make it easier for our users to make great-looking documents. There are two facets of this decision: better tools for doing so, and easier access to the existing tools and the new tools. You'll see a lot of posts here in Mac Mojo that talk about the better tools. I want to talk about easier access to them. One of our major changes for Office 2008 is that we have made some significant user interface changes to meet the goal of easier access.

Those of you who are in mixed environments probably know that the Windows Office team has done a complete overhall of their user interface in Office 2007 for Windows. We have a great relationship with the Windows Office team. In Office 2008, as with all of our other releases, we closely followed their work so that we could leverage the appropriate pieces of it for our Mac users. One of their major goals for Office 12 was a laudable one: they wanted to improve the discoverability of features so that you could find the features that were already in there. A feature can be the coolest feature in the world, but its usefulness is degraded if no-one can find it. To solve this problem, they threw out everything in their existing UI and started from scratch. But even revolution has an evolutionary aspect to it, at least in software development. As they were doing early usability testing on what eventually evolved into the Ribbon, one of the most compelling results was that their users liked seeing graphical representations of actions because it helped them visualise what they were about to do.

We looked at their solution, and we were very interested in the user feedback about the graphical representation of actions. However, we decided that we couldn't simply throw out our interface right now. Our UI has evolved down a different path than that of the Windows Office UI, even before the Ribbon came about. One major difference is our Formatting Palette. For many users, it is both well-liked and well-understood. Losing that would have a huge impact to users who are already comfortable and productive with it.

Aside from the Formatting Palette, we had another reason that we couldn't throw out our interface wholesale. Mac users have strong expectations about their user interface. We're often told by our users that they definitely want us to look Mac-like. The Mac UI one of the strengths of the platform: once you learn how to do something in one application, you can be reasonably assured that this lesson will apply to other applications too. Mac users expect a menu bar at the top of their screen with an Apple menu, an app menu, then File and all the rest of them, finishing up with the Help menu. We could have just left the Apple and app menu in place, and ignored the rest of it. Not only is this a waste of screen real estate, it breaks the user's mental model. But the Ribbon does some great things, and we want to capitalise on their innovation while still ensuring that we keep a Mac-like experience.

We decided to evolve our UI for Office 2008, while keeping in mind the revolution found in the Ribbon. We came up with what we now call the Elements Gallery. It and the toolbars are embedded into the application window. The decision to not try to replicate the Ribbon made some other decisions quickly fall into place for us. One major decision that came about almost immediately was that, unlike the Ribbon in Windows Office, we would not try to put every feature into our Elements Gallery.

In our first design, we only included some of Word's Document Parts (headers, footers, cover letters, bibliographies, etc). Early usability testing showed that users really liked the idea, and asked whether it would be in the other applications as well. In response to this feedback, our design evolved into something which would be more broadly applicable across our suite. Since we didn't put all of our functionality in the Elements Gallery, users requested that we have a minimised mode so that they could hide it when they weren’t using it. Our design evolved again.

Throughout the evolution of our design, usability tests were essential to the changes. Last September, there was an interview in APC Magazine that happened in the middle of one of those usability tests. In that interview, APC quoted one of our product managers, who said:

We had what we thought was going to be this perfect UI solution, and the first time we put it in the labs, no-one understood it! It was so different they were completely confused! We just finished up another round of usability testing on the new UI yesterday, and the program manager said the difference is like night and day.

That's software evolution at work. In the previous test that she was talking about, we had missed the mark. In that usability test, none of our usability test participants could complete all of the tasks successfully. In my analysis of those results, I thought that we could fix all of the problems pretty easily. We quickly made some minor tweaks to our UI. My team went back into the usability lab, and presto! it worked! As that product manager said, the difference was like night and day, and all because our design evolved a little bit. We were pleased to find that our basic idea was solid, we just needed to make a few small changes to improve it.

I've talked a lot about the Elements Gallery, but, as they say, a picture is worth a thousand words. So let me show you an example of the Elements Gallery at work. I'm putting the final touches on a presentation in PowerPoint right now. Here’s the Elements Gallery showing me slide transitions:

Right now, we're putting the finishing touches on the Elements Gallery, as well as the rest of Office 2008. It's almost time to let our software out into the wild. You can see the Elements Gallery and other new Office 2008 features in action on our Office 2008 sneak peek website.

(Edited to fix the picture. Sorry, I linked to the wrong version of it! This is the 600-pixel wide version. Click on the picture to see the full 1000-pixel version. I didn't want to include the really wide one here so that I wouldn't make you scroll left-to-right in your web browser window.)

Come and get it! RDC for Mac v2 beta

nadyne — Wed, 01 Aug 2007 00:57:00 GMT

Today's the day! As Craig (our fearless leader) announced a couple of weeks ago, we have now made a beta of Remote Desktop Connection Client for Mac, version 2, available. You can download it from Mactopia (scroll down to get to the RDC v2 beta, it's listed under 'other products').

For me, RDC is one of those little apps that nicely fits a need. In my office, I have a Windows XP box that lives under my desk. I don't have a monitor hooked up to it. Its primary reasons for existence involve booking travel through the corporate travel agent and filling out expense reports. I only access it through Remote Desktop Connection.

RDC v1 is a great little app. It saves me from having to have an extra monitor sit on my desk. But it's not a perfect little app. Like a lot of software, it was originally developed by someone on the team to scratch their own itch, and ... well, it shows. It's perfect for the original developer's own use, but it's not perfect in other situations. One of the issues with RDC v1 is discoverability. I've long since lost count of the number of feature requests that we've had for allowing the resize of the RDC screen. That feature has always been there, you just had to know where to go to find it.

We decided that it was time to update RDC. There were several reasons behind this decision, including a new Remote Desktop Protocol, the need to be able to connect to Vista, and the OS X switch to the Intel architecture. Instead of updating the existing code, we decided to re-develop RDC v2 from the ground up using the latest Remote Desktop Protocol. At WWDC 2006, we announced that we would update RDC, and we've had a team working on it ever since.

One of the major differences in RDC v2 is that we've completely redone the UI. I did a usability study of RDC v1 that revealed several issues. Users had a hard time getting everything set up on their Mac as well as on their Windows machine. Users couldn't figure out how to share files between their two computers, and some didn't believe that it was possible at all. People didn't realise that there was online help available for it, and often didn't even install it. For RDC v2, we wanted to address these UX issues and make RDC a more Mac-like app. Our new UI isn't hugely obvious when you first look at the application — the UI has always been quite minimal, and we've retained that in RDC v2. RDC v1 uses a disclosure triangle to show you the connection options. In RDC v2, to be a better Mac citizen, we've moved these options to a standard Preferences menu. This should improve the discoverability of many of the features that we've always had built in, such as being able to view your Mac's hard drive when you're connected to your Windows computer.

Another UI change is that we now support dynamic screen resizing. In RDC v1, you couldn't change your screen size while connected to a Windows computer. Now you can, and you can enter full-screen mode during a session too. I love this because I use RDC on my laptop. When I'm in my office, I hook my MacBook Pro up to a big 23-inch external monitor. Using RDC on that is different than using it on my MBP's screen, and now I can switch between them dynamically.

One feature request that we have received frequently was the support of multiple sessions in RDC. System administrators want this feature because they often need to connect to many machines at once. Users of RDC v1 who want this feature can probably name a couple of workarounds, but they were all pretty messy. RDC v2 supports this natively. You can connect to multiple Windows machines by saving connection settings for all of the Windows machines that you want to connect to. Then, you can simply launch those saved connections from the Finder.

My favourite new functionality in RDC v2 is a security feature. In RDC v1, you could share files with your Windows box, but you had to open up your whole hard drive to the Windows box. This never really concerned me — after all, my Windows machine is in my office and I'm the only person who has access to it. But it meant that I had to dig through the whole file system to get the file that I wanted. Now in RDC v2, I can choose what I share with my Windows machine: nothing, the whole hard drive, or a specific folder. I've been using internal builds of RDC v2 for a few months. I've found that, when I need to transfer a file from my Mac to my Windows machine (or vice versa), I just share the Mac folder where the file lives. Then when I browse my Mac's files from the Windows box, I just see the one folder which is exactly where I need to be. It's a very small thing, but it saves me a bit of time.

This is a beta, which means that we're not quite done yet. We've still got some issues to iron out. We want to release it to you so that you can give us feedback about it. To send feedback about the RDC beta, use Microsoft Connect. Several members of our team, including myself, will be reading your feedback to make improvements to it before its final release.

ship it!

nadyne — Fri, 16 Mar 2007 00:47:00 GMT

Here's a secret of software development. You're never actually done with your software. There's always one more feature to add, one more button to tweak, one more change to make.

The end of a cycle is an odd time. Everyone is hard at work. The developers are finishing up their features and fixing bugs. The testers are ruthlessly hunting down bugs. The program managers are prioritising those bugs. The user experience researcher (hey, that's me!) is planning the final studies of Office 2008 for Mac.

But there's a problem. The people involved really love their jobs and have an unparalleled passion for excellence. 'How can that be a problem?!' I hear you ask. This is a problem because of feature creep. I hear it all the time. 'You know, if we just had a couple more days, we could do [more cool stuff]. What's a couple more days?' The devs come up with these ideas as they're working on the code. The testers come up with these ideas when they find a bug and come up with an elegant solution to the problem. The PMs come up with these ideas when they look at the lists of possibilities for their areas. And yes, I do it too: I conduct a usability test and think of a great approach to a particular scenario that I observed in the lab.

The end of a cycle is hard because you have to clamp down on these kinds of things, and it's hard to say no to a good idea from someone who deeply cares. Several feature creeps have crept into my office in the past month, brought in by people who have great ideas and want to get a UX perspective on their idea. Each of these feature creeps only take a couple of days, maybe a week, to fully realise. But the sum of all of these tweaks and additions and improvements that have crept into my office is easily six months, and I know that I haven't heard all of the ideas that have come up.

Creating a suite of products that have the scope of Office for Mac is a difficult mission. To make this mission somewhat easier, we have to decide how we're going to focus our efforts. This is decided early on in the project and is based on lots of research to understand and prioritise user needs and requests. It gets refined as we go along. When ideas come up, aside from considering their impact to the schedule, we have to figure out how they fit into our focus. If they're not quite on target with our focused priorities, the end of the cycle is when we're more likely to regretfully say 'no'. If the idea is on target, then a hard conversation starts: how do we fit this great idea into our product without having a significant impact on our schedule? It's always a delicate balancing act, and it gets more and more delicate as we get closer and closer to launching Office.

There's a growing refrain in the hallways whenever feature creep rears its attractive and tempting head: 'Ship it!' I'm hearing it more and more. We've all heard Steve Jobs' legendary "real artists ship" -- and that spirit is alive and well here and now. It's really hard to say no to cool things even when they come late in the game, but at some point, you have to realise that you don't have an infinite number of hours in a day and that you can't do everything that you want to do. This time.

Every day, we get closer and closer to being able to ship it. I'm looking forward to that day. Until we ship it, we have to avoid the siren song of feature creep. The good part about your software never being done is that some of us are already working on the version after Office 2008 for Mac, and all of these (and so much more!) will get their due consideration based on research and customer feedback (isn't this where I came in?).

Bay Area Mac users needed again!

Office for Mac — Fri, 22 Dec 2006 22:42:00 GMT

You responded in droves when we last asked for usability test participants! We have another usability study that Bay Area Mac users will be interested in. We’re doing another usability test of new features in both Entourage and PowerPoint. We need users who use Entourage at least once per week and PowerPoint once per month. The study will be conducted at our lab in Mountain View, California.

If this describes you and if you’re in the Bay Area, please sign up to participate in our study! You can do so in one of two ways:

Sign up on our usability participant webpage, and make sure that you indicate that you use both Entourage and PowerPoint. Don’t forget to fill out your contact details, otherwise we won’t know that you’re in the Bay Area! http://www.microsoft.com/mac/go/mactest/
Call our usability test recruiters at (888) 261 8488. They’ll take you through a questionnaire and get you into our database of potential participants. If you leave a message, don’t forget to specify your name, phone number, and that you are a Mac user.

If you’re in the database and are selected as a potential participant, you will get a call or an email from someone at Microsoft. They’ll ask you some additional questions to make sure that you qualify for this particular study. If you don’t qualify, or you’re not available this time around, don’t worry! We’re doing lots of usability studies in the next few months, so you might hear from us later.

We’re doing lots of other work as well, so if you’re interested in participating in our other usability studies in the Bay Area, Redmond, and around the world, sign up on our webpage. And don’t forget to tell your other Mac-loving friends and family!

A day in the life, usability edition

nadyne — Wed, 29 Nov 2006 04:26:00 GMT

A few weeks ago, Brad told us what a day in his life is like. Inspired by Brad, here's a day in the life of a user experience researcher. My days are highly variable, depending on whether I'm doing a usability study or not, so I'm not sure if this description is typical of one of my days, let alone any other user experience researcher's day.

7:30am - Compared to Brad, I sleep in. I have a shorter commute than he does -- about 10 minutes, maybe 15 if the traffic lights aren't cooperating or if I stop for a coffee or Jamba Juice on the way in.

8:30am - I got into this habit when I had a longer commute. I always check my email before I leave home. I tell myself that it's so that I know when my first meeting is, but I spend much more time reading/responding to email than checking my calendar. One of the items in this morning's email tells me that our Redmond campus is closed today due to snow. I'm torn between being jealous that they got a snow day and happy that I live in the Bay Area and thus snow is something that happens to other people. Somehow I manage to spend an hour reading and responding to email.

9:30am - This is a fifteen-minute commute day. I need coffee.

10am - Meeting #1 is with my contractor. I'm about to go on vacation for most of December (yay!), so we're mapping out all of the work that needs to be done between now and mid-January: working with the app teams to ensure that our usability recommendations for previous studies are included in the final products, creating the task lists for our next two usability studies, and recruiting for usability participants at Macworld Expo in January. (And don't forget that you can sign up to participate in usability studies, too.)

11am - Meeting #2 is with the other PowerPoint leads: program management, development, test, marketing, and user assistance. We're all working hard on Magnesium (that's our codename for Office 12), and our status for that is the major topic of conversation today. We also agree on when I'll run my next usability test.

noon - The email gods are never appeased, and they have delivered another eleventy billion into my inbox. Sigh. Some of the email is from snowbound Redmonders who are apparently losing their sanity due to the cold.

1pm - The email gods deliver good news in the form of my 2pm meeting being cancelled. Oh thank goodness. I have some time to catch up on my to-do list, and I blast through many of them: write up my weekly status report for my manager, make a first pass at prioritising the usability findings from my last Entourage study, make a first pass at prioritising the usability findings from my last PowerPoint study, write most of this blog post.

3pm - Meeting with my manager. I ask him to hold down the fort while I'm gone. I hope he doesn't let the teams make a new UI element bright pink or blinking ...

4pm - And the meetings are done for the day. I have another chance to get things done, so I do: review a few things and send feedback, respond to some of the email, help out an Entourage PM with a question he has about laying out a dialog, chat with the PowerPoint lead PM about an upcoming meeting, chat with the PowerPoint lead dev about the differences between interviewing a candidate for an intern and a full-time position. I wrap up the day by writing up my to-do list for tomorrow so that I don't forget what I really need to get done first.

5:30pm - I duck out of the office to attend a Barenaked Ladies concert in San Francisco. Good night!

thanks!

nadyne — Fri, 27 Oct 2006 00:39:00 GMT

I put out a call on this blog last week to help me find some users who are Entourage and PowerPoint users. I had lots of responses, and as of right now, that particular study is filled. I want to thank all of you for reading that post, responding to it if you fit my needs for that study, and forwarding it on to people who you thought might be interested. That was immensely helpful to me, and I look forward to meeting those of you who will be participating in the study next week.

I'd like to remind you that you can always sign up to participate in usability studies. Whenever I make a study request, we always start with the people who have already signed up. If you signed up some time ago and some of your information has changed (your address, your phone number, your email address, or the products that you use -- for example, you've started using PowerPoint since you filled out that page), please use that form to update your information.

Bay Area Mac users needed

nadyne — Fri, 20 Oct 2006 19:24:00 GMT

Edited to add: This study has now been filled. Thanks for signing up!

I know that I’ve asked our readers to participate in our usability studies before. I have a very specific need this time, and I’m hoping that you can help me out.

I’ve got an upcoming usability study that covers new features in both Entourage and PowerPoint. Thus, I need users who use Entourage at least once per week and PowerPoint once per month. This study will be conducted at our lab in Mountain View, California in early November. If this describes you and if you're in the area, fill out this contact form and use 'usability study' as the subject. If this doesn’t describe you but does describe a friend, please direct them to this post. :)

In exchange for about two hours of your time, you get to help shape the future of our Macintosh products, and see new features and the new UI of Entourage and PowerPoint. You will also receive a Microsoft software or hardware gift of your choice, such as Office:Mac 2004, Microsoft's new Mac-only keyboard, an Xbox 360 game, or several other things (even Windows Office 2003, if you'd like to give it to a friend).

If you have questions, you can email me.

of babies and bathwater

nadyne — Tue, 03 Oct 2006 22:47:00 GMT

A couple of weeks ago, Mary gave us a behind-the-scenes look at talking to the press. One of the articles that came from the interview that she talks about is in APC: First details of Office:Mac.

In that interview, Mary was kind enough to give usability testing a shout-out. Here's the relevant part of that interview:

Design and usability testing on the Office 12 interface is already underway in the MacBU labs at Redmond and Cupertino, and the team has already made one trip back to the drawing board based on user feedback.

"We have usability experts and usability labs at both of our campuses, and we're spending a lot of time bringing people through for each iteration of the UI. That's part of why it's changing so much right now" explains Starman.

"We had what we thought was going to be this perfect UI solution, and the first time we put it in the labs, no-one understood it! It was so different they were completely confused! We just finished up another round of usability testing on the new UI yesterday, and the program manager said the difference is like night and day."

This is such a great example of what I do and why I do it. We are refreshing our UI (don't worry! we're not killing your toolbars!). We put in a lot of effort to design the refreshed user interface. But we're not perfect, and our original design wasn't perfect. When we took our new UI into the usability lab, it didn't do as well as we'd hoped. Users were really confused. So we went back to the drawing board.

Going back to the drawing board doesn't mean that we threw the whole thing out. There was definitely a baby in that bathwater. We had to figure out what worked in our design and what didn't. For what didn't work, we had to figure out why it didn't work. Were we totally wrong, or were we just a little bit wrong?

So we came up with some ideas for fixing the issues that we observed. For something as big as a UI refresh, this is quite a big deal. There were lots of discussions and brainstorms. We decided what we would change. Mostly, they were pretty minor tweaks: making something look a bit more like a button, changing a name, that kind of thing.

The week that Mary and Sheridan did that interview, we were in the usability lab trying out the new design. Those little changes that we made had a huge impact. In the original study, none of the users really got it. In the second study, the difference was, as the PM that Mary mentions in the article said, like night and day.

Of course, it still wasn't perfect. It might not ever be perfect -- possibly because perfection doesn't actually exist for something that's as complex as what we're doing. So we made a couple of extra changes. Right now, I'm writing this blog post while sitting in the usability lab to see if this change gets us where we want to be. While I'm here, I'm also testing out a couple of new features that I didn't have enough time to test earlier. I'm not done with this study yet, but the preliminary data is fantastic. I think we've gotten what we wanted: a new UI that looks great and that helps our users do their jobs easier.

Before anyone asks, I can't answer specific questions about it yet. Not all of our functionality is hooked up, so it's still not finalised. And while I've been in the lab this week, I've discovered that there are other things that I want to look at. We solved the big problem, and the existence of the bigger issue hid many of these smaller ones now. I'll be back in the usability lab again to look at other related items. (Although our labs are in Redmond and Mountain View, not Cupertino.) If you'd like to join me and get a sneak peek at the new UI and features, sign up to participate in our usability tests!

Edited to fix a broken link. Thanks to the anonymous commenter for pointing that out!

another way to give us feedback

nadyne — Wed, 06 Sep 2006 20:37:00 GMT

Aside from leaving comments in this blog and the other various MacBU blogs, or sending us feedback on our product feedback website, there's another way to interact with us. Our user experience research team (which includes me) conducts usability tests.

In a usability test, we show you a prototype or some very very early code and ask you to complete some tasks using it. While you're completing those tasks, we'll usually ask you to think out loud so that we know what's going through your head when you're going through our code. Our usability tests take an hour or two, and we schedule them at your convenience. This means that you get to see early versions of what we're working on, and help shape the future versions of our software!

For example, if I were conducting a usability test for the calendaring functions in Entourage, I might ask you to complete the following tasks:

Look at your calendar. This tests whether you can find the icon, menu item, or keyboard shortcut that opens up the calendar view.
Your accountant just called and asked if you could meet at 2pm tomorrow. Are you free at that time? This tests whether you can understand the information that is presented in the calendar view.
Before your meeting with your accountant, you'll need to remember to get together your tax information. Leave a reminder for yourself. There are multiple valid ways to perform this task. If I am interested in a specific one but the user does the other one, then I'll ask them to try to find another way to do the task.

This is only a small corner of a usability test, but it gives you an idea of what we do when you come in for our usability tests.

We primarily do our usability tests in Redmond, Washington (which is in the Seattle area) and Mountain View, California (which is in the San Francisco Bay Area). We also travel around the world to meet our users. In exchange for participating in a usability test, you will receive a hardware or software gift from us. You could get a free copy of Office:Mac 2004, or one of our desktop sets (including Microsoft's new Mac-only desktop), or an Xbox 360 game, or even a copy of Windows XP.

If you are interested in participating in our usability studies, sign up here. People always ask about beta testing, but I think usability testing is cooler. (I know, I know, I'm biased!) You've got two hours of my undivided attention. I take the results of the usability tests that I conduct, and go directly back to the product teams to make recommendations for improvements. Usability tests are very hands-on, and have a huge impact on what we do.