Programmers are People, Too
Applying User-Centered Design to Middleware

Figure 1 Illustration of a middleware user interface

Creating a user experience that is easy-to-use, useful, and engaging for its target audience is the driving principle of the User-Centered Design (UCD) approach to product design and development (Vredenburg, Isensee, and Righi, 2002). UCD clearly applies to improving the aspects of a product that a typical end-user sees, hears, and touches. UCD can be used to design the graphical user interface you might see on a word processor, spreadsheet, or on the web site of your favorite retailer or news service. It can be used to enhance the potential customer's first impression of a product by helping design the marketing materials. It can help create a satisfying "out-of-the-box experience." In short, UCD seems to be ideal for designing all aspects of the typical end-user experience.

There are several reasons why it seems that UCD does not—or even should not—be applied to middleware. Consider these statements you might hear uttered among product managers, designers, and purchasers of middleware:

• "Users of this product are programmers. They don't require ease of use."
• "This product doesn't have any users. Why should it be designed with UCD?"
• "Our product doesn't have a user interface, so it doesn't need UCD."

These assumptions are erroneous for several reasons. First, middleware customers are now demanding exemplary ease of use. Higher workloads are making increasing demands on programmers' and systems administrators' time across an ever widening array of technologies. At the same time, training budgets are being reduced. Workers are being asked to do more with less, and often have to essentially train themselves. Second, middleware does indeed have users and a user interface. Although the users are not the end-users we typically envision, the users of middleware are in fact interacting with not only a user interface, but also, with all aspects of the "middleware user experience" (MUE), including the out-of-the-box experience, user information, marketing materials, service and support, maintenance and upgrade, and all other aspects of the product that the customer sees, hears, and touches.

As the middleware market matures, more products will deliver equivalent capability, making the MUE an important differentiator between them. Applying UCD to the design of the MUE will become essential for product success; in fact, the principles of UCD have been successfully applied to middleware in past projects (Sobiesiak, Jones, and Lewis, 2002). The following discussion therefore addresses why and how UCD can and should be applied to the design of the MUE.

The Market and its Requirements

Early UCD activities typically include identifying and segmenting the market for a new product, and identifying each market segment's basic requirements. A market intelligence professional or team reviews existing market data and conducts new research to determine the makeup, size, requirements, purchasing habits, and other pertinent characteristics of the target market. These data influence various design and strategy decisions, such as product features, positioning, and pricing.

Understanding the market for a middleware product is just as important as for a consumer product; in fact, it may be more important, since the market may be more complex. More often than not, middleware is purchased by enterprises (e.g., companies, government departments, universities etc) rather than individuals. The characteristics of enterprises must therefore be understood and considered when designing middleware.

First, in an enterprise, the middleware user, purchase decision maker, and purchaser may be different people or departments within the enterprise, with correspondingly different needs and expectations. All of these must be understood individually. The design of the middleware product must take all of them into account, striving to achieve a balance to meet the wants and needs of all of the user groups.

Second, enterprises often use middleware to support business-critical applications. Issues such as security, reliability, availability, and scalability that may not be so important in consumer markets are critical requirements for the middleware market. These issues make the enterprise working environment more complex. For example, business applications and associated middleware usually need controlled development and rigorous testing before being released into production. As a result, middleware users often work with multiple versions of the product in separate development, test, and production environments. The requirements for each of these environments may vary and may also involve specific tasks for moving data from one to another.

Third, many large enterprises also use a variety of systems-management products to monitor and control the middleware and other software they use to run their business. In these cases, aspects of the middleware product interface relating to administration and interaction with systems-management products may introduce more complexity to the design. Designers must focus their efforts on these aspects of the product that don't exist in typical end-user applications.

Finally, in addition to the purchasing enterprises, third-party systems integrators and Value-Added-Retailers (VARs) represent an important market segment for middleware products. VARs may package, install, and configure middleware with application software and hardware for customers who do not have the in-house expertise to do it all themselves. In these circumstances, customers may rely completely on the VAR's choice of middleware and may even buy it from them as part of the package. In these circumstances, the VAR's needs may be just as important as those of the purchasing enterprise.

Users, Tasks, and Goals

