Hello world!

(Isn’t that how you’re supposed to start anything computer-related?)
My name is Jensen Harris and I work on the Microsoft Office “user experience” team.  Our team is responsible for the overall interaction and visual design of the programs that ship in Office.  Although we work very closely with the individual application teams (Word, Excel, PowerPoint, Outlook, etc.) to help solve difficult usability issues specific to those programs, our key responsibility is to design and develop the UI framework that people use to interact with all of Office.  Some of the innovations that came from this team before my time working on it included red-squiggle spell checking in Office 95, command bars in Office 97, and Task Panes in Office XP.
In short, the team’s mission is to help make sure that you can find and use the functionality in Office as seamlessly as possible.
Some background on me: I’ve worked at Microsoft for a bit over seven years; before that I was twice a summer intern.  I spent my first five years at Microsoft working on the Outlook e-mail and PIM program, both for the Macintosh and for Windows.  The last project I worked on was leading the redesign of the Outlook 2003 user interface that shipped in Office 2003.  After work on Office 2003 concluded, I moved to the overall Office user experience team, and that’s where I’ve worked for the last two years.
In this blog, I hope to write a lot about my thoughts about the ins and outs of defining and designing the user experience of Office.  I’ll be writing frequently about the future of Office but also sometimes the past.  And there may be times I find it irresistible to delve into general user interface issues or even (gasp) software issues in general.  Hopefully you’ll indulge me once in a while.
I look forward to reading your comments and hearing suggestions on what would you would like to see me cover.  In some cases, I may be able to point you to blogs which more precisely cover the information you’re looking for; there are a pretty substantial list of product teams and personalities blogging from around the Microsoft world these days.
More from PDC in Los Angeles tomorrow…
Comments (11)

  1. Mark Bower says:

    Jensen is a PM on the Office 12 UX team. His blog will be focussed on the new UI for Office 12.

  2. Winston Dosera says:

    "our key responsibility is to design and develop the UI framework that people use to interact with all of Office"

    Is there anywhere within that remit a responsibility towards people who are "quite happy with it the way it is now, thank you very much!"?

    I can’t help feeling that the unstated reason behind most "enhancements" to the UI is to break compatability with long established ways of working and to, in effect, force people through yet another upgrade.

    What exactly does the new Office do that the old one not? Moving options around and redesigning icons for the sake if it is a kind of 2nd grade approach to the UI.

    If it ain’t broke why fix it?

    If it is broke, modify it.

    Don’t just throw it away.

  3. Jon says:

    Really useful insight into your teams work – Thanks for the words!

  4. ray says:


    Why have cars when horse and buggy can get you from a to b?

    Why do surgeons wash their hands before an operation when for hundreds years before that it didn’t matter (apart from to the patients who died or got seriously sick)?

    Office 12 might be significantly better or it might be worse. The market will judge.

    Microsoft is taking a huge risk in making changes like these to one of their major revenue-generating products, especially now that good-enough products like OpenOffice are available for low or no cost.

    Some people will like it, some won’t. I’m reserving judgement until I’ve actually used it, rather than just seeing a demo.

    "If it ain’t broke why fix it?" — The Office developers obviously think the current UI paradigm is broken.

    "If it is broke, modify it." — Sometimes things are so broken you cannot fix it with a few cosmetic tweaks.

    "Don’t just throw it away." — I bet you’ve complained about code bloat like the rest of us 🙂 Making a clean break (while maintaining a level of backwards compatibility) is much better than having legacy code forever embedded in an app.

  5. Russell says:

    I have a question concerning the declarative markup. I saw in the lab how inserts were done, but how are deletes and updates handled? i.e. How would a customizer remove a button from an existing chunk? Also, how would multiple Add-ins handle conflicts such as, A deletes item, B updates item (after A)?