sword in the stone   Hayne of Tintagel
HCI  /  Software Engineering for Usability

Software Engineering for Usability

Prev section Next section Top of document

7. Organizational and sociological difficulties

We have known for a long time what is needed to make a good user interface, and developers have many effective techniques at their disposal - so why are bad user interfaces still being produced ? Gould and Lewis wrote that the principles (of section 5.2 above) "are hard to carry out, mainly for organizational and motivational reasons". (Gould and Lewis 1985) It is pointless to introduce a good process in a company without first making sure that the organization and the individuals are ready, willing, and able to carry out that process.

Jonathan Grudin reports on some problems that he observed in the context of commercial product development:

"... the business operations and development practices of most of today's large product development companies were formed when hardware and software functionality were the only considerations. It is not surprising that their basic organizational structures and processes do not facilitate interface development. In fact, we will see that the design and development of good interfaces are often systematically obstructed -- not intentionally, but obstructed nonetheless." (Grudin 1991b)

7.1 Organizational partitioning

"... contact with customers and users is the province of groups or divisions outside of development: sales, marketing, training, field support, and upper management." (Grudin 1991b)

"The development company's sales representatives may be reluctant to let developers meet with customers. A developer, coming from a different culture, might offend or alarm the customers or create dissatisfaction with currently available products by describing developments in progress. Similarly, the marketing group may consider itself the proper conduit into the development organization for information about customer needs and fear the results of random contacts between developers and users. In one company, developers, including human factors engineers, were prevented from attending the annual users' group meeting. Marketing viewed this as a show staged strictly for the customers." (Grudin 1991b)

In one typical company whose development process was studied by Poltrock and Grudin, the development plan goes as follows:

"Marketing defines product requirements ... based on information about customers' needs acquired directly from customers and indirectly through field support. Marketing communicates these requirements in the form of specifications to a Design group. ... The Design group interacts with customers as needed to produce a specification of a high-level product design. ... A group of software engineers within Development designs the interface based on specifications from the Design group ..." (Poltrock and Grudin 1994)

This process exhibits a few common problems. First of all,

"Marketing's primary role is to determine what is needed to sell systems, not what is needed to make systems usable. ... Marketing's contacts are with the customers' management; Marketing rarely communicates with users or with field support about users' needs." (Poltrock and Grudin 1994)

Note the difference between customers and users:

"A customer is generally a company or other organization that purchases the systems, but the customer is personified in the managers responsible for the purchasing decisions ... Users are the people who actually interact with the product ... " (Poltrock and Grudin 1994)

Since the primary means of communication is formal specifications documents, there is an inevitable degradation of useful information as it passes along the chain. One user of the product complained to a member of the Development group:

"I have to talk to Marketing, who really sometimes don't have the foggiest idea what I'm talking about. They pass the information on as best they can to the Design group, who might not have any idea what Marketing is talking about either, ... And then it gets to you guys, and you have no idea what it is about; you don't know where it came from, and you don't know how to contact me." (Poltrock and Grudin 1994)

It is worth noting that at this company, some developers started meeting informally with people from field support. The information they obtained this way was invaluable in making interface design decisions. And in a experiment, it was found that people from field support were far more effective in finding bugs than the systematic testing by the Quality Control group -- the field support people tested the product by using it as they imagined that users would.

One of the most interesting things about this company is that a previous release of the product had been much more successful in meeting users' needs. It turned out that this previous release had been designed and managed by a "super designer" who (with the support of the vice-president) "bypassed the usual management chains of communication, personally talking to each developer daily ... Describing this coordination task, he said, `I ran around like a living information system' ... ". The idea of having a "super designer" recalls Brooks' "chief programmer" recommendation. (Brooks 1995)

I note that some companies have their developers answering the technical support line - this gives the developers at least some contact with the real world of the users.

7.2 Different personality types

"Some engineers lack empathy or sympathy for inexperienced or nontechnical computer users. When developers and users meet, they sometimes find that different values, work styles, and even languages get in the way of communicating. Developers tend to be young, rationalistic, and idealistic, products of relatively homogeneous academic environments. They often have little experience or understanding of the very different work situations and attitudes of many system users." (Grudin 1991b)

