Integrating a Strategic User Research Process That Works

A Strategic User Research Process That Works

Title: Strategic User Research Process Integration in Innovation Projects
In this blog post I give you a recipe for a strategic user research process. The ingredients are a well structured approach, defined methods, guidelines for getting there via good user interviews and a project infrastructure to manage everything. I also give some examples of how we do it at Iconstorm. If you have any questions, you’ll find my contact at the end of the post.

In general, I’d say that there are two different purposes for a user research process: You can either confirm hypotheses about a product or prototype. This approach looks at tech first and this is how user research is approached very often; think usability tests, for example. However, the shortcoming of this approach is that it often locks us in with the status quo and it gets harder to think or look outside the box we are already in.

The second approach, I much prefer. (*Yoda nod*). Instead of zeroing in on our tech, we will focus on people with this one. We look at their behavior, their context, their goals and difficulties, and from that, we build new ideas and find fertile ground for innovation. Overall, this style of user research is much more explorative and strategic, because we can disengage with our existing business models and products, and look at what people really need from us. In this blog post, I will show you how to integrate a strategic user research process with your projects that does exactly that.

Integrating a user research process just “to have talked to someone” might feel nice, but isn’t particularly useful.

Christoph Erle, Iconstorm

Strategic User Research Process: For scope, direction, innovation

You should apply user research in the beginning of your project

In my most recent post, I talked about the fuzzy frontend of innovation. I mentioned that user research is very effective for untangling complexity and finding direction. And this is exactly why, in my opinion, a user research process belongs at the beginning of a project, regardless of whether we work with a mature product or an interesting idea. There are two main reasons for that…

Two reasons for doing user research early

1) User research helps reduce cost and risk by giving scope and direction

According to the rule of ten, avoiding missteps during early project stages can reduce cost that would rise exponentially later. Which makes sense: Once we’ve already built a prototype and have done a lot of work, it is really bad to find out that people don’t want it. We’ll now have to go back to square one and the project’s timeframe explodes. However, if we find out what’s desirable to users early on, we can enter the lean startup phase with more confidence and the risk of multiple iterations goes down. Thus, user research gives us better ideas of scope and direction.

Image: The Hero Arm by Open Bionics is a great example of Human-Centered Design.

2) User research helps discover purpose, vision and amazing ideas

With explorative user interviews early in a project, we can aim our attention at what people need as opposed at what we can build.  With this as a starting point, we can build much more exciting products. The image above is from the British company Open Bionics, and one of my favorite examples in this regard. Because their Hero Arm is so much more than a mere replacement. It’s not just affordable or functional—it changes conversations in the schoolyard. This is much more exciting than just improving the tech, and can only be done if we look at the person attached to it.

Integrating a Strategic User Research Process in an Innovation Project

A recipe for strategic user research:

Process, methods, interviews, infrastructure…


Below, I give a few practical ideas of how to tackle a user research process and integrate it with your project. The goal is to make it workable within the constraints of typical project structures. There are four topics to consider: The actual process structure, the methods that’ll be applied to work with the results, the how of the interviews and evaluation and the infrastructure that needs to be in place.

Because research is an investment, it has to be molded into a workable process featuring predictable results. Especially this last point needs a little work, as an explorative approach with open interviews might not seem too predictable at first glance. Following are the most important building blocks you need to consider.

First, map out a process and define goals, purpose

The preparation of your research needs to go hand in hand with the project’s planning in general. It’s best to do this in a kickoff with all relevant people at the table. You should have a prepared list of things you need to iron out, for example an explicit purpose and goals for your research, which deliverables, who is involved etc. (Especially stakeholder management is an important topic in this regard, but I might have to write another blog post on that one.)

It is also important to define the process structure and timeframe: It is best to map out its steps beforehand and make predictions. Usually, a user research process will have four stages: The preparation phase, the actual user interviews, the interview evaluation and, finally, the design phase. How long this takes altogether depends on the interviews’ content and goals.

Example Research Sprint
This is how we do it: At Iconstorm, we can predict that a one-hour interview plus evaluation will take 8 hours to complete; as a result, we’ll have about 80 to 90 usable statements that can be carried over to the design phase. Thus, the time for all interviews can be estimated and, after adding budget for preparation and design phase, we can reshape the individual tasks in form of a sprint.

