Skip To Main Content

Using Research Tools in your design practice: Negotiating to actually use them

Posted by Jess Klein

Apr 20 2016

Bocoup has been offering a handful of user research workshops lately focusing on developing a process for working on design projects. Following the workshops, I have been pinged by tons of designers and engineers who are doing user research on a project requesting some support in a real-world application of the tools.

Primarily, the main question I’m hearing is, “How do I get my [client, user, project manager, boss, etc.] to let me to conduct user testing?” This is understandable, as much of design is a conversation around getting buy-in on a vision. It can be challenging to convince various stakeholders that you need the time and the resources provided through user research to develop out your ideas.

The Tools

While there are many, many tools available to perform research, I’m going to focus on a set of three. These tend to be my personal top three favorite approaches.

Interviews

Why Use them?: To get to know the users and to define what their goals are when they use the product.

Who’s involved?: Anyone who might be a potential user of the product and key people involved with the product development.

Ways to implement: Interviews (e.g. In-person, Remote, Async, and Group), phone calls, questionnaires, etc.

Time: ~1-2 hours per interviewee.

At our workshop this winter, participants interviewed youth enrolled in game design educational programs at Global Kids.

Personas

Why Use them?: People relate to stories and people. Personas give us a real human to connect with, someone who has goals for using the product.

Who’s involved?: These are archetypes based on interviews.

Ways to implement: These can be done by a single maker or crafted collaboratively with stakeholders.

Time: ~2 hours per persona

Here is a persona from the workshop with Global Kids dedicated to building a skill recognition tool for youth. After interviewing students, we came up with a handful of fictional personas like this to help us to relate to the potential users of the tool.

Journey Maps

Why use them?: To evaluate the current and future steps and interaction touch-points a user needs to take in order to achieve their goals with your product.

Who’s involved?: It’s time for the designers, engineers and stakeholders to put your personas to work!

Ways to implement: These can be done by a single maker or crafted collaboratively with stakeholders.

Time: ~4-12 hours per persona

To make journey maps, we imagined all of the different steps that Marshall (our persona) would need to take in order to accomplish his goal (presently and in an ideal future with the new tool).

…. but what if?

Okay, great. Real world talk here. What if:

  • my client won’t give me access to users?
  • my client is giving me access to the wrong users?
  • there’s little-to-no time? my colleague just wants me to get to making wireframes?
  • my account manager marks this as a “nice to have”?
  • + add your own disgruntled designer comment here

Tactic 1: Demonstrate the Value

Research makes it possible to do the right thing. You know who didn’t do research? The stupid little pigs that built their houses out of straw and sticks. They made a great stew. Build your house out of bricks.

— Mike Montiero, You’re My Favorite Client

Design has requirements—to make good design you need to do research in order to identify the opportunity space—even if the client thinks that they know the space. Research allows you to validate their assumptions with data.

Tactic 2: Share your Process

Sharing your process (i.e. making a plan for a plan) allows for visibility into your roadmap. It also demystifies design and research. This isn’t magic. You aren’t paying me to go back to my potions. I am going to work with you to establish the problem and the solution.

Tactic 3: Choose your Tools Strategically

These are tools—and you don’t need to use every tool for every job. Maybe a questionnaire would suffice. Maybe you send out a questionnaire… that would warrant a second conversation.

Tactic 4: Convene a Workshop

Sometimes it’s all about framing. A workshop implies creation, making, building. It’s not lightweight or fluffy. It has an agenda, a goal, and a deliverable.

Tactic 5: Plan in Advance

Good research happens because of good planning. This can happen as early as the project scoping. Ask for access to users in the section of the contract where you define what is needed to be provided to you by the client prior to the work commencing.

If you are the client

Advocating for user research will benefit you in the long run. You will gain a better understanding of who your product is for and why they are using it. This will result in a stronger, more defined project and save time and money on redundancy, messy scoping, and (gasp) designing the wrong thing for the wrong person.

In Summation

User Research can be hugely beneficial to your design practice—even if it’s done in lightweight ways. As a general approach, demonstrating to your stakeholders why the research needs to performed and how it will impact your deliverables in the end, seems to work for me.

I’d love to hear from you. How have you incorporated research into your process?

Posted by
Jess Klein
on April 20th, 2016

Comments

We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.

Contact Us

We'd love to hear from you. Get in touch!