"Developers are often motivated by seeing videotapes of users struggling with their product, after a brief period of blaming the difficulty on the users. (`I have a problem with this,' one development manager interrupted a screening to say. `My problem is, I'm watching a moron.' But after being told that the person had worked for the company for 5 years and that a majority of testers had the same difficulty, the manager was soon enthusiastically proposing interface changes.)" (Grudin 1991b)

In a project for scientific collaboration, a suggestion was made to include a way for users to see who else was logged in to the program. The programmer implemented this as a button labeled "Finger" (which makes sense to UNIX experts). "This is a case of an interface designer making a suggestion, and a programmer hearing the suggestion in his own language, rather than that of the users." (McDaniel, Olson et al. 1994)

7.3 Conflicting goals

Grudin points out that developers are driven my many different and often conflicting goals. Some examples:

"... one design may be chosen because it is easier to describe and communicate" (Grudin 1991b) (A better design might be known but be too hard to describe in a written document.)

"A major barrier to rapid advancement in interface design is that a hallmark of good software design--modular code organization--works directly against a hallmark of useful user support--knowledge of context." (Grudin 1991b)

"Apart from the effects of carelessness, neglect, and ignorance, the most common source of poor interface design is probably the natural tendency of developers to map elements of the underlying software architecture onto the interface. This is useful for developers: If the interface reflects the underlying design, only one model of the system must be kept in mind. But users arrive with a model that does not correspond to the software architecture, so they are forced to acquire a second model of the system." (Grudin 1991b)

Goal of recognition of developers' efforts: developers like to see their part of the software visible on the interface; marketing wants to emphasize new features - usability concerns are not considered.

Making a user interface design understandable to management (e.g. with a prototype) may be seen by developers as not in their best interests. Grudin says:

"The visibility of an interface brings it to management's attention. One developer commented, "If you put up an architecture model, not many people will come back and comment... But if you actually put up screens and ask people to comment, everyone from the managing director down has their own personal idea." (Grudin 1991b)

Grudin's summary:

"... the high visibility and growing importance of the interface works against iterative design in three ways: (i) the interface is grouped with aspects of the product that must be "signed off" on early in development; (ii) other groups, such as those producing documentation, training, and marketing, are strongly tied to the software interface and affected by changes; and (iii) iteration or change in the interface is noticed by everyone, which can create uneasiness, especially in an environment with a history of stressing early design." (Grudin 1991b)

Grudin's conclusion:

"The software development process is one of constant compromise. Tradeoffs are forced by conflicting engineering considerations, management decisions, and product marketing constraints. ... Designing and building a quality interface is always a goal, but it is just one of many. In the absence of a strong case for particular choices, aspects of the interface are undervalued when the tradeoffs are resolved." (Grudin 1991b)

7.4 Marketing concerns

"... some people fear that by exposing features and functionality that are under development, user involvement can discourage customers from buying the current product version, create false expectations if features are not implemented, risk legal rights to software patents, and give competitors information about product plans." (Poltrock and Grudin 1994)

7.5 Corporate Culture

In a panel discussion at the CHI'94 conference, Leela Damodaran said:

"The validity of trying to moderate the adverse consequences of mechanistic and technocentric design methods is the issue here. A 'human-factored' design method under the control of an IT-focused project manager, who is driven by tight deadlines and stretched resources, is no more likely to deliver a user-centered system than would be the case with classical Tayloristic methods. Nothing short of 'institutionalising' HF into every aspect of organisational life will actually have the desired impact on the quality of IT systems developed." (Long, Hakiel et al. 1994)

Poltrock and Grudin say:

"Iterative design also faces a fundamental historical engineering challenge: the success of non-iterative design for many noninteractive systems." (Poltrock and Grudin 1994)

This success has led to development processes and corporate cultures that make usability engineering difficult. However, there is hope for the future:

"We see positive signs that in some companies younger than those described here, virtually all employees take usability seriously." (Poltrock and Grudin 1994)

Prev section Next section Top of document