The researcher’s journey: leveling up as a user researcher

This article was first published on the PlanGrid blog and is republished here with the kind permission of the author.

On January 3, 2011, I delivered the greatest usability study ever conducted. It was, truly, an incomparable study, with a detailed report that would leave academics everywhere singing its praise from the rooftops. For the first time, my college professors would have been proud of my work. The report was perfect: beautifully typeset in LaTeX, fully hyperlinked, and methodologically reproducible.

Wasted work: page ONE OF TWO on the report’s enlightening table of contents

This world-shattering report was delivered and then…nothing happened. Two years following this report, none of its original findings translated into product action. Anything that did change was the result of subsequent, duplicate efforts.

*   *   *

As a newly-minted researcher, the burning question of “why didn’t that work?” kicked off a six year journey that’s still pressing on. At a higher level, the question is about doing useful, effective work: “what does it take for research to positively influence product and design, and how do I do that?”

There’s no simple answer; it’s a broad interplay of dynamics involving people, processes, and structure. Effective research hinges on organizational ways of working and the team’s desire to learn (spoiler alert: there are times when it just won’t work). It also lies in your own mastery of the research process, technique, and ability to influence the team.

Here we’ll focus on the last pieces, charting the growth of researcher-as-individual contributor from junior, to mid-level, to senior researcher. To make it easier to assess your own progress, we’ll look at it along three axes:

1. [Thinking] Process mastery: ownership of the research process
2. [Execution] Technical competence: technique, method, and output
3. [Impact] Organizational influence: empowerment, alignment, and direction

*   *   *

The research process

A quick baseline: in terms of “doing research” (the defining trait of a researcher) we’re talking about execution, orchestration, or facilitation of the sometimes-linear process of:

1. Figuring out what to learn
2. Deciding how to learn it
3. Uncovering or observing evidence
4. Making sense of what was learned (“synthesis” and “insights”)
5. Deciding how to act on it
6. Ensuring consistent action

The process: laid bare

We use ownership of the process as a proxy for growth and maturity in the role. Your journey begins in the middle and slowly spreads outward to embrace the whole cycle: from basic mechanics and execution toward projects, program level initiatives, and higher-order strategy. It’s an exciting ride.

*   *   *

Junior researcher

A junior researcher starts with prepackaged questions or predefined methods and executes on defined units of work. It’s hard to understand potential outcomes when you don’t have clear experience that relates your execution to specific kinds of output. Each project is a new opportunity to build experience across contexts and methods to learn the types of things you’ll find and how they feed into product.

Junior level ownership

I. Process mastery

At this execution-focused stage, your questions around projects will focus on the nuts and bolts:

1. Who? – Target audience
2. What? – Method
3. When? – When do you want it?

When a product manager says “we should do a usability test” or a designer “needs to talk to customers,” it’s a chance to hone basic skills. Growth comes through experience and reflection, forcing yourself to ask “why do we want to do this?”, “what are we really trying to find out?”, and “is this the right way to get there?”

II. Technical competence

Every interview in and of itself can be a hurdle, and it’s hard to see the forest (project) for the trees (each instance of execution). As a junior level researcher, you must become competent in executing on the basics:

• Recruiting
• Interviewing
• Interview note-taking
• Interview debriefing
• Observation
• Data collection
• Surveying
• User testing
• Simple reporting

Research synthesis outputs are facts, incidents, and simple behavioral insights. You’re ready to move on when these basic pieces can be smartly combined and deployed to ensure a successful project.

III. Organizational influence

Junior researchers strive to empower the organization with insights, and answer on-hand questions. Your influence develops on the strength of that execution, and the sense of judgment that you hone as you learn what your users need and how they do their work:

• Credible reporting
• Fair, honest judgement of design and product
• Interaction-level and usability authority

Failure to have an impact (e.g. aforementioned report on January 3, 2011) is especially instructive: “It’s so clear to me that X is true, and I believe we should do Y. But nobody else sees it — what’s happening?” There’s an outside-in perspective flip that precedes growth, akin to the ideas underlying the practice of service design. It’s not about the great studies that you can do, it’s about finding out what the team needs to push work forward.

*   *   *

Mid-level researcher

By now, you’ve developed a sense for product and design, and can deliver strong, evidence-based recommendations. This speaks to a new level of technical competence (derive meaningful insights and connect them to design or product strategy) as well as influence (be seen as a respected, measured point-of-view and valid source of insight).

Mid-level ownership

I. Process mastery

Now your questions snap a level higher to organize projects and ensure meaningful output:

1. What? – What are you trying to figure out?
2. Why? – Why is this important for us to answer?
3. You recommend Who, What (method), and When

Facility with a range of methods allow you to assess trade-offs and select methods with a reliable sense of outcome. Understanding how projects run, you work backwards from expected outcomes and proactively plan your efforts.

II. Technical competence

From the project-level vantage point, you draw on well-developed basics in new ways and adapt methods to the project at hand. It’s here you take ownership over the project, working as a research partner to push design and product outcome. Mid-level growth in execution also extends basic reporting to employ more robust methods of synthesis and communication:

• Project planning
• Project management
• Structured design and research methods (e.g. mixed-method studies, progressive iterative research while embedded in a team)
• Complex synthesis (e.g., personas, journey mapping, service blueprinting, jobs to be done)

Mid-level research outputs provide rich insights and start to depict the important stories that ground, humanize, and build out meaningful context.

III. Organizational influence

At mid-level, you work within the organization to reframe team questions and incite action with results. You realize that it’s never enough to run a good project and deliver great insights: no matter how “true” or “logical” your findings, they will not promote themselves if you don’t bring the team along:

• Embed and partner with functional teams
• Empower other project teams to do effective research
• Reframe and focus research questions
• Develop a respected point of view on product-level decisions

Understanding what comes out of different research methods, paired with a keen sense of how the organization works, is the next step in ensuring positive product and design impact through research.

*  *  *

The shift from medium to senior level started in late March of 2015 when my consulting team delivered a scientific disaster modeling system for a client. They had tried to redesign an on-premise solution for the cloud, spending millions of dollars and two years shipping a system their customers wouldn’t accept. It wasn’t usable, attempted to do everything but could do nothing well, and it ignored pages of feedback customers felt were essential. Given the messy context of the project, I ran a user-centered discovery and testing program designed to force focus on the project and help pave the way for successful delivery.

During discovery with customer proxies and subject matter experts, we built a set of personas encapsulating the goals, needs, and workflow scenarios of the system’s main users. Within our client and with their top customers we socialized the persona “Daniel” as our primary target: we claimed that if V1 could solve for Daniel’s specific needs (without specifying how), all parties would see real and immediate value from the system. Slowly, with open lines of feedback and iteration, client and customers agreed that Daniel represented their core and most pressing needs. We aligned on a goal: if, by a specified date, our system could support Daniel’s target scenarios, the project’s first phase would be a success.

We tested conceptual and functional prototypes with the client’s customers, learning and iterating until real users could achieve Daniel’s core tasks in the system. The customers, especially non-user buyers, invariably piled on feedback outside the bounds our V1 scope (much like before). With clear alignment on Daniel’s needs, we could address feedback honestly and openly, maintaining focus in development: “Given what you’ve seen so far, do you believe [this input] would help Daniel with [goal] in [target scenario]?” The client and their customers came to trust and respect our team’s ability to act–or not–on their feedback with a clear lens. Phase 1 ended as a success.

*  *  *

Senior researcher

As a senior researcher, you leverage learning in new ways beyond specific project work. Organizations already spin off more data and knowledge (in nice functional silos) than any team can make use of — you look to unlock this knowledge, frame rich stories, and foster broad alignment. This is higher order impact at a ‘research program’ level that must also be balanced with project execution.

Senior-level ownership

I. Process mastery

At senior level, you look to the higher order purpose of every project, request, and activity, often suggesting your own project work based on perceived team needs. Your sphere of awareness shifts from a pure focus on user behavior, needs, and context, and must encompass the organizational reality that supports or stifles meaningful work:

1. Why? – What is our organizational and user impact?
2. You shape, reframe, or reject the entire process accordingly

Owning the edges of the process entails focus on understanding what the organization needs, and ensuring it leads to meaningful action. It’s work that may go far beyond the standard role descriptor of user research: your job is to wrest fruit from the garden of knowledge, but, if it’s not productive, you may need to shovel fertilizer.

II. Technical competence

Moving to the program level, ownership of the research process requires you work in regular partnership with other teams to employ projects strategically. Senior level technical competence is tied tightly to ways of disseminating knowledge, increasing alignment, and ultimately fostering higher order impact than any individual project may achieve:

• Centralizing customer feedback
• Wide audience communication & presentation
• Roadmap planning
• Framing and storytelling
• Workshop facilitation

Beyond insights and rich stories, senior level researcher output is alignment, shared understanding, and direction.

III. Organizational influence

At a senior level, your work introduces new language, shapes the organization’s thinking about users, context, work, and direct organizational inquiry to align with strategic priorities:

• Strategic partner to product and design functions
• Reshape higher-order processes
• Centralize and unlock existing knowledge
• Direct organizational research focus

This includes understanding how to use individual projects to inject structure and clarity into product development and turn learning into broader organizational understanding.

*   *   *

And beyond

As you follow the path of research, a logical extension of the function includes centralizing, framing, exposing, and continually communicating your organization’s point of view on the industry and the user’s needs in context. Empowering teams to learn on their own and ensuring meaningful compassion for users’ context and needs — at organizational scale — is the beginning of “and beyond.”

It does not, however, reduce the need for project-level execution; this will always remain a difficult balance. It may mean a strategic individual contributor role, building out a research function to take on the higher order work, or something else, entirely…

This snapshot is based on personal experience, researching researchers, related reading, and some light extrapolation. If you are a researcher on the journey, at “beyond,” or managing this journey for others, I’d love to hear about your experience.

Special thanks to Abhik Pramanik, Christiana Lackner, Chantal Jandard, Alissa Briggs, and the PlanGrid design team.