Key to a successful UCD effort is the identification and description of the users of the product. With middleware, the application end-user (that is, the user interacting with an application that utilises middleware) typically attracts the least focus from MUE designers and developers. By definition, these users do not interact directly with the middleware; therefore, there is an implicit requirement to deliver a completely "silent" or "invisible" experience for them. The middleware and all its external behaviour should be capable of being mediated appropriately by the application, unnoticed by the application end-user.

Although the application end-user does not interact with the middleware product, there are indeed direct users of middleware. These are the users that must become the focus of the UCD efforts. They include systems administrators, middleware application developers, and product evaluators. Each of these groups has unique characteristics, tasks, and goals that must be taken into consideration when designing the MUE.

Systems Administrators. Systems administrators install, configure and maintain middleware and other software. They are tasked with supporting business-critical applications for which reliability, security and availability are paramount. They often need to run the same sets of administration tasks on multiple systems and repeat them accurately and verifiably, for example, in both test and production environments. They may need to administer the middleware remotely, since the systems are often geographically dispersed. They may also need to perform some of these tasks in fixed "downtime" slots (e.g., overnight) to maximise availability of the business applications.

Traditionally, middleware has provided systems administrators with character-based interfaces (e.g., commands issued at a command-prompt and in scripts) rather than GUI's for their tasks. However, regardless of implementation (character-based or graphical), UCD is needed to understand the systems administrators' complex working environment and tasks and to ensure that the MUE supports them.

Furthermore, UCD often demonstrates the fallacy that systems administrators have no need for GUIs. Systems administrators certainly need character-based interfaces, which lend themselves to remote execution, automation, and repetition. However, character-based interfaces are subject to typing errors, misremembered syntax, and other ease-of-use and ease-of-learning problems that originally gave rise to the popularity of the GUI. After all, middleware users are people, too, and ease-of-use problems can seriously affect their productivity.

It is worth noting that not all middleware users want to interact with a GUI. Some systems administrators may still prefer a character-based interface for reasons of habit or efficiency, and they may even regard a GUI with disdain. One advantage of the UCD approach is that it encourages the MUE designer to ascertain these sorts of preferences from middleware users and to accommodate them in their designs.

So, middleware often needs to provide several interfaces (graphical, command-line, and scripted) for the same tasks, to meet the needs of different groups of systems administrators in different contexts. Each interface merits UCD in its own right, but there is also a need to ensure continuity between them in the MUE, since the same users may use all of them at different times.

Application Developers. Middleware application developers are programmers who create the application software that interacts with the middleware. Their MUE is largely provided by the middleware's Application Programming Interface (API). The developers write calls to the middleware into their application code using the middleware API to invoke the functions provided by it (e.g., to retrieve data from a database or to put a message on a queue).

Although the middleware API is a programmable interface (used by the application programs), it is also an important part of the application developer's MUE. To this end, it is important to focus on both the middleware API itself (content, structure and syntax) and on the user assistance (e.g., help, tutorials and samples) that enables application developers to learn and use it effectively.

Finally, similar to systems administrators, middleware application developers may also perform some middleware administration tasks to allow them to test their programs against the middleware.

Product evaluators. Product evaluators assess middleware products for potential purchase or for review in the computing press. They adopt the roles of both the systems administrator and middleware application developer to perform their evaluations; however, they do not necessarily have in-depth experience in either role. They often have only limited time available for their evaluation. Because their reports (particularly press reviews) can have a significant impact on the commercial success of the product, they are of great interest to middleware designers and developers.

Their relatively limited expertise and the speed at which they typically need to complete their evaluations mean that the out-of-box MUE may play a critical role in moulding their perception of the product. Designers should focus on helping these users move from receipt of the product to first time use quickly, efficiently, and pleasantly.

Gathering user task data

User researchers working with middleware users require more content knowledge and technical expertise to understand their tasks and goals. For example, feedback gathered during a task analysis performed with middleware users is often heavily couched in terms of the tasks as defined by the current technology. Users' descriptions of what they do, and expressions of want to do may be heavily influenced by the way the current product works rather than any ideal vision of how they would like to work. User researchers must perform a careful interpretation to extract users' underlying goals, and this requires a fair amount of technical content expertise.

The Out of Box Experience

