다음을 통해 공유

It Takes a Village

  • 아티클

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.

Comments

  • Anonymous
    November 04, 2005
    Is it "sometime" yet?

    So.... tell us about the "fish" :)

  • Anonymous
    November 04, 2005
    Yeah - let's hear about the fish already.

  • Anonymous
    November 04, 2005
    It sounds like a great team. But you don't mention anywhere how large the team is. I guess that there's no fixed size to it, but could you give a rough estimate? It sounds like there are already a dozen PM's, so I guess a couple of hundred developers is not far off. Is that still manageable? It's very interesting to see how this compares against teams like the 37signals (although the goals and products are in no way comparable, of course).

  • Anonymous
    November 05, 2005
    Quote: "...what kinds of drawing and animations layer we would need to make the visual design awesome."

    Is the new Office using WPF to proivde these drawing and animations layers?

  • Anonymous
    November 05, 2005
    The comment has been removed

  • Anonymous
    November 05, 2005
    Tom:

    What I was referring to is an abstraction layer Office has which provides the drawing and animation to the UI regardless of the backend rendering engine (be it GDI+, WPF, or something else down the road.)

  • Anonymous
    October 27, 2008
    PingBack from http://mstechnews.info/2008/10/the-office-2007-ui-bible/

  • Anonymous
    June 19, 2009
    PingBack from http://mydebtconsolidator.info/story.php?id=22986