Designing and engineering the new Office 12 user interface has been the most challenging project I've ever worked on.  Over the last two months or so, you've had a chance to start to get to know me and some of the design philosophies I believe in that carried over into the user interface.

But I'm just one of many people who have been working over the last two years to bring the world these design evolutions, and today I want to tell you a little bit about this incredible team.  We're known internally as the Office "UEX" team, short (of course) for user experience.

The heart and soul of a product team at Microsoft is the development organization.  Without developers to engineer the architecture and write the code, there could be no product.  They're the ones who turn ideas into reality.  Leading the overall development process is Dave, our dev manager, who manages the overall engineering process.  Reporting to him are six dev leads, each responsible for architecting a major area of the user experience: the Ribbon, extensibility, galleries, Ribbon content, etc.

Microsoft is blessed to have talented developers, but the developers working on the Office user experience are among the best I've ever worked with.  They've had an enormously daunting task: build an entirely new UI architecture, a bunch of controls no one has ever built or used before, on top of decades-old code bases with menus and toolbars built down to the core of them.  And do it all while the design is continually changing and iterating.  It's an amazing feat to take these ideas that have never been done before and to figure out how to make them real, how to get them done on top of these different application architectures.  Without the dev team, there would be no product, and they have accomplished everything they've been asked to do.  When you sit down a year from now and use the Office 12 UI, it's because our developers figured out how to make the ideas come alive.

On the other hand, if the user interface works predictably, it's because of our test team.  Imagine this challenge: "We're changing the UI of everything in Office.  We need you to test all the new controls and concepts no one has ever created or tested.  Also, could you check every command in Office and make sure it's still there and works like it's supposed to?  Thanks."

Sean leads the UEX test organization, which has had its own profound challenges.  All of the automated UI testing in the product was built around command bars; a new mechanism had to be devised.  Testing all of the new mechanisms in the product would have been work enough, but they have also have lead the charge to make sure all the functionality in the product was accessible through the new UI and worked as expected.  They have to be flexible and willing to roll with changes as we continue to learn more and change the way things work.  At the same time, they also test the experience of the features themselves, giving valuable feedback on if it seems like the design makes sense in practice.  Probably the best compliment I can pay Sean's team is that they've provided us with no shortage of bugs to fix in the coming months. :)

I work on the program management team.  We write the specs and are the most directly responsible for the design of the features that show up in the product.  Julie (you know, Video Julie) leads the overall team and has the most important job on the PM team: clearing obstacles and managing distractions so that the team can execute on the vision.  I'm one of the two PM leads reporting to Julie.  My role is probably best described as UI coordinator.  I'm responsible for making sure all the pieces fit together across all the designs and for generally giving lots of feedback and kind of messing in people's work.  I get to listen to ideas, give ideas, help with hard problems people bring to me, help keep the designs on vision--all without actually having to write any specs myself.  (Man, I've got a great job!)   Our other PM lead, Preethi, has been coordinating the developer story for the new UI as well as leading the story around migration and a number of other areas.

The soul of the PM team, however, are the individual PMs.  Each one owns the design decisions for a number of different areas--everything from generating the initial ideas to writing the spec, to working with the developer and tester on bug triage.  We have an amazing, eclectic, and talented PM team and a culture that encourages the free spread and incubation of ideas.  I think back to so many of the key design ideas that became the core of the UI, and often times I don't even remember who came up with the idea initially.  It doesn't matter, because the PM's job is to find the best idea, wherever it comes from, and turn that into a great design, a great spec, and eventually a great feature and/or product.

We also work every day with the Office Design Group.  Designers are great problem solvers--they can help us visualize solutions to problems that we couldn't imagine on our own.  The design team owns the visual look and feel of the product, using the colors, textures, and animations to augment and enhance the interaction design.  In Office 12, the design team has had the challenge of helping to architect not just the eventual visual look, but also what it would take to create that visual look: what kinds of drawing and animations layer we would need to make the visual design awesome.  We provide the wooden puppet, and the design team turns him into a real boy, infusing the product with life and spirit.

We also have a usability and research group which provides the decision framework used to evaluate the product.  Back before we decided on the direction to take the UI, it was the usability and research folks who set out all of the data and information learned from the last decade of studying people using Office.  (Ask me about the "fish" sometime...)  Every step of they way, these folks have had to work to push the envelope of how we do usability research, how we evaluate the effect of a major UI change.  I know I have promised to blog more about this effort, and I will do so.  But suffice to say, we learn things from our usability research virtually every week that directly impacts the design of the product.

And then there are all the others who help out and who have contributed ideas and code and resources--devs, testers, PMs, usability engineers, designers, product planners, our international teams around the globe, localization, and marketing from all of the product teams involved in the UI.  We have "official" representatives from every team getting the new UI (Word, Excel, etc.) whom are just about as involved in the process as we are, but of course many people on each of those teams have helped us along the way.

I guess what I'm saying is this: doing something as ambitious as the Office 12 UI takes a team of people working towards the same goal.  No one person conceives or develops the entire thing.  Everyone has a role to play, and every role is key to the success of the product.  It doesn't take a huge team to achieve something great.  You combine the best ideas you have with hard work from talented people in an environment which believes in and supports your team, and you have a chance of making something great.

Have a safe and fun weekend and don't forget to drop your "Top 5 Word Commands" guess in the comment box.  I'll have the results on Monday.