One aspect of the MUE that has not been given adequate attention in the past is the "Out of Box Experience" (OOBE). The OOBE refers to the customer's first encounter with the product itself. It encompasses the experience of opening the package, accessing the contents, setting up the product, and using it for the first time. A positive OOBE is one that requires little time to move from opening the package to first time use, and that gives the user a pleasant, positive impression during this initial experience. As such, it may involve the design of the packaging materials, marketing collateral, documentation, software, and hardware.

In the past, the OOBE has been a focus for typical end-user products, but has often been only an afterthought for the middleware. The view of the middleware user as highly skilled and beyond the need for hand-holding has led to the mistaken belief that the OOBE is simply not important to middleware users. However, although highly skilled, middleware users typically have little time and resource to spend in this initial experience. Their mission-critical role in the enterprise requires them to maximize their productive time, and the design of the OOBE must support a fast startup. Thoughtful arrangement of documentation, pre-installation of software, and a minimal amount of non-essential collateral material can help the middleware user move quickly from unpacking the product to first-time use.

Further, in contrast to many typical end-user products, the middleware OOBE may be more complex. Getting started may involve a variety of orientation, planning, installation, and configuration tasks that span several product components and involve more materials (server, software, manuals). Additional and more technically-oriented focus should be given to the OOBE design.

UCD has raised the bar from simple usability to encompass more characteristics that make a product desirable. User delight is one such characteristic. The ability to make a user smile in recognition of special care taken in the design can be an extremely positive product attribute. An example of a delightful middleware OOBE is taken from "User-Centered Design: An Integrated Approach" (2002):

The IBM RS/6000 desktop and desk-side systems were designed to be consistent, user-friendly, and appealing to their intended users. The target user audience for these products was systems administrators, who could best be described at the time of this work to be young professionals who live and breathe computers. The packaging was designed to smoothly orchestrate the hardware setup and software installation through carefully presented, sequenced materials, and was based on usability studies of the tasks required for a successful setup. This logical ordering of materials avoided the "Christmas effect," where users scatter packaging and components around the room, digging for (and sometimes even discarding) items needed at various stages during the setup. Collateral material was included to capture the customer's interest and enthusiasm for the system. Users opened the product box to find a t-shirt, a mouse pad, a copy of Wired magazine, and games that showcased the 3D graphics capabilities of the system such as Quake. This approach to design worked beautifully. It became cool to have an RS/6000. One of the most common questions asked by customers in the feedback survey was "Where can I get another t-shirt?" One customer manager reported having to hold a raffle to give away the t-shirts because users who had been assigned systems from other vendors were jealous.

Additional efforts were made to ensure that the users' experience with the system would be positive from the very beginning. In one case, usability testing found that users were impatient the first time they booted the system because it went through a lengthy initial configuration process. The product designers decided to include a bag of microwave popcorn with the computer. When the system reached the configuration step, the instructions suggested the user enjoy some popcorn. Later, the installation process was changed to minimize the configuration delay.

Finally, consistent with other aspects of the MUE, middleware OOBE designers require more content knowledge and technical expertise to design a strong middleware OOBE.

Designing the Middleware User Interface

A typical graphical user interface for an application or web site has as its mission, to support common tasks in an easy-to-use, engaging format. The design of such an interface is based on a thorough understanding of the users and their tasks; specifically, interface designers try to understand how users conceptualize their tasks (their mental model) so they can design an interface that supports their way of thinking. Designers have the same goal with regard to the design of the middleware user experience. However, there are some key differences.

As described in "Users, Tasks and Goals" above, middleware users need a wider variety of interfaces than an application end-user, for whom a graphical interface is usually appropriate. Middleware users rely heavily on character-based interfaces (such as the command-line, scripts, and program code) to achieve the productivity and automation they need. The rendering of these interfaces at the screen is relatively straightforward and has less bearing on the success of the MUE compared to graphical interfaces.

Instead, the MUE designer needs to pay more attention to the task model that these interfaces expose. Very often, the model is shaped significantly by the emerging middleware technology and does not map directly to the user's current conceptual model of the domain. In these circumstances, it is important to validate the suitability of candidate task models implied by the technology prior to implementing it.

