Blogpost

XVIII.3 May + June 2011
Page: 10
Digital Citation

Killing off user-centered design


Authors:
John Zimmerman

Over the past few years, I have heard many proclamations and complaints from IxD/HCI practitioners and researchers that make me feel we have lost our way, that we have drunk a bit too much of our own Kool-Aid.

I am the user’s advocate. I fight with the developers and managers to make sure the users get what they want. That’s my job. —UX designer #1

The UX designers here make great designs. But no one listens to our ideas. We keep explaining why we need to design for the user’s experience, but nobody cares. —UX designer #2

I know the user is not me! It would be unorthodox, inappropriate, and impure to draw on my own personal use experiences. —HCI researcher/practitioner

We do interaction design all wrong in my company. We almost never go out and conduct field studies on users before we start to redesign a product. —UX designer #3

When I hear these statements, I feel like I have failed. It’s time to drop the Sharpie, set the sticky notes down, and stop sniffing the dry-erase markers.

To understand how we have gotten so far off track, I want to go back in time, to the early, early days of interaction design. These were golden times when computers moved into the office; when we investigated work practices and then replaced workers with computational systems that automated them out of a job. Ah, what happy users they must have been.

The earliest computers to enter the workplace were designed by engineers who had no idea what the workers did or how these systems would fit into their work practices. Thank goodness these systems mostly failed, or we would not have much of a reason to exist. Then came the mighty HCIers and interaction designers. We applied cognitive theory to interfaces, which solved many problems. And then we started to pay attention to the social aspects of work, which solved many more problems. Computers were difficult and disruptive, and we worked to make them fit.

The Scandinavians recognized the social disruption caused by computers and reacted with participatory design (PD). Here, domain experts in the workplace (workers/users), domain experts in business (managers), and domain experts in technology (techies and designers like us) worked together to socially prototype systems into existence. With the goal of democracy and protection of worker’s craft knowledge and practices, PD evolved into a type of user-centered design (UCD).

Contextual design (CD) grew out of design practices in the U.S. when much of the work was to design custom IT systems within a business. IT departments had to design and get buy-in from other departments within their own company. CD practitioners would model the communication flow to find opportunities to automate processes, and they would model the company culture to make sure their design proposals would be accepted within the organization.

In both cases the users and the client were included in the design process. So what happened? How did we forget we have a client? First, software development became more commercial. It was not IT departments making systems for internal users, but instead companies making software for other companies and individuals to buy. Second, HCI and interaction design became academic disciplines. They were taught by academics who understood the need for “user” research. However, many of these academics chose to stay in or return to school and teach so they could escape the challenges of working with clients.

When I hear UX designers complain that their company never pays any attention to their design suggestions and insights, I always ask to see the research they have conducted on their development teams and their managers. This usually leads to blank stares. But clearly these managers and developers are critical stakeholders in the design. Instead of telling them how this helps a user, why not tell them how these design suggestions and insights benefit them. We must remember to research and synthesize their needs and their culture within the process. We must go back to the past to find our way into the future.

And now, to those who claim that HCI and interaction design orthodoxy will not permit personal insights to muddy up the design process: When I hear such claims, it makes me think of the usability aspect reports I have written as “sacred texts.” This is a false, false claim and it stifles design.

Dan Bricklin combined his domain knowledge on the pain of using pencil-based spreadsheets with domain knowledge of how computers work. This is a happy marriage that leads to great ideas. PD is all about having users co-design their own tools; it’s a practice of combining tech-domain and work-practice-domain expertise. If you have knowledge of the work-practice domain, you must bring it into your design process. You must draw on your tacit knowledge to find design inspiration. There are no laws, there are no HCI police ... I’m pretty sure.

How can you do UCD without doing user research and going into the field? You can’t. But maybe you should not be doing UCD. So why do we do this? Again, this all started with engineers in labs designing work systems for workers they knew nothing about, for workers who had never used computers, and for computers that lacked a rich set of interaction conventions. That’s not the world we live in now. We are designing for users who are constantly using computers, and we have a rich set of interaction conventions to draw on (design patterns). Not every project deserves upfront user research. Let me say this again. Not every project is deserving of the time and effort of upfront user research.

Do industrial designers always conduct a study of dining before making a dining chair? No! They use their own experience and their sensitivity to design conventions to search for a balance between the comforts of convention and the stimulation of novelty. Instead of blindly following a process, we need to be more pragmatic. We need to ask ourselves, “How conventional is this product I am working on?” If the project is pushing beyond conventions or if the goal is to shake up the current state, then of course you need to go into the field and hang out with potential users. But if the project is simply to turn the crank on a website that is already working pretty well, then you need to think about your client and if the time and expense will pay off.

It is time to cast off the mantle of UCD before it makes us irrelevant. We need to return to the past and remember that we design for clients. We simply investigate users because doing so is in the best interest of our clients. I am encouraged by the growing interest in service design and its focus on the co-production of value between customers and service providers. This is a return to what we should be doing, to the work of finding rich intersections where the user’s desire and the client’s desire intersect. I don’t ever want to hear another interaction designer or HCI practitioner tell me they are the user advocate fighting against developers. Complaining will get us nowhere. Instead, we need to treat developers and managers as clients and design systems in which they easily see how their needs are being met and their desires are being fulfilled.

Now repeat after me. There is no UCD. There is only CCD, and I’m not talking about religious education for young Catholics. I am talking about client-centered design.

Author

John Zimmerman teaches and conducts research focusing on operationalizing identity and attachment theories for use in IxD, interaction with intelligent systems, and how social computing can help citizens feel like owners of their public services.

Footnotes

DOI: http://doi.acm.org/10.1145/1962438.1962442

©2011 ACM  1072-5220/11/0500  $10.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.

 

Post Comment


No Comments Found