Second, define methods and deliverables

Integrating a user research process just “to have talked to someone” might feel nice, but isn’t particularly useful. Therefore, based on project purpose and requirements, you’ll need to consider what to deliver in the end. This, of course, entails building a toolchain. Therefore, depending on how much time you can allocate, you have to combine methods that fit your goals, integrate well with each other and can be applied within your budgetary constraints.

Whether we’re talking about user stories, job maps, value propositions…. personas, customer journeys, TRIZ… a strategy matrix, IO-OI, brand positioning or Golden Circle – you can tailor your interviews to all of these if you are clear about which methods you are using beforehand. For example, User Jobs from Jobs Theory integrate well with User Stories; the Golden Circle goes great with a Brand Positioning; and so on. That’s why I generally recommend constantly expanding your method toolbox to be prepared for everything.

Example Toolchain From our Strategic Design Playbook
This is an example from one of our projects. In this case, we ended up with a strong user persona, a product purpose, three value propositions and a detailed job map as deliverables. The kicker: each sticky on these canvasses represents a statement from a user interview; meaning prototyping could move forward based on concrete interview insights.

Third, do interviews that integrate with the methods

This sounds easy, but it is actually hard: For good user interviews, it is paramount to have standards that ensure quality. First and foremost, they need a good interviewer guide and good questions. And this last part is often lacking. To boil it down to two principles, I would say this: A good question connects to the methods you chose, and a good question elicits a useful answer.

Connecting to the chosen methods is relatively straightforward, but requires some work: Just look at your methods and then think about which thematic ideas are hidden in them. These aspects should then also be reflected in the conversation. Getting a useful answer, on the other hand, is not that simple, because in most cases, you shouldn’t ask people about what you want to know directly.

Example: You are setting up a new office and want to know what your people need. In that case, don’t ask them what the perfect infrastructure for an office would be, in their opinion. Questions like this would require a lot of expert knowledge, which hardly any interview guest will bring to the table. Instead, focus on things people can talk about with some confidence, e.g., how they behave in the office, how they want to work, what things bother them while doing so, why they come to the office in the first place…. Since the participants actually know something about these things, you will later work with facts, not just opinions or beliefs.

Examples: These are probably not the best questions to ask…

What do you want in our new office?

Guest A: “I’d love an office dog!”

Guest B:”I’d love an office cat!”

Guest C: “I hate dogs, who said that?”

We get contradictory results if we ask for wishes.

What do you think is the best infrastructure for an office building?

Guest: “Uhhh… I don’t know. Maybe lots of flowers and a lot of space to work at my desk, a nice kitchen… Wait, what else do people need?”

Guest can’t answer with confidence because we expect her to be an expert on architecture or interior design.

Do you have any cool ideas that we should implement with our new office?

Guest: “Yes! The coffee machine should have voice controls!”

Guest: “We need a public bar!”

Guest: “Now that it’s legal, couldn’t we grow… plants?”

Asking for ideas we get features that *maybe* we shouldn’t implement.

Fourth, build some infrastructure for your projects

Finally, it is important to have all the tools in place to guarantee a seamless process. I think two good pointers in this regard concern the interview process management and the integration of interview analysis and design phase.

Concerning the process, there is one very important thing to consider: the interview guests’ informed consent. You’ll need to specify exactly what is the purpose of the research, what the interview will be used for, which data you record and why, the rights of the participants, who will be present and so forth. (Look at this white paper by the EUI for more info.) Moreover, after you get the consent, your process also needs to reflect what you promise. If you promise anonymity, you must ensure it!

Second, there is the integration of analysis and design phase. This is more straightforward: I recommend using a database or spreadsheet to record your interview results. First, look at your methods and the content they need, then define statement categories that fit with them, as well as rules on how to write them down. Equipped with that, you can analyze the recorded interview on a semantic level and extract useful statements. Once your database is filled, you can just copy the entries to sticky notes; these are then ideal for collaboration workshops where your methods come into play.


Any questions?

I know this seems like a lot (it is!), but in the end the benefits are undeniable. Good user research will make for a great innovation project. Therefore, if you are interested in integrating a user research process like this with your project, I would highly recommend doing the work. And if you have any questions, you can always connect with me on LinkedIn. I enjoy helping out!

Until then, good luck out there!