http://tc.eserver.org/authors/Wilson,_Chauncey_E. A bibliography of works by Wilson, Chauncey E. in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Wilson,_Chauncey_E. http://tc.eserver.org/35597.html http://tc.eserver.org/35597.html A common mandate at many software companies is “Make our products consistent!” I’ve heard this clarion call for consistency at every company I’ve worked for that has more than a single product or service. The rationale behind the consistency mandate is that it will reduce design and development costs, improve the overall quality of the software, strengthen the brand (“the products should all look like they come from the same company”), make learning easier for users, and reduce errors when multiple products are used together. These are all great goals, but there is a problem with the consistency mandate – consistency is complex, multi-dimensional, and sometimes at odds with other important goals like usability. http://tc.eserver.org/35598.html http://tc.eserver.org/35598.html I’m part of the AEC User Experience Team at Autodesk. Our goal is to design a great user experience for our customers, but just what does that mean? Our definition of user experience focuses on all the touchpoints that current or new users have with our product. For example, the downloading of software trials is often the beginning of one’s user experience with a product. If you have to fill out forms that ask for too much information, (should “cell phone number” be a required field on a trial download form?) or present you with too many obstacles, the likelihood of a positive user experience will be low. Your interactions with technical support, documentation, the product, and even other products that you use, are all aspects of the user experience. http://tc.eserver.org/35595.html http://tc.eserver.org/35595.html User Experience and usability practitioners are on a continuous hunt for problems that plague our users. This seems straightforward – find problems from testing, user forums, observation, and other methods, prioritize the problems, and generate solutions that eliminate the complaint. However, some events that we call problems in one context may not be problems in another. http://tc.eserver.org/28493.html http://tc.eserver.org/28493.html A 'user edit' (also known as a 'usability edit') enables you to evaluate the usability of documentation (Schriver, 1991). Participants in a user edit study can either think aloud as they use the documentation to complete tasks or they can mark up the pages of the documentation to indicate where they had problems. The think-aloud protocols or marked-up pages are then reviewed for usability problems. The user edit report lists the problems and recommendations about how to improve the usability of the documentation. http://tc.eserver.org/25069.html http://tc.eserver.org/25069.html I’m not used to writing editorials, but lately I’ve heard complaints from more than a few usability professionals about reviews of their work that were snide, hostile, and lacking in reasonable suggestions and this has moved me to speak out. These complaints deal with a primary activity of our profession: constructive criticism. We are often asked to uncover potential problems with products and processes and recommend design changes that could improve usability – using a tone that is firm and constructive. We are also asked to provide feedback to our usability colleagues in book, proposal, and presentation reviews. I have become concerned that feedback among usability professionals is not always as constructive as the feedback we routinely present to our clients. With the recent introduction of the UPA Code of Conduct, hostile reviews of the work of colleagues could be considered an ethical violation. More about that later. http://tc.eserver.org/24918.html http://tc.eserver.org/24918.html Predicts that usability practitioners will need new skills to cope with changes in this field. http://tc.eserver.org/19194.html http://tc.eserver.org/19194.html Over the years, I’ve often heard colleagues say 'let’s throw a questionnaire together and find out what our users think about our product.' Implicit in this statement is the assumption that questionnaires are easy to design, administer, and analyze. This assumption is far from the truth. http://tc.eserver.org/18221.html http://tc.eserver.org/18221.html In this progression, respected usability specialists will moderate tables on subjects of interest to colleagues who have been working in the usability field for some time. These topics will focus on usability test design, data analysis and presentation, and marketing of data. Attendees should plan to contribute their own experiences. This progression addresses the frequently expressed request by Usability PIC members for more sessions on advanced topics in usability. http://tc.eserver.org/14190.html http://tc.eserver.org/14190.html Chauncey Wilson of BMC Software, Inc. has compiled this excellent list of resources. We are grateful to him for allowing us to post it here. To contact Chauncey directly, send e-mail to chaunsee@aol.com. This bibliography was last updated in December 1998. http://tc.eserver.org/11904.html http://tc.eserver.org/11904.html A reader asks, 'I have a question regarding the tracking of usability problems for a project. In some of the larger projects that I have worked on, we end up with a long list of fixes from multiple sources (heuristic evaluations, usability evaluations, user comments, etc). Many of the comments tend to get buried in a long list or pushed aside by high priority items. How are some of the ways this has been dealt with in the past?' http://tc.eserver.org/11881.html http://tc.eserver.org/11881.html The Just-In-Time (JIT) method of data analysis has the virtue of immediacy, rapid turn-around, and team involvement; however there are several disadvantages. First, this type of analysis is problem-focused, rather than goal-focused. Long lists of problems are generated, but there is no clear relation to specific usability goals. Second, developers may not be able to fix things immediately so the context of the problem may be lost when it is time to fix the problem. Third, the JIT analysis requires that the entire development team observe the testing sessions since problems may occur that are the responsibility of different developers. http://tc.eserver.org/11884.html http://tc.eserver.org/11884.html The following response to a question about heuristic usability testing techniques appeared recently on a popular mail list for usability professionals. http://tc.eserver.org/11882.html http://tc.eserver.org/11882.html Have you ever wondered about reports of usability tests? How much time does it take to write one? What should you keep in mind when designing and writing the report? Here are some rules of thumb that I use. http://tc.eserver.org/11819.html http://tc.eserver.org/11819.html Most usability studies focus on ease-of-learning rather than on long-run efficiency. Ease-of-learning is an appropriate goal for products that are used infrequently, like many commercial Web sites, automatic teller machines (ATMs), or Microsoft PowerPoint. However, ease-of-learning should not be the primary goal for products like corporate accounting and purchasing software or CAD software that are used many times a day, often by 'power users'. For products where most users soon become experts and use the products daily, efficiency should be the primary usability attribute, with ease-of-learning a secondary attribute. http://tc.eserver.org/11830.html http://tc.eserver.org/11830.html For things like order-entry or general form input, some of the attributes of windowing applications can get in the way. If you are designing a windowing application for frequent form-based input/modification, you want really good keyboard capabilities, an absence of windows popping around, a minimum of keyboard mouse transitions, etc. The guidelines for Windows design don't really deal well with form design and high-frequency data input and modification. http://tc.eserver.org/11834.html http://tc.eserver.org/11834.html Co-participation (also known as co-discovery) is a usability evaluation technique where two participants are paired in a usability test and work collaboratively on tasks. They are often asked to think aloud while working together. I've used co-participation for both hardware and software tests and have also used the more traditional one-person-at-a-time technique. http://tc.eserver.org/11838.html http://tc.eserver.org/11838.html It is important for the Usability Engineer to attend meetings where development and product managers review bugs, decide if the severity is appropriate, and choose which bugs will be fixed. I've been able to convince development and product management to consider some usability bugs as critical bugs. http://tc.eserver.org/11783.html http://tc.eserver.org/11783.html There is an ongoing discussion in usability circles about the importance of formal reports that document the results of usability testing. I think that each usability evaluation should have a formal report that provides some context for the problems. Not all problems can be addressed immediately and memories fade. Usability reports are also important for showing what a usability specialist has done. They can also be used to determine some metrics, such as the number of problems addressed by development or the number of problems that occurred during successive prototypes or versions of a product. http://tc.eserver.org/11744.html http://tc.eserver.org/11744.html This article highlights some of the lessons that I’ve learned about the process of creating style guides and implementing processes for ensuring that a product is consistent in a number of dimensions. I discuss the purposes and benefits of a style guide, a process for creating a style guide, the many types of consistency, reasons why style guides fail, methods for ensuring consistency, and some references that discuss these issues in more detail. http://tc.eserver.org/10890.html http://tc.eserver.org/10890.html Most development organizations track software bugs and their severity in a corporate database, which is shared with product development and tech support teams. We find, however, that these same organizations seldom have a standard method, if any, of tracking usability issues. Usability practitioners communicate usability problems through reports, highlight tapes, and formal briefings, but are these methods adequate for tracking usability problems through successive cycles of product development?