How to write a research plan that facilitates team alignment

“UX (user experience) research is the systematic investigation of users and their requirements, in order to add context and insight into the process of designing the user experience.” Interaction Design Foundation

But what if a target user hasn’t been defined? What if you didn’t know what problem you were trying to solve? How do you get started then?

Size Matters

I use to work at a mid-size company with a very niche product. When assigned to a project, I could potentially have up to three stakeholders — all people who I knew and who sat a few steps away from my desk — who needed to be aligned around the vision for the project. Reaching alignment could be challenging at times, but it was usually possible after a round of stakeholder interviews. A project kickoff meeting promptly followed those interviews. After the kickoff meeting, my work became pretty straight forward: recruit users, talk to users, present insights and recommendations. Rinse and repeat.

The change from a mid-size company to a large enterprise, I must admit, took me off guard. No amount of training, reading, or networking, prepared me for the challenges I was about to face. Alignment takes on a whole new meaning when you work for a large enterprise. It is not just about defining which user to focus on — first we must define the market. It is not just about building a product that will delight users — first we must define the business opportunity. And your list of stakeholders that started off with three names quickly grows to twenty. The domain is complex and the vision is as diverse as each individual stakeholder. Where do you start? How do you make sense of everything being thrown at you?

Finding My Path

I realized that I had one of three paths I could take:

1. Do Nothing. A lot of what’s being asked of me isn’t technically my job so why should I do it? The problem with that mentality is that everyone is on the same boat, and doing nothing won’t help anyone. Not the company, not the team, not you. And let’s face it, it’ll probably get you fired.
2. Do everything. This is a popular one, especially among new researchers who are idealistic and eager to please. The problem with doing everything is that it’s not possible. You’re not a domain expert in every area so you might be able to cover some gaps but you won’t be able to fill them. Trying to do everything sets unrealistic expectations on the discipline as a whole.
3. Facilitate the process. My happy medium! As a researcher you have the skills to listen, process information, and share insights in a way others can’t. Why not use these skills to bring your team together and ask the big questions? Facilitating the process keeps the project moving forward, builds trust with your team, sets expectations, and makes things manageable.

The Master Plan

Whether you work for a large enterprise or a start-up, all projects have milestones. At IBM, there are two important milestones prior to the release of a product marked by our Design Thinking practice. The Hills Workshop, this is where the team comes up with design requirements based on user needs and technical feasibility. The goal of a Hills Workshop is to bring the team together to define the mission and scope of a release and focus the work on desired market outcomes. Then there’s the Playback Zero, where the initial designs are presented to stakeholders for feedback and discussion. The goal of the Playback Zero is to align the team and stakeholders around scenarios that show the value of the offering.

I decided to craft my research plan to lead up to each of these milestones. But first I had to add one more — the Project Kickoff. Arguably the most important milestone, which sets up the next two milestones for success, the Project Kickoff often gets skipped, as teams work under the misconception that being comfortable with ambiguity means being comfortable with designing solutions without a clearly defined strategy. And so they go straight into the ideation phase without fully understanding the problem space. That’s like putting the cart before the horse, so to speak. The Project Kickoff sets the foundation for the rest of the project by ensuring that we’re asking the big questions and aligning around the business opportunity, vision, target customers, project goals, roles, responsibilities, and next steps. Skipping this milestone will come back to haunt you — in fact, I’ve seen it happen multiple times. Like Benjamin Franklin once said, “If you fail to plan, you are planning to fail!” — I couldn’t agree more.

“…if you fail to consider all the aspects of product strategy, business strategy and user needs, those miscalculations will also follow you through every step of the process.”

— Joe Natoli

The whole point of a research plan, without getting too scientific, is to define what needs to be investigated, and the best way to go about that investigation. Working within the context of each milestone makes this task much less intimidating. Now, I’m not suggesting that these are the only milestones that matter. However, the beginning of a project can be the most ambiguous and overwhelming. Therefore, I believe that if you can write a well crafted research plan that gets you past this stage, the rest will be much easier.

With a framework in place it’s time to fill in the gaps. Here’s a high level outline of what I might include in my “Master Plan”, as I like to call it:

1. Research goal per phase

2. Research design:

• Methodologies
• Objectives
• Participant criteria
• Timeframe
• Links to supporting documentation (e.g. discussion guides, usability tasks, etc.)
• Budget (if relevant)

3. Project Milestones

• Objectives
• Timeframe
• Links to supporting documentation (e.g. workshop agenda, participants list, etc.)

And, here’s an example of how I might structure the document. Nothing fancy, just a simple Box document.

As you can see, only phase 1 of the plan is filled out. There are two reasons for this:

1) This is a template (obviously 😊)

2) Your research plan is meant to be a living document that grows and changes over time as things become more defined, and that’s ok!

Let’s take a closer look.

This “Master Plan” does more than keep me organized — it keeps my team informed — so it’s important to be specific! Along with each methodology or study, I include relevant links to supporting documents: research participant screening questions, discussion guides, agendas, user tasks & scenarios, etc.

To learn about research methodologies and more, check out some of my favorites:

Sites:

• Usability.gov — Great resource for lists of methods, templates, and guidelines.
• The Nielsen Norman Group — Lots of in depth “how to” articles, guidelines, and trainings.
• Cooper Journal — Awesome articles and case studies.

Books:

• Just Enough Research — This book is helpful to newer and experienced researchers alike. It is straight to the point, and provides a very practical approach for conducting research.
• Think First — The description on the cover says it best, “My no-nonsense approach to creating successful products, powerful user experiences + very happy customers.”
• Designing for the Digital Age — This is a BIG book! I kind of use it like an encyclopedia. Anything I ever wanted to know about designing digital experiences is in this book (I’m pretty sure).

Articles:

• Recruiting enterprise participants for pennies: a practical guide — This article, written by my friend and colleague, Cary-Anne Olsen-Landis, is a step by step guide on how to recruit research participants when you have zero resources.
• It’s all Relative: Data Visualization for UX Research Data — Great article by yet another talented friend and colleague, Stefanie Owens, on how to present your research findings in a visually engaging way.

Conclusion

Understanding how to leverage IBM Design Thinking in combination with my own knowledge has been key in creating a framework for writing research plans that are reproducible and effective. As I reflect on the last three years, I realize that this is just one of several strategies I’ve adopted throughout my journey — in what I now know to be Design Research — at IBM. To be successful in this space I needed to expand on my definition of what it means to be a researcher. As it turns out, Design Research, and UX Design for that matter, is about much more than just users — it is also about the business! To craft a strong research plan, you must set out to investigate and identify opportunities for both, and the right solution will be somewhere in the middle.

This article was inspired by a course I co-teach with Ashwini Kamath on how to write a research plan for the new hire education program at IBM Design in Austin.