Forums

XXV.2 March-April 2018
Page: 71
Digital Citation

Flying from the pigeon hole: Moving beyond methodological expertise in product-development orgs


Authors:
David Siegel

back to top 

Until the day my mother died, she maintained that she could not understand what I did for a living. Yes, she had heard my elevator pitch about helping to make technology more useful, easier to learn, and more natural for people to use. But this attempt to concisely summarize my work is actually pretty abstract. It could not create a picture in her mind. In contrast, it was easy to create such a picture with simple descriptions of a couple of my activities. I could even do a mock usability test with her. By reducing my work to a couple of examples of my activities, I gave her a feeling of understanding. As soon as I said, “But it’s more than that,” I lost her.

back to top  Insights

ins01.gif

It occurs to me that, as a profession, UX researchers face the same challenge in industry and respond the same way. To be successful in an organization, other people have to be able to “read” your role and see your behavior as consistent with it. They need to have a much more concrete image of what you do to know when to include you, and how to weigh your input in relation to everyone else’s. The idea that you are going to help them be user-centered is far too vague, and it’s also something that everyone believes they are already striving to do. As a result, you may find your role defined, or may define it yourself, around a service or method you carry out. Perhaps the easiest UX research practice for people to understand is usability evaluation, so it is no surprise that so many wear the evaluation hat.

With my mother, there were no big consequences if her partial understanding gave her a reductionistic view of me. But in our workplaces, there are significant implications, both positive and negative. On the positive side, it gets UX in the game, by creating some discrete contact points between UX and the product decision-making process. These can be plotted on a product timeline or included in a roadmap. As frustrating as it may be not to have found a channel for the wider range of contributions you could make, at least this assures some opportunity to gain serious consideration. In the realities of organizational life, this benefit is probably substantial.

On the negative side, the most obvious risk of being defined as the practitioner of a method is that it limits you to a supporting actor role. But I believe it also has deeper consequences. As an outsider to decision-making processes, you may be able to respond to requests only reactively. Others can perceive it as beyond the scope of your role for you to raise the questions you study. If you are not legitimately seen as a participant in the product strategy or design debates that generate the questions, your attempt to prioritize some questions can even be misconstrued as criticism. Indeed, you may not even have the information that would allow you to question the way in which the problem is framed.

In the end, you may hand over findings but leave evaluation of their implications to others. Thus, you become a deliverer of factoids—not an expert even on the narrow topic of usability, but rather a technician. Even your authority over technique can dwindle. I have talked to many usability practitioners who say they don’t like to report the numbers of participants who encountered a problem, since their meaning is so difficult to determine, but do so anyway because their audience expects it. Sadly, such compromises quickly become institutionalized in organizations. So, while you may be able to influence product design around the edges and may sometimes be able to influence deeper aspects of design such as information architecture, your role will be tactical and you will have a hard time influencing the deepest levels of product strategy and concept. Even delivering insights and building user empathy through foundational research is often not enough to bring you into the decision-making process. The idea that this type of research inspires others implies that you give input but others take the next step in deciding its implications and how to act on them.

back to top  If We Want Some of What They Have…

When findings don’t get traction, UX professionals, especially researchers, often express their frustration in somewhat self-serving complaints that others “just don’t get it,” or that product decisions are being made for the wrong reasons. There is an element of helplessness to this, and one of arrogance too. Helplessness because you have launched your babies (findings) into a process you don’t fully participate in, and arrogance if you tend to believe that your findings deserve to have more impact than the vast number of other inputs and considerations that shape product development, the neglect of any of which may spell product failure.

UX researchers tend to perceive certain disciplines as having power in defining the product at the strategic level and often perceive them as resistant to UX input. These others can include product management, engineering, marketing, and sometimes even design. Which disciplines depends on the organization. Even these disciplines cannot escape the struggle to have their perspectives taken into account, and any of them can feel that they are being forced to make compromises, or being dictated to, compelled to implement someone else’s vision in which they have not participated. But having power at least means they are in the wrestling match. If we want to have the influence they have in setting the strategic direction of a product, then we have to offer what they offer. Recognized expertise is certainly part of it, but being the guardians of method is not sufficient. Here are some characteristics that members of influential disciplines share:

  • They are highly conversant with the business realities. They are obviously working toward achieving the largest goals of the organization. They accept that decision making entails risk, and they appear to find ways to forge ahead in the face of risk. This sharing of risk puts them on the same team as the business leaders.
  • Others see the work they do as indispensable to the creation and launch of a product. There will be no product at all unless someone keeps the work on track, builds it, and sells it. Because their buy-in is needed to proceed, others want to get an early read on what they think. People would have a sense of personal risk in proceeding without indications of buy-in.
  • The work they do is expansive and can’t be narrowed down to a few methods. Their work scope is big enough that it requires the subdivision of a dedicated staff. They do so much work that others are far too busy to take it on themselves. They don’t just submit reports when asked, but also produce the basic planning documents, roadmaps, requirements documents, status reports, production plans, and overviews.
  • They keep things moving forward. They build on the basis of partial answers, and they tend not to revisit questions that are perceived as having been resolved well enough to take the next steps. This is the fatal flaw in the hope that UX researchers fall back on: that by revealing the problems in product decisions when it is too late to correct them, they will train organizations to involve them earlier next time.
  • They do not just represent their own perspective, but rather synthesize multiple perspectives. They don’t just show up to offer input at other people’s meetings. They convene and set the agenda for cross-disciplinary meetings. They are constantly in contact with and ingesting information from multiple other disciplines—they are key nodes in expanding networks. They take charge of the process of gathering others’ input on influential documents, and take ownership of the documents.
  • They produce things that get incorporated into others’ production.
  • Their leadership broadens its focus from the current feature or product to the product as a whole or to a family of products. They share resources or negotiate across product teams.

