It all starts with a buy-in
Let’s assume a scenario. You got hired as a team-of-one UX researcher. The company might have some UI designers, they might even talk the talk of user centricity, but they don’t seem to be walking the walk. In order to, well, do your job, you’ll need to embed yourself properly in the organization.
You can see that at the moment the company is gut-driven. You can imagine how it could look as a data-driven one, but getting from point A to point B… that will require some careful, disciplined approach.
There are several issues I recommend you focus on:
- getting a seat at the table — your ideas are indirectly (at best) against the culture of the organization. Getting a buy-in for your ideas on the management level might create a top-down pressure for a change in the organization. Optimal course of action would be for your voice to carry the same weight as that of other decision makers, but more likely, you’ll find yourself working through a proxy (probably the person that decided on hiring you in the first place).
- business value — good research takes a while (and ought to be reproduced a couple of times before one can claim stuff works in a certain way). Especially early on, you might be judged by the costs your efforts are generating, not your methodology and future impact. Sprinkling your strategy with studies aimed at generating quick wins will help you offset negative attitude stakeholders might have towards you early on.
- money — what do you need in order to do research? What hardware, what software? How will your laboratory look like? Do you have a justification for these costs? Can you show the ROI?
- fostering grassroots changes — while it’s possible for operating principles to be pushed down from the management level, giving the right orders will not be enough. They need to be carried out according to their spirit, not letter. It’s on you to help your co-workers realize the value of data they can now have, and nurture a sense of empathy for the user.
- extending influence — you’re probably working at IT/product department. Don’t forget that content, communication and customer support are all part of user experience with your brand.
Who are we doing this for?
Research is not for the researchers. It’s not for you. It’s for informing decisions happening in every aspect of the business. You need to gain understanding of how your company works at every level (or you know, at least have a reasonable idea of what it is that you don’t know) in order to create a strategic plan for research activities. Without realizing what areas your company is comprised of and what data do they need, you’ll get somewhere, but it ain’t gonna be far. These areas will probably be:
- internal support & legal
- creatives
- devs & admins
- project management
- communications
Let’s talk about these in detail.
Internal support & legal
A wee bit over a year and a half ago this tweet happened:
Telling a long story short, this lead to a worldwide effort to define what ResearchOps might be (by analogy with DevOps or DesignOps concepts). What got settled on is that this term describes all activities necessary for research to be realized — before user sessions and after them. Based on this Medium post by Emma Boulton, operational structures I think you need to consider while creating research strategy are:
- scope — cadence, protocols, timetables, priorities, methods. The “how and when are we doing this study” questions.
- recruitment & admin — finding participants (including subs for the no-shows), dealing with logistics, incentives (in what way can you pay the participants? How much will it be, how and when to adjust this value?) Last but definitely not least, paperwork.
- data & knowledge management — how will you store raw and processed data? How are the documentation templates defined? How can people from departments across the company access knowledge tailored to their needs?
- governance — how can you ensure safety of researchers and participants both during research sessions (especially when doing field work)? How can you make sure GDPR (and law in general) is being followed? Is participant data really secure? Is the research done ethically?
- people — who is responsible for which research activities? Who owns research and it’s products?
- tools & infrastructure — what hardware and software do you need for research? How can you procure it? How do you manage physical space for research?
Creatives
You will probably be working with these ones most often, since it’s way cheaper to change a mockup than a developed prototype (or a production). You’ll need to think about research cadence and it’s place in an agile environment, so you can be sure your insights are being delivered on time.
You will also be researching their needs, figuring out ways to improve their comfort. Product people are also users, and you need to empathize with them, the same you empathize with the clients of your company. This can have measurable impact on the ROI of research, since you can show improved output from product teams thanks to your efforts.
Devs & admins
They will both enable your research and provide opportunities to grown. You’ll need them when it comes to production testing, like periodic user testing on live, A/B testing or implementing survey notifications. They will also provide you with technical knowledge about what is possible to develop and what is wishful thinking. It’ll help you to come up with better, actionable recommendations after research sessions.
Another important thing you need to take into consideration is how to include devs in research activities. While building empathy for the user should happen at every level of the organization, it won’t be happening everywhere in the same way. Include devs in these research activities that’ll have the most impact on them, like inviting them to observe a usability test.
Project management
These people will ultimately sign off on all major activities you want to pursue. Engage in deep conversations with them in order to determine KPIs and plan their measurement.
Since project objectives and milestones are decided on this level, here you’ll find starting points for your strategy. Begin with an objective the company wants to achieve and walk backwards from it, figuring out what are the necessary steps for those goals to be fulfilled.
Communications
Best product is the product that can convey it’s value to the customers, so they’ll choose it instead of a competition’s one. The questions of language (including UX writing) and data required to inform content strategy are, in my opinion, just as important as usability testing a new component.
Think on how your company engages with it’s customers on a support level. What image of your brand is built through those interactions? How will you measure satisfaction metrics and make sure the users voice is being heard?
What are we doing?
So, you’re about to go on an adventure called “creating a research strategy”. Like I mentioned before, I think that the best way to start is through understanding business objectives of the project. Defining the destination will make plotting the journey easier. This will be your outline that you’re gonna fill in with detailed tactics.
Next step is to define research population. You already have some idea who your users might be. Plan how you want to talk with them and discover their needs. Do not forget to come back regularly and validate whether their needs have stayed the same.
It’s time to choose research methods. They don’t have to be set in stone, but you’ll need them defined so you can assess whether you have the necessary equipment and can actually do your research. Have little to no idea what methods you can use for what purpose? Go to Design Research Techniques website, they got you covered.
Remember to consider the cadence of research. Some activities, like mockup/prototype validation, need to be embedded in agile cycles (e.g. sprints). Another ones, like quarterly summary surveys, will happen on a fixed schedule. And then there is stuff like generative research and user needs, which will have to happen parallel to all above.
While in principle research cannot ever be considered “complete”, you’ll need to define checkpoints for certain activities, so definitions of done can be met (e.g. you are implementing a new search engine functionality in your shop. Ask yourself, what kind of research needs to happen for it to be shippable?).
Next on, define how will the insights be shared with various departments in your organization, what is their shelf life, and after what time will they need to be re-validated.
Last, but definitely not least, define ownership. Knowledge needs to be owned, there must be someone who’s responsible for delivering it according to the strategy and business objectives. If you happen to work as a research team-of-one, well, that’s gonna be you.
The execution
Even the best laid plans survive encounters with reality like a fresh tomato hitting a brick wall. They transform. Your research strategy, meticulously made, must remain adaptable. Keep this in mind and try to keep it modular, so changes in one area will only influence those in other areas, not invalidate them (although major pivots are unlikely, they’re possible. Hope for the best, be ready for the worst.).
Most likely the changes done will concern research methods. For instance, in a research strategy I made for a gov project, I decided on using SUS scores as a part of our quarterly performance summary. I wasn’t satisfied with how stakeholders reacted to the volatility of interpretation concerning SUS outcomes. This lead me on a search for a better method and for the next quarter, I swapped to SUPR-Q. It proved to be the right choice, since decision makers could understand and compare quarter-to-quarter performance easier.
Pay attention to the way research activities are being tracked. It’s best to have them visualized in some form, since research debt accumulates quickly, especially when you’re a team-of-one. If it hits critical level, you might find yourself re-doing research. Not for validation, but because stuff got so entangled you can’t tell the tail from the front anymore. To keep a bird’s eye view on how things are going, I made a Kanban board in Trello:
- TODO — the backlog. What needs to happen in the foreseeable future.
- NEXT — next up in store, highest priority issues that need to be done.
- DOING — self explanatory
- DROPPED — abandoned research. Sometimes, business reality forces you to abandon a study. Keep it visible, so you can easily come back to it if need/occasion arrives.
- DONE — stuff that got done but is not yet fully embedded into the knowledge base
So, in closing, what to do when stuff falls apart? Your purchase order bounced, cosmic ray fried your knowledge base and backup servers, HiPPO happened? Remember about what you’re being paid for — to make life better for the users through informing the decision makers, in order to create a better product. Prioritize what research activities survive difficult times accordingly. You’ll be fine.