The Windows@ 95 User Interface: Iterative Design and ... - Microsoft

important lessons about how to best apply it. We alsolearned many things that changed the product we werecreating. Three of the most important ones are discussedbelow.Importance of baseline with existing productThe initial design for the desktop and file system UI wasbased on Windows 3.x and work done by the “Cairo”*team. These predecessors incorporated concepts validatedin even earlier systems such as the Apple Macintosh andXerox Star. Usability testing of the initial Windows 95design yielded fairly negative results. Both beginning andintermediate users had difficulty understanding basicconcepts in the new system. The magnitude of these resultswas surprising, because we thought we were on the righttrack by making small changes to the existing UJ.We realized that we needed a baseline with Windows 3.x,to better understand the magnitude of the prior problemsand what problems were unique to the new design. First,we gathered market research data about Windows 3.xusers’ top 20 most frequent tasks. We then conductedseveral lab studies comparing the existing and new designs,focusing on the top 20 tasks. The results were veryenlightening and greatly changed the design of the product.Had we begun the project with a baseline test of Windows3.x, considerable time and energy would have been saved.Scalability: the agreeable middle groundIn the initial design for Windows 95, we were afraid ofgoing too far and alienating the existing user base. Resultsfrom the baseline testing encouraged us to experiment withradical solutions. We created a separate UJ for beginnersand mocked it up. Usability testing proved successful,because actions were very constrained, but limitations withthis approach quickly appeared. For example, if just onefunction a user needed was not supported in the beginnershell, s/he would have to abandon it (at least temporarily).For these and other reasons, we abandoned the separateshell idea.After our two design failures, it became clear to us that atruly usable system would scale to the needs of differentusers: it would be easy to discover and learn yet wouldprovide efficiency (through shortcuts and alternatemethods) for more-experienced users. Scalability is visiblethroughout the final product, especially in the Start Menu.Replacements for the monolithic design specDuring the first few months of the project, our design specgrew by leaps and bounds and reflected hundreds ofperson-hours of effort. However, due to the problems wefound via user testing, the design documented in the specwas suddenly out of date. We faced a major decision: spendweeks changing the spec to reflect the new ideas and losevaluable time for iterating or stop updating the spec and letthe prototypes and code serve as the spec.1A future version of Microsoft Windows N?TM. Initialdesign work for the Cairo UI began in 1990.After some debate, the team decided to take the latterapproach. While this change made it somewhat moredifficult for outside groups to keep track of what we weredoing, it allowed us to iterate at top speed. The change alsohad an unexpected effect: it brought the whole team closertogether because much of the spec existed in conversationsand on white boards in people’s offices. Many “hallway”conversations ensued and continued for the duration of theproject.To ensure that interested parties stayed informed about thedesign, we:1.2.3.4.Held regular staff meetings for the design team. Heldweekly, these meetings allowed each of us to check inand to quickly learn how our work affected what otherswere doing.Broadcasted usability test schedules and results viaelectronic mail. Team members found always had thelatest test schedules and testing results handy.Formally tracked usabilitv issues, as discussedpreviously.Held regular design presentations for outside groups.Presenting to groups “live” was more effective than awritten document, because the presentations invitedricher feedback and always contained up-to-dateinformation.The “prototype or code are the spec” approach overallworked well, although we naturally have refined theprocess over time. For example, all the prototypes for agiven release of the product now reside in a commonlocation on the network and include instructions forinstalling and running them. The design team continues towrite initial specification documents and circulate them forearly feedback. Once prototyping and usability testing hasbegun, however, the spec often refers readers to theprototype for details. This, in turn, invites richer feedback.Using a prototype or code as the spec may not work well inother types of projects, such as contracted or procuredsoftware development, where completed specs are oftenrequired up front as part of a project’s contract.REFERENCES1. Nielsen, J. (1993). Usability Engineering. San Diego,CA: Academic Press, Inc.2. Sullivan, K. (1996). The Windows 95 User Interface:A Case Study in Usability Engineering. In CHI 96Conference Proceedings (Vancouver, BC, May 1996),ACM Press, 473-480.3. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988).Usability Engineering: Our Experience and Evolution.In M. Helander (Ed.), Handbook of Human-ComputerInteraction (pp. 791-817). Amsterdam: ElsevierScience Publishers, B. V.563