This chapter uses some special usability and ethical issues that arise from experience with what can be called captive end-user systems (CEUS). These are systems required to gain access to or participate in a private or privileged organization, or for an employee or member of another organization wishing to gain such access and participation. We focus on a few systems we list, but our discussion is relevant to many others, and not necessarily Web-based ones. The specific usability aimed at in this chapter is usability testing (UT), which we use in its usually accepted definition.
This chapter reviews, extends and updates earlier work (Troutt, 2007) that introduced the term captive end-user systems (CEUS) and the basic ideas. The earlier paper focused on some special usability, usability testing (UT), and ethical issues that arise from experience with such systems. These are systems that are required to gain access to, and participate in, a private or privileged organization. They do also apply to situations where an employee or member of another organization who may wish to gain similar access and participation. The examples that come to mind are generally web-based and required for submitting such material as:
Articles to academic journals (editorial systems)
Student applications to universities and academic programs
Faculty curriculum vitae (CV) material into a database
Our focus is on systems like those listed, but many others, not necessarily web-based ones, could also be listed. Automated phone-answering systems come to mind. Government forms such as tax filing forms also qualify, although in that case, commercial tax preparation software is available in the form of several competing products.
As an attempt at a more precise definition, we suggest the following. A captive end-user system (CEUS) is a computer-based system whose intended end users will not have had input into the systems analysis and user testing of the system and or did not have an opportunity to shop among similar systems.Top
Background: A Growing Problem
A First Example
A case familiar to one of the authors involves a change to the e-mail system at a Midwestern US university. Some people, like his spouse, hate the new system which is called Zimbra. This has now become a new curse word in the office (as in “I’ve been Zimbra-ed” or just “Oh Zimbra!”). While sympathetic to his spouse’s viewpoint, the coauthor in question doesn’t have the same problems using it. This is in part due to many hidden features that are part of the interface, hence undocumented and not obvious to the general user. For instance, this mail client is a Web 2.0 application. People were used to using MS Outlook and all of the features it had, as well as its user-interface components. Since this interface doesn’t work the same way, it feels unfriendly and not as functional, until one figures out how to do the same things in it.
This usability deficiency was described to an expert in this sort of situation, most prevalent in the conversion of an old system or the adoption of a new system. The new system may be actually a better design, but because it doesn’t allow them to do things in the same old way, it first appears unfriendly and not a good fit with established procedures and habits. As a forerunner of our discussion, let us reveal at this stage that the expert’s recommended solution is to first find out what outcome or objective the end users are seeking, and only then show them how this can be accomplished in the new system. At the 2007 HICSS conference, a presentation specifically looked at that issue as a shared mental model problem in virtual team support (Thomas & Bostrom, 2007) The research showed that training and the development of shared mental models among users has a direct impact on successful appropriation of newly introduced tools. Such training and development activity is many times replaced by coercive actions that mandate change without justification or explanation. Such coercive approaches are rarely successful.