Be Annoying
In research I conducted last year with Cheryl Abellanoza, we found that when individuals recall their experiences of vehicular crashes, they spend a lot more time describing the period after the crash rather than detailing the event itself. These descriptions covered the span of days, weeks, months, and, sometimes, years. People described a variety of things: fear about returning to their commute; stress of dealing with insurance; pain during physical therapy; anxiety due to tension with their spouse and family; self-doubt related to their judgement. Characteristically, these descriptions jumped from topic to topic and moved back and forth in time. Cheryl and I referred to these descriptions as the longview of crashes, or, for short, the longview.
When we initially presented the research, folks listened and nodded: “Yeah, that makes sense. So, anyway…” This was not to say people did not care. Instead, people did not know what to do with it. The longview did not fit well with how teams were organized, what products were offered, and what we and others expected from this research. Instead, the longview felt complicated and complex. However, no matter what I did, I kept coming back to the fact that the longview was both important and vital to understanding the experience of a vehicular crash. Still, like those I was presenting to, I was unsure of what to do exactly. I could not let go of what I had heard, and I wanted others to know that.
So, I decided to, as Mayank often suggests, be annoying.
Every opportunity I had, I brought up the longview. Someone would say, “I want the nugget. What feature do we make?” I would respond, “It’s more complicated. Listen to what this person told us about discussing finances with their spouse.” When conversations moved in directions that did not support what I had heard, I would draw them back — “A crash is more than the crash. Let me explain.” I stuck with it and people definitely were annoyed — I was making things complicated and complex. At the same time, they started to listen because they could not ignore it. Folks began to take up the idea, and the longview of crashes became a way of thinking about crashes and safety rather than a feature, need, or nugget.
Enumerable articles, books, posts, tweets, comments, and think pieces on the topic of product development state that users are the key to developing innovative products. Regardless of the source, a similar arc is traced:
To make good products, companies — and the people therein — need to understand how, where, when, and why products get used. This understanding is necessary because people often use products in unexpected ways and for unexpected reasons, and, more often than not, the people within a company assume a great deal about the motivations, contexts, circumstances, and lives of the folks using products. These assumptions, when unchecked, become embedded in products that do not meet the right needs. In short: the user is not (like) you, employee of Company X, so go out there and talk to them!
In many ways, the sheer volume and dispersion of this narrative is exactly why researchers (such as myself) have a place in product development cycles and on user experience teams. And, as thankful that I am to have a place and position, I roll my eyes at these at these remarks, in part, because they often ignore the very contexts, circumstances, and people through which such understanding is dispersed. Although a company may echo the refrain of “users are the key”, that same company may be organized in ways that people, resources, and visions do not align well to what users are saying. In many ways, my experience with communicating the longview to various teams stemmed from this tension between understanding users and operationalizing this understanding.
In fieldwork I did a while back, I documented this tension. I watched multiple teams coordinate distinct budgets to support a single user need. This coordination was clunky and difficult, and ultimately underserved the goal. Even though these employees understood the importance of listening to what users were saying, they battled against their organization — specifically the process of zero-based budgeting. These teams were not able to act on these insights not because they did not understand users, but instead because understanding was—and is—not enough. In general, I think a gross majority of people working in product development everywhere have bought into the idea of understanding users, but many product development environments still struggle to mobilize this sort of understanding in resources, personnel, processes, budgets, and egos.
Now, strategies do exist: lean product development and jobs to be done are two such strategies that aim to reorganize product development. I have witnessed both of these strategies first-hand, and they work in the right workplaces. However, they overlook an important aspect. Missing from these strategies are discussions of what it feels like to advocate for users when people and organizations are less than receptive. So what does it feel like? Well, it can feel very annoying; that is, it can feel like I am being very annoying.
Though not the only answer and far from a complete one, one way to push past the tokenistic role of users or organizational inertia is to reiterate insights and stories over and over again. But being annoying is — as anyone who has ever been annoyed before knows (so everyone) — more than hearing the same thing over and over again. Being annoying is affective: it is the way hearing the same thing over and over again provokes action. Alright already!
So, how might you be annoying in your organization? Being annoying is about doggedness, persistence, and advocacy, as well as accepting the discomfort of pushing against the tide. But being annoying does not mean being incompassionate or disrespectful to your colleagues. Instead, to be good at being annoying, you need to use each interaction as an opportunity to refine the message without losing the meaning. That means, to be annoying, you need to know who and how to annoy without pushing someone too far.
Written by Thomas Lodato, PhD
Thomas is a Senior UX Researcher at Verizon Connect. He’s an alum of the Georgia Institute of Technology, where he focused on the future of work. At Verizon Connect, he specializes in being annoying with ethnographic methods. He feels most at home on inline skates. For more, follow him: @thomas_lodato
