Sunday, September 27, 2009


Established products present additional challenges to User Experience Design. The central issue is how do we improve it without changing it.  There is impedance to change since users have "over learned"  the interface and change results in errors and a fairly significant re-learning process, usually more protracted than a new user would experience.  Microsoft designers have in the past few years done exactly that, changed Microsoft's office interface as described in this article.  This was a bold decision and has not been without its critics - see these comments on Amazon's Microsoft Office site.

Eric Lorenz discusses these issues in this entry from his log book.  He also discusses the quest for simplicity that may have motivated the changes, this was after we had discussed Maeda's, Laws of Simplicity, in the class.  I have mentioned Maeda's book in several posts and it is highly recommended.  Here's Eric's post:

During our lecture on 6/1/09, we covered Maeda’s “Laws of Simplicity”.  These Laws, and some of our other readings dealing with simplicity and complexity, have sparked some thoughts about two particular products on the market today that most of us come in contact with daily: Microsoft Office and the automobile. 

I brought up Microsoft Office during the lecture.  I was commenting on how the menu structure of the “new” 2007 version is considerably altered compared to the earlier versions, which had all been fairly consistent in design.  In my mind, this is a perfect example of the struggle between Consistency and organization.  The “what goes with what?” question has been answered well by Microsoft in the new version.  However, upon first inspection, the new version seems quite counter–intuitive and harder to navigate to existing users.  On an objective level, the new software is better organized and therefore offers improvement over the previous versions.  Because of its revamped organization, it is actually simpler: new users would probably find the 2007 version more intuitive, as they are not influenced by where the commands used to be located.  The menus are functionally consistent, if not version consistent.  I guess simplicity is in the eye of the beholder to some extent: Better organization may be friendlier for new users but the change of menus may actually seem to make the system more complex to confounded existing users. 

In this way, the gains in simplicity for new users are balanced with the learning and time difficulties for existing users.  (I wonder how Microsoft decides which group is more important?)  After all, most of the workforce does not receive formal training for a new version of MS Office.  Therefore we are forced to dive right in, which we know most likely costs extra time (and money) in the long run.  Along the same line, time penalties also result in user (and possibly their superiors’) frustration. 

In the end, I think Microsoft balanced its interests well because I believe they have done the right thing by improving the product first and foremost.  However, although the learning curve is probably not considered exceptionally steep for users’ of previous versions of the Microsoft Office suite, the impact is considerable because of the broadness of its effect as an organization’s entire workforce absorbs the time to adjust; not an insignificant event for something considered “productivity software.”

Personally, even though I was used to the old version and had been using this product for years, since I have become familiar with the new version I do prefer it.  I tend to be a logical person and like to have everything in its place, especially if it is a functionally organized place.  I was also well aware of the inconsistencies in the old version.  Even though the new version of Office is much different visually, I can appreciate the simpler organization because I see the difference between it and the (in my opinion) more complex old version. 

So what do you think, was MIcrosoft correct in its interface changes for the Office Suite?  Let us know what you think.  It will also be a great question to revisit.  Later.

Monday, September 14, 2009


The last quarter of 2009 and the first half of 2010 is going to be interesting for software projects.  The knowledgeable lead tech person should prepare for sporadic absences caused by the H1N1 virus.  A great place to follow the spread of the contagion is the flu tracker site in Pittsburgh.   Universities are feeling the effect of the H1N1 virus and are doing all they can to make preparations.

My advice would be to make sure you have flexibility and fluidity in your assignments, insuring that all critical areas of code have a main developer and a "buddy" (Brooks' co-pilot) that is very familiar with the code.  Perhaps this is the time to begin pair programming.

This also is the time to establish a remote work program so that folks feeling ill are not tempted to come to work.  It would be worthwhile to make it clear that folks feeling ill should stay home.  It also may be a great time to experiment with Second Life as a venue for remote meetings.

Please add any other suggestions you would like to share on preparing for and coping with this pandemic.  Later!