Power to the People

The mindset for designing software has evolved considerably over the last several decades from being developer centered to a much more user centered approach. This evolution was, perhaps, partially driven by the successes of ethnographic research that was being conducted in other industries when designing products. The transition to the computing realm seemed only natural as the ubiquity of consumer computing grew, and was moved along even quicker given the incredible uptake of internet applications. Due to the high reliance of users on various applications in different parts of their lives, the need for more usable interfaces became an urgent concern. However, developers were ill trained in usability practices and thus were unable to create interfaces very well. Having a team of designers work on the GUI seemed like the answer, but even then there were inadequacies with the resulting product. The contextual design (CD) methodology was formed to address all these issues and come out with products that were designed specifically around user concerns. The results from projects designed with CD in mind are often very positive, and embrace many aspects of user and participatory design.

As Blomberg & Burrell pointed out, ethnography was brought into the spotlight when the internet boom made creating software for home consumption a big business (1). This brings up an interesting point: why was ethnography and contextual design not as utilized when software was created mostly for business use? Are business users more prone to accept bad UI? The argument could be made that since business users are locked into whatever software the company is providing (be it internal or external) they have no other options or anything to compare it to, no matter how frustrated they are. The company may have chosen the software because of cost, compatibility or any other business reason. In addition, after a certain amount of time, the users likely adjust to the unintuitive interface and system structure, and are forced to accept the strategies and workflow as they are (2). Another argument is that the business user is easier to design for due to the fact that they are more predictable than the wide array of different home users. The tasks and different ways home users use a given program may be much more diverse than the comparatively rigid structure of a company. In most companies many processes are very defined, allowing for much easier analysis, and not necessarily requiring an entire ethnographical study.

Ethnography, in the context of HCI, is a study aimed at identifying opportunities for enhancing experiences (1). Contextual design, on the other hand, can be summed up as the approach to designing software based on an understanding of how the customer works (2). Combining these two practices in designing software has one colossal effect on the project: users are involved at nearly every point. The concept is simple: if you don’t understand what the user does, it doesn’t matter how visually appealing the interface is, the end result will fail to meet the user’s needs. To that end, contextual design a major theme: you need to understand what users do. In this regard, the user is the expert. However, an interesting contradiction appears when one attempts to put this idea to use. It turns out the user is actually often unable to convey exactly what it is they do (3). They give an impression, which in many cases is inaccurate. Because of this, the best way to understand exactly what a user does, is observation. There are different schools of thought on how this should be done: one observer, multiple observers, camera, audio or a combination of several of methods. There are certainly pros and cons to each method, but an interesting rift appears between in person observation, and more passive methods such as video recording. Are user responses and behaviors going to be different if they are observed in person or on film? If so, the passive method would produce a more pure representation of the tasks the user performed, even more so if the user wasn’t informed of exactly when the recording was occurring (ethics concerns naturally surface with such a scenario). The same concept applies to when speaking with people in follow up interviews/debriefs. When in person interviews are involved, users tend to not always tell the entire truth due to being uncomfortable or overly privacy conscious (1). Would a phone interview relieve the pressure and increase the comfort of the interviewee? Would not personally knowing the interviewer put the user at ease and allow them to open up more? If this were the case indirect interviews would seem to be more useful, though the visual element present in face to face interviews would be eliminated, so the best method would need to be evaluated on a case by case basis, perhaps with input from the user.

In interacting with the users through the design process, the goal is to get a grasp of what they do and if there already is a current system, what inadequacies they face with it. When this information is gathered through observations and follow-up interviews, the design team needs to analyze it, and then develop some conclusions. With these, the team can proceed to what Holtzblatt refers to as ‘visioning’ (4). Visioning refers to inventing solutions given the context of the larger practice. With all the information gathered through the observation phase, the design team should have a grip on what the user does. At the visioning stage, the team comes up with a way to modify the way the user goes about their task to incorporate new ideas. Holtzblatt stresses that this stage does not include interface choices (4). This is meant to separate the interface from the actual functionality of the application, allowing the team to perfect the actual functionality before moving onto the GUI that will drive the application.

As the popularity of home computing grew, so did the need for the software presented to consumers to be well thought out and implemented. As Hugh et al. point out, developers are not good at understanding how people work; they write code and design system implementations (3). As such, having them be the only ones responsible for the usability aspect of software made very little to no sense. The users are the ones who know exactly what they do, what workflows they follow, and what problems they encounter. Because of this, involving them at every point in a software project is vital for the end result to represent something a consumer would find useful. Only with user involvement can design teams take workflows and feedback and turn it into software that makes sense for the user. In hindsight, it is unclear why the ethnography and contextual design movements didn’t grab hold earlier. One thing is certain, however: after years of bad software design, it is good to see companies finally recognizing their customer base for the invaluable resource that they are.

Works Cited

1. Blomberg, Jeanette and Burrell, Mark. An Ethnographic Approach to Design. [book auth.] A Sears and J Jacko. The Human-Computer Interaction Handbook: Fundementals, Evolving Technologies and Emerging Applications. New York : Taylor & Francis Group, 2008, pp. 965-988.

2. Contextual Design. Beyer, Hugh and Holtzblatt, Karen. 1997, ACM Interactions, pp. 32-42.

3. Beyer, Hugh, Holtzblatt, Karen and Baker, Lisa. An Agile User-Centered Method: Rapid Contextual Design.

4. Holtzblatt, Karen. Contextual Design. [book auth.] J. Jacko and A. Sears. The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. New York : Taylor & Francis Group, 2007.