Design Research
Customer or Citizen?
By Andrea Moed
Industry vetted user-centered designers making a transition to public sector projects must consider our craft in a new light: relative to government’s traditional means of knowing people.
As a Silicon-Valley-based design researcher for nearly ten years, I have helped private sector companies better understand their users by conducting stakeholder interviews, ethnographic fieldwork, usability testing, etc. In that time, I’ve learned that private-sector companies conduct design research for two main reasons: first, they want to find usability problems that might reduce their revenues; second, they want to better anticipate their current and potential customers’ needs and desires. Relatively few private sector companies genuinely want users directly involved in the co-creation of their products and services1; most would rather understand their users’ behavior and leave the design of their products to designers themselves. In short, their approach—the general approach to user-centered design in the private sector—involves more of an “observation of” than a “dialogue with” end users2.
In 2013, I joined the civic group OpenOakland and was pleasantly surprised to meet civic technologists who were not only interested in determining their website’s usability, but were also interested in hearing ideas from their users about what they should build next. Hearing this sentiment renewed my longtime interest in participatory design (a practice also known as community design or co-design3). In Silicon Valley, I occasionally conducted studies where participants sketched their ideal versions of products after trying the company’s current design. But interacting with members of OpenOakland reminded me that participatory design has had a venerable history in the public sector—some of which I’ve experienced firsthand, in fact: In 2002, I attended a 4,300-person town hall called Listening to the City that convened residents of New York City to determine what the City might build at the former site of the World Trade Center.
Upon further thought, I recalled Tim O’Reilly’s description of “systems designed for contribution” as “architectures of participation”. I wondered how I might combine my experience in industry with some of the ways in which governments typically solicit citizen input to form the basis for new architectures of participation, architectures in which those for whom civic technologies were being developed—including those users who wouldn’t self-identify as “tech savvy”—could have a say. This quest, and the support of OpenOakland, has led to the creation of a citizen user testing group, or “CUTgroup4,” in Oakland. (A CUTgroup is a group of local residents who are paid to test civic apps and digital services.)
In the remainder of this article, I’ll recount the ways in which three experiences have informed our community’s plans for its CUTgroup in 2015: From the 2002 Listening to the City event to a participatory budgeting process (also in New York City) to Dan O’Neil’s original conception of the Chicago citizen user testing group. Throughout the article, I’ll highlight guiding principles I’ve taken from each of these experiences, both with regard to carefully observing user behavior (a practice favored by user-centered designers) and with regard to providing a forum where people might deliberate amongst themselves in order to co-create services of public value (a democratically favored practice).
Case 1: Listening to the City
Participatory design has long been associated with public space planning. Since at least the 1960s and ’70s, urban planners and activists have recognized that although their work directly affects everyone in a community, most people lack the technical knowledge and/or requisite vocabulary to clearly articulate their needs and desires5. In response, urban planners have sought to develop increasingly accessible facilitation exercises to meaningfully engage citizens in the co-creation of public spaces.
The events of 9-11-2001 in New York City motivated some of largest and highest-profile participatory planning processes yet seen in the United States. In 2002, I attended Listening to the City, a giant town hall at Manhattan’s largest convention center. Over 4,300 members of the public engaged in small-group discussions that lasted several hours.
Listening to the City was highly structured and carefully facilitated. Participants at each table were shown six designs developed for the World Trade Center Site and asked to share our thoughts6. We responded both verbally and through personal electronic keypads. We discussed alternatives. As we talked, notes from each table’s discussion were transmitted to a central station where “theme teams” synthesized ideas and displayed them on huge projection screens.
The technologies supporting this experience were novel in 2002, and critical to doing participatory design at this scale. From my perspective as a user-centered designer, though, Listening to The City looked more like a focus group than a design research session. When poll results made clear that the existing designs weren’t faring well, for example, some participants opted to share their own.
The scale and conception of the event (i.e., as a community response to 9/11) also appeared to motivate participants politically. One participant said “I came here to represent my family, my nation and my organization7,” while another explained “I wanted to give back to New York what New York has given me8.” This is the opposite of the way design research is typically perceived: As an exercise in sharing one’s personal perspective in using a product or service.
Guiding principles: Many people have selfless, community-oriented reasons for engaging in participatory design. This is different from commercial research, where participants feel obligated only to give their opinion insofar as it relates to their own wants, needs, and behaviors.
Case 2: participatory budgeting
Like the participatory planning of public spaces, the participatory budgeting of public funds has many variants. I will focus on the method currently being practiced in New York City9.
New York City’s participatory budgeting process takes place over a one-year period. During that time, citizens allocate over $25 million in capital funds across 24 City Council districts. The process begins by having residents submit ideas for projects (e.g., park improvements, computers for a local school, installing street lights, etc.). Notably, ideas are gathered across multiple channels: Individuals may submit them on the project website or at volunteer facilitated public meetings. Ideas are then presented back to residents in order to solicit feedback. Finally, all residents in the district can vote on which ideas to fund.
New York City’s participatory budgeting process is similar to the “Listening to The City” event in that both initiatives were designed to make the co-creation of public services more broadly accessible. The process differs, however, in key ways: The proposals under discussion all come from members of the public; the process results in not just recommendations but actual allocations of funds; and there’s a direct path from the outcome of the design exercise to policy.
Guiding principles: Many of those who participate in budgeting will propose solutions and make space for them. Those who plan participatory design events must make space for people who have not previously self identified as advocates; these individuals will require room to generate their ideas, detail their specifics, and develop support. Some attendees see participatory budgeting as a platform for advocacy; it’s therefore worth separating the ideation phase of the process from the advocacy phase.
Case 3: Chicago’s CUTgroup
Established in 2013, Chicago’s CUTgroup consists of a group of residents who’ve indicated their interest in participating in the paid testing of civic apps. CUTgroup members are called upon whenever a team of developers wants to test their app.
Unlike the previous two examples of participatory design, the CUTgroup primarily evaluates services that already exist (rather than those being proposed or planned10). This, in turn, fosters a direct interaction between the makers of the software and the community members who comprise its intended audience. In usability testing sessions, developers observe and take notes as users try their apps; in discussion sessions, developers discuss their design choices and listen to user opinions.
This is a departure not only from public participatory design methods, but from traditional design research methods as well. Until recently, it was widely believed that designers and developers should not run usability tests of their own software because their bias as creators would cause them to ask leading questions of users and be less open to perceiving users’ difficulties. Reports of early CUTgroup sessions seem to indicate otherwise: both creators and users appear to benefit from interacting directly. Creators get feedback and observe problems first hand, and users get to address the people who can improve their experience. What’s more, the power dynamic is changed from one that privileges test proctors to one in which creators and citizens meet as equals11.
Guiding principles: CUTgroup’s principal organizer, Dan O’Neil of Smart Chicago Collaborative, has written that CUTgroup is part UX research, part community organizing, part digital skills training, but not fully any of those things. In practice, this means that organizers have the freedom to balance the immediate objectives of participants and those of developers. User-centered designers beginning to work in civic design should seek out developers who want to forge collaborative relationships with users (as opposed to those who just want feedback).
Observations and open questions
Public participation is moving from the aspirational to the practical, with an increasingly clear path from ideas and discussions to outcomes. The people responsible for implementation are increasingly present, and the cost and effort to convene these meetings and generate results is dwindling.
Participation is not quite its own reward, it is a means to shared ownership of public products, services, and spaces.
Aside from this, what’s clear in each of the cases presented above—and what’s very different from the commercial world—is a unique motivation: a sense of civic duty. Unlike commercial user research, many of those participating in public sector user research don’t seek a simple exchange of feedback for rewards (i.e., a transaction). Instead, participants are motivated by a mix of activism and altruism in addition to any incentives offered. While participation is not quite its own reward, it is a means to shared ownership of public products, services, and spaces.
Open questions
Throughout this article, I’ve suggested a few guiding principles for those who wish to elicit public participation in the design of public-sector products, services, and/or spaces. Those same principles, however, also imply questions that civic designers must address.
- Recognize that many people show up to speak in the name of others. How can we be transparent about how participants are selected? How can we better encourage all members of the public to participate?
- Recognize that many participants bring their own proposed solutions, and make a space for both ideation and advocacy. How can we identify and route around the fact that our data will be naturally biased toward more vocal and opinionated participants?
- Mix one-on-one user observations with group discussion. How can we effectively observe users and identify places where designs meet cognitive limitations without seeing users as passive?
The aims of those who design citizen experiences are often broader than than those who design customer experiences. Citizen experience designers seek to improve a user’s experience of a product or service while also empowering users to ask more of their government. We may even want to help them rely more on one another. Satisfying this mission will require a new approach to learning from those we serve. Our activities will need to draw upon the methods of commercial design research and traditional, democratic means of public engagement—and to know when to emphasize each.
Footnotes
-
There are some notable exceptions in which businesses have co-created products with their customers. See Satish Nambisan and Priya Nambisan, “Engaging Citizens in Co-Creation in Public Services.”
Return -
This may be changing, at least with regard to companies in the social media business. The backlash against experiments on behalf of Facebook and Instagram indicates that many of their users want a dialogue about the terms of use.
Return -
In participatory design, users play a hands-on role in the creation of products and/or services they might eventually use. This approach often generates both viable design ideas and greater empathy for users on the part of designers.
Return -
A CUTgroup is a model for testing civic apps that was recently developed by people over at Smart Chicago Collaborative. In a typical session, a development team creating a civic application meets with a group of citizens who will likely use their app. There is group conversation and also a period where the users get a chance to try out the app for themselves as developers observe. The creation and early activities of the Chicago CUTgroup are documented in The CUTgroup Book.
Return -
This is a situation resulting in linguistic insecurity, or “feelings of anxiety, self-consciousness, or lack of confidence in the mind of a speaker surrounding the use of their own language.” (Wikipedia)
Return -
Subsequent press coverage focused on participants’ largely negative reaction to all six proposals, treating the event a bit like the test screening of a movie in which the audience hated the ending.
Return -
Civic Alliance to Rebuild Lower Manhattan, “Listening to the City Report of Proceedings.”
Return -
Ibid.
Return -
I have not been involved with this process, but studied it as inspiration for Open Budget Oakland, a local civic website I have worked on.
Return -
CUTgroup session formats vary: while some sessions consist of a central presentation and a group discussion, others follow the model of a typical usability test. For an example of a group discussion centered CUTgroup session, see the documentation of the Foodbourne Chicago test.
For an example of a moderated user test, see the test of the EveryBlock app.
Return -
While the problem of developer bias still exists, it is certainly offset by these benefits. It can also be dealt with by training the developers to adopt a more neutral point of view.
Return
Like this kinda stuff?
Consider donating to help us to continue doing this work! We also encourage reader comments via letters to the editor.