Month: March 2008

When I came to my new company, I didn’t mind going from Vista back to Windows XP. There were a few tools and features that I missed, but ultimately one version of Windows isn’t too much different than another.

But I would have caused a serious uproar if I had to use something other than Office 2007.

It’s pretty rare for me to feel passionate about Office software. The last version of Word that I really, really liked was probably Word 5.1a for the Mac, back in 1992. After that I got proficient with some newer features, most notably working with references and TOC formatting for an 800 page software design book that I put together from individual documents in a ridiculous amount of time back in the late 90s. But it got harder and harder to like Word, and I found the time I spent typing in plain old text boxes on the Web to be a refreshing change. I even adopted Notepad and other text editors as my quick writing tool of choice, and still find I prefer working in plain text to having to think about formatting as I write.

So what changed my perception of Office? Why am I no longer afraid to set foot in Word? Why do I actually evangelize PowerPoint 2007? I think the answer is that the Office team, Jensen Harris among them, sat down and looked seriously at how people used, or didn’t use, Office, and made some hard choices about how to change the software to fix what they found.

Jensen had a great presentation at Mix that explains the process that the Office team used to come up with the new Ribbon-centered design for Office 2007. I’ve only looked at the slides so far, not the actual video, but by themselves they’re pretty inspiring.

What are the takeaway principles? I think the outline of the presentation spells it out:

1. Define the problem by talking to actual users. Don’t rely on the conventional wisdom to tell you whether there is a problem with your software. Conventional wisdom would have told Microsoft that Office was a cash cow with no issues and no room to improve the brand, that they should just keep marketing the product the same way and keep stacking on task panes.
2. Get data about the problem. Start with internal observations (menu and command count), then go to external observations to define a hypothesis and an approach based on user interaction data and the emotional tone of how your users approach and think about your product.
3. Define the design goals, and draft a list of principles that guide the solution. If the solution is too complex to define up front, you’ll need guiding principles to help you make decisions along the way as you iterate.
4. Prototype. A prototype can be created a number of ways, from plain old paper to Photoshop to RAD tools. Use what’s appropriate and don’t discount the low tech solutions. At my current gig, most of our prototypes are created in Visio.
5. Evaluate the prototypes. I love Jensen’s list for this process because it sums up about two semesters’ worth of marketing education from my MBA program:
   • Beta users
   • Anecdotal feedback (blogs, forums)
   • Benchmarks and Metrics
   • Observations and Interviews
   • Usability studies (around the world and remote)
   • Card Sorts and Paper Prototypes
   • Surveys
   • Longitudinal Usability Studies
   • Long-Term Deployments (5 months+)
   • Truman Show
   • SQM (Customer Improvement Program) [automated data collection from volunteers]
6. Finally, build in room for iteration. You probably won’t get it right the first time, but you’ll learn from every trial.

I’m excited about Jensen’s summation of the experience because it is high-visibility verification that structured software design matters. It’s a great story to tell your management team, your development team, or that guy in QA who complains about changes to the screens.

I already know this approach works because I’ve used it, or at least a subset of it. At my last gig, this is what our design process looked like for our last release:

• Problem: Users couldn’t find functionality in our software that was already there. Some of the functionality confused users. Prospects didn’t enjoy working with our product as much as with competitive products.
• Design goals: Improve discoverability and make the product more enjoyable to use. Design tenets: reduce the number of toolbars; have consistent places and ways to expose functionality; borrow UI conventions from products that the user is familiar with; use a familiar overall convention to frame what the user is doing and make them at ease; eliminate features that weren’t adding value.
• Prototyping: Paper, Photoshop, and quick XAML apps. In some cases, I mocked up parts of the UI using sticky notes to move around different modules or parts of the screen design, so we could figure out how to get the features in the most convenient places.
• Evaluate prototypes: Here customer presentations and beta users made the biggest difference. I would have loved to have the budget for more formal usability testing.
• Iterate: We rebuilt our development process to allow for course corrections along the way.

The process isn’t rocket science, but it works, and so will your product if you think honestly about every step along the way.

Apple has posted its application form for the new iPhone enterprise tools, whatever they are (Apple has been awfully nonspecific on that point). This is cool for a bunch of reasons:

1. It’s an open, transparent beta process for a piece of enterprise technology.
2. From Apple. When was the last time you heard any of the words in the first point from Apple?
3. And there is a fairly detailed feature list too!

Well, prospective feature list. And of course I should note that there’s a chance this comes from a marketing manager who’s looking to write case studies. But still: cool.