Technical Communication at UAHuntsville

Last week, while preparing to give a presentation to a group of students, I encountered a problem. When I logged into my favorite online presentation editor, I discovered that the interface had changed almost completely.  There were unrecognizable menus across the top of the screen, and the buttons and menus I was used to were no longer there. I experienced a brief moment of panic. I had to present the next day: how was I going to learn a completely new interface AND complete a presentation visual in less than twenty-four hours? Fortunately for me, a banner appeared at the top of the screen offering me the option to switch back to the “classic” version, at least temporarily. I could create the presentation I needed using the version I already knew and come back later when I had more time to learn the new interface. Not every user is so lucky when it comes to other software or websites.

My potential panic could have been prevented if the developers of the online presentation software had utilized the concept of iterative usability testing. Dr. Jeff Bacha, a professor of technical communication at the University of Alabama in Birmingham, gave a lecture this week at the University of Alabama in Huntsville advocating “In-context” usability studies, and he touched briefly on iterative usability testing as a method of producing more efficient products–and subsequently happier users.

What exactly is iterative usability testing? Iterative usability testing differs slightly from traditional usability testing. In traditional usability testing, usability experts observe users as the users interact with the product after it has been completed or nearly completed. In iterative usability testing, users are offered the chance to evaluate the product throughout its development. In other words, as small changes are made to the product (the software, website, etc.), users are asked to evaluate the product and the specific changes that have been made. When I think about iterative usability testing, I like to compare it to the writing process. To adopt a writing term that many people may be familiar with, iterative usability testing is, essentially, revising. When we write a document, we draft, ask readers for feedback, make changes, and ask for feedback again. We may go through the process half a dozen times or more, producing slightly different–and hopefully improved–drafts each time. Iterative usability testing is a similar process undertaken for a product such as software or a website. The developer makes small changes to a software program or website, asks users for feedback, and takes their concerns into account when making changes to the next version.

In the diagram below, I illustrate the similarities between the two processes. The first stage of both processes is the creation of an initial version of the document or product, a “first draft,” as it were. In the second stage, the product is tested by users (or the document is read by readers) and feedback is collected. In the third stage, that feedback is incorporated into the document or product. In other words, the product or document is revised in order to reflect user/reader concerns. This results in the fourth stage of the document, the new “draft.” I do not say the final draft, because in writing and in iterative usability testing alike, each draft is sent again to readers and users for additional feedback, for as many “revising loops” as time and resources allow before a final version is produced.

The key to successful iterative usability testing is incremental change: if the changes to the product are too drastic, users may be overwhelmed and become unable to point out specific, fixable issues. Take the case of my interaction with the online presentation editor as an example. If the developers had not offered me the alternative to revert to the previous version of the controls, I would have quickly become frustrated, because I didn’t have time to spend on learning the new system right then. In all likelihood, I would have abandoned the editor altogether and gone back to a familiar system like PowerPoint, at least for the project at hand. On the other hand, if, instead of changing the interface all at once, the developers had changed things little by little, asking me along the way (through email surveys or on-site polls) which changes I liked and which ones I didn’t, my potential for frustration would have been greatly reduced.

Iterative usability testing, then, is useful in one respect because it prevents user frustration. However, it is also useful for developers; in the long run, it can save time. Incremental usability testing provides developers with user feedback throughout the development process so that they can tailor the product to the user’s needs. Finding out which features users actually use and which ones they dislike can direct the development process more efficiently. The developers won’t waste time making major changes that users neither need nor want.

Thinking of iterative usability testing in the same way writers think about revising could help developers prioritize their incremental changes. There’s no need to waste time working on an introduction to a document if readers think the draft is fine as it is; instead, the developer can focus on problem areas that will actually improve the reader’s experience. Likewise, there’s no need to work on changing the appearance of the forum on a website if user input shows that nobody actually wants to use the forum.

If the developers of the online presentation editor I was using had asked me, I would have told them that the menu interface was fine as it was. I didn’t need them to make changes to a system I already knew. Perhaps the developers have added new features or reduced the number of clicks it takes to add a YouTube video link to my presentation; I haven’t had time to go exploring in the new version yet. Whether it turns out that I like the new version better or not, the occasion did serve to remind me that when it comes to making changes to something, whether it be a document or a digital product, it’s important to keep the user’s needs first. And how do I find out what users need? I have to ask them—again and again—until I get it right.

–Bonnie Winstel