ins02.gif

back to top  ...Then We Have to Do Some of What They Do

If this sounds daunting, then you may be thinking that UX research is inherently limited to an advisory role. Maybe we are fundamentally like auditors, QA, risk-management specialists, compliance officers, and the many other supporting roles that exist in organizations. I think not, at least not inherently. That would be equivalent to saying that disciplined practices focused on developing deep understanding of users and customers, their interactions with your products or products like yours, and the aspects of their lives and contexts most relevant to the space your products hope to occupy, don’t have a place in determining product strategy and concept. Here are some ways that UX research can emulate the behaviors of core team members and make our contribution indispensable to product strategy:

  • Become the consolidator of information about your audience from all sources. Do not just collect the results of your own research activities, but also track and analyze data from market research, support calls, satisfaction surveys, and customer feedback and complaints. Get active participation from partners in these other branches of the org structure in pulling together and reviewing this data.
  • Publish a regular digest of this data, synthesize trends in its content, and propose interpretations of its implications for issues that other groups care about. Highlight the complementary strengths and weaknesses of the data sources. For any findings that are surprising or troubling to any stakeholders—and even for those that are overly reassuring—propose hypotheses to account for them and follow-up research to make sense of them. Keep your audience eager for the next installment by maintaining continuity across publications. That is, continually assess progress with regard to issues you have identified.
  • Build synergies across projects. Identify strategic themes that cut across tactical problems. Identify persistent UX challenges applicable to technologies like yours, and track and evaluate your own company’s approach to them as well as other evolving industry models. Identify cross-product design patterns and synthesize findings about them across projects and products.
  • Build a better partnership with design. Design is closer to production than research is, but has its own struggles in becoming a full participant in strategic decision making. Help design live up to its principle of being an ongoing process of experimentation. Collaborate with designers in developing and testing hypotheses about core design challenges, generating alternatives, and evaluating them. Become an active partner with designers in making the case for novel solutions. Help design resist the appeal of the local maximum—expedient solutions to immediate problems that cumulatively damage overall design integrity.
  • Help your organization stay mindful of the big picture even while doing tactical research. Scope your research a level higher than the research question that is posed to you. For example, don’t simply test the usability of designs for a new feature without also evaluating the impact of the new feature on the overall information architecture.
  • Become a trusted problem solver. Don’t surface problems without pointing the way to alternative solutions. Make sure that your solutions take into account the types of constraints that everyone else is wrestling with, so your suggestions are not easily dismissed and you don’t appear clueless. Simplify problems more and complicate them less. Propose more efficient and elegant (i.e., easily engineered) solutions than what others may assume are necessary.
  • Make concrete, formal contributions to product definition. Use your insights to propose UX requirements that can be incorporated into a formal design brief. Join the fray of critiquing draft product requirements documents and contribute to sections of them. Help UX contribute to resource scoping. For example, development work for UX is almost always under-scoped. Product teams quickly envision ways in which they can deliver the functionality, while assuming UX will take care of any “mental model” problems. Meanwhile, UX tries to design solutions based on a reasonable mental model, assuming that developers will solve obstacles in the data structure. Often, a very brief period of design exploration as part of the earliest planning process could be enough to provide an order-of-magnitude estimate of the resources that will be needed to bridge this mental-model gap to different degrees.
  • Help product strategists manage the life cycle of the product, from introduction to full adoption. Target research and recommendations at issues such as: How will the user discover value initially? How will that discovery promote engagement over time? What UX challenges will users encounter with deeper and more widespread engagement extending to other user segments? How should the continuing development of features and increasing power of the product be phased to best support progressive adoption, while also allowing the team to manage the inevitable increase in UX complexity along the way? Help anticipate and plan for the time when the product will reach the limits of its scalability—for example, an information architecture that makes sense at one phase will inevitably break down as the product grows, but organizations are often slow to acknowledge this until the product has become a Frankenstein. Partner with design to help your company recognize when this point is approaching and prepare alternative models for the next phase of growth.

back to top  Are We Up to The Task?

This sounds like a lot of work, and the range of skills it requires calls for a team effort. To begin, you probably have to piggyback strategic activities on top of your tactical responsibilities. Not all UX researchers are prepared to move beyond their tactical roles, and the disciplines that feed the profession (e.g., computer science, cognitive psychology, anthropology, market research, schools of design) are generally not educating people in the realities and complex dynamics of the product-development environment or how to function in it effectively. On the positive side, engaging in just a few of these activities can be enough to create a virtuous cycle, where you are likely to be invited in more broadly. UX researchers who make a start in taking on any of these practices are likely to kick off a process of making UX sensibility a more central factor in product strategy.

back to top  Author

David Siegel has been a UX consultant, author, and trainer since the late 1990s. He took time off from his independent consulting practice for a four-year stint at Google, where he served as lead UX researcher for Google’s internal CRM, supporting its thousands-strong sales force around the world. davidandrewsiegel@gmail.com

back to top 

©2018 ACM  1072-5520/18/03  $15.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 © 2018 ACM, Inc.

Post Comment


No Comments Found