Getting the model right is essential, as it will provide the unifying foundation for the variety of user interfaces that will surface it to the user. Typically, low-fidelity prototypes (simple sketches) are useful in exploring and testing alternative solutions, especially at the early stage of the design process. However, since character-based interfaces are graphically less complex, it is often unnecessary to create illustrations of the user interface as it might eventually appear on-screen. Instead, the early, low-fidelity prototypes of the MUE are more likely to consist of user task flows necessitated by the objects and actions emerging from the basic architecture and technology prototypes. These may take the form of presentations of typical task flows that users can be "walked-through", to gather feedback on their utility, intuitiveness and efficiency. Later prototypes may then be used to illustrate the administration command and API syntax proposed to perform typical tasks. Their description and intended use, as detailed in the product information, will be a significant element of the MUE. Prototypes of this information can be a useful vehicle for gathering feedback on the adequacy of commands and APIs.

There are typically fewer visual cues to help the user identify and perform their tasks in a character-based interface, and additional assistance may be needed to improve the MUE. For example, it may be important to include interactive facilities to help a systems administrator construct commands correctly at the command-prompt, or simply to provide integrated access to help for available commands sets, syntax, and error conditions there.

Finally, if the underlying model exposed in the MUE differs significantly from the user's current model of the domain, then rendering it graphically in a GUI may provide a powerful means of facilitating the user's understanding of it, even if they migrate to command-line and scripting interfaces later on.

User assistance design

User assistance and information are also likely to be an important element of the MUE, especially in the absence of a graphical interface. Even if the interface consists of a relatively concise set of commands and API's, there are likely to be many different ways in which they can be combined, usefully or otherwise. Users need help to understand how best to configure the product and use the APIs for their own circumstance and needs. This is particularly true if the middleware is re-defining the tasks in the domain. Users will be not be able to draw on their pre-existing mental model to any great extent, and will instead rely more heavily on the information provided with the product.

To this end, the MUE designer must ensure that the MUE includes the appropriate user assistance for this purpose. It may include:

• Searchable online information centers
• Conceptual overviews
• Interactive product tours
• Tutorials
• Helpful, explanatory error messages
• Example applications
• Program code samples

UCD techniques are essential to ensure that this user assistance is both useful and usable.

Visual design

Visual design skills may not be important for middleware design if the middleware does not include a GUI. Nevertheless, they may still be needed to provide enhanced user assistance that contains graphical illustrations, e.g., architectural diagrams, animated product tours, and tutorials. Marketing collateral, branding materials, and sales and support websites will also require visual design effort, especially important since middleware typically runs silently beneath applications.

If the middleware does include a GUI, a greater level of skill may be required for its design than many typical end-user applications or web sites. Middleware concepts tend to be somewhat abstract in nature and the visual designer may need to generate appropriate and effective visual metaphors for abstract objects in the interface. It may be necessary to invent a consistent visual "vocabulary" in their presentation, to communicate their relationships and states consistently at different times. The GUI objects will then need to be rendered so that they are understandable and appealing.

Conclusion

Clearly, UCD can and should apply to the design of the middleware user experience. In some cases, the emphases and methods may differ from those used when applying UCD to typical end-user experiences. But the two have in common the goals of creating products that are easy-to-use, useful, and engaging to the target audience. Applying UCD to the MUE should become standard practice, leading to the increase in the ease-of-use of middleware products for all of their users.

References

Sobiesiak, R., Jones, R.J., and Lewis, S.M. (2002). DB2 Universal Database: A Case Study of a Successful User-Centered Design Program. International Journal of Human-Computer Interaction, 14(3&4), 279-306.

Vredenburg, K., Isensee, S. and Righi, C. (2001) User-Centered Design: An Integrated Approach. Upper Saddle River, NJ: Prentice-Hall.

Adam Clow is a user experience architect and team leader at IBM, working on middleware products at the Hursley laboratory in the UK. He leads UCD teams responsible for the user experiences delivered by the commercial messaging products developed there, such as Websphere MQ™ and Websphere Business Integration Message Broker™. His background is in human factors, user interface design and user feedback. Prior to this, he worked in a similar role on services engagements for IBM Global Services, primarily in the utilities industry. During 20 years at IBM, he has had experience of many different aspects of the software development cycle, through roles in business analysis, development, test, training and operations.