Should researchers make design recommendations?
By: H Locke
Tags: Research, UX Research, Design, UX

When I was coming up, I was taught about UXR by people with an academic background in research and various levels of ‘a degree in HCI’. For those people, a researcher’s role was all about rigour and objectivity. In short, I had some excellent principles drilled into me.

But over time I’ve experienced a massive range of research attitudes, influenced by the specific company, project and individual researchers involved which have led me to reflect on the question — Should researchers make specific design recommendations as part of their findings?

I feel like I’ve been in situations at both ends of the spectrum.

One extreme…

Having worked in what some would call ‘pure’ UX agencies, I have seen researchers who refuse to commit to any specific guidance beyond “we should do more research”.

I’ve seen frustrated clients looking for answers, and not having the tools themselves to make forward leaps — they didnt know how to turn the findings into specific design iterations and prioritised sprints.

The solution?

In this kind of agency, I often saw this outcome for clients — namely a sense of dissatisfaction and confusion. Here I found myself taking on the lead strategist role, so that the researcher could remain faithful to their ideals of ‘just the findings’, while I worked with the client and stakeholder teams to plan and prioritise subsequent quick wins, additions and future design experiments as appropriate.

Some of the researchers didn’t like this — but the clients did, and they gave us more work because of it.

Some of the researchers loved this — because it didn’t force them to answer questions they felt would bias their presentation of the findings.

Photo by Marc Zimmer on Unsplash

To the other…

I’ve also worked with researchers who couldn’t stop giving design guidance. Not just suggesting new iterations or experiments — but actually creating specific ‘recommended’ wireframes themselves and putting them in the research reports.

This frustrated the team around them, because it prevented them from carrying out a proper exploratory design iteration as a next step. The research report essentially gave the client the design answer — with no space to understand the findings for themselves, and shut off any thought of future experimentation.

In short, the clients skipped reading the findings and just copied the wireframes.

Not to mention that the person who did the research (and design) is was then too biased to assist with any future design exploration.

This is why in my team I attempt to prevent any one person from testing their own designs, or designing (alone) based on their own tests. But I’m aware this is the luxury of having several people who are 360’s on my team.

The solution?

First, remove any and all specific visualised design recommendations from any research report. That makes it much easier for stakeholders to understand findings as they are, without jumping ahead and solutionising.

This doesn’t mean slowing the iteration process down or rapid projects. For example you can separate two meetings (research findings and ideation session) with a 30 minute comfort break. You just need to create a mental break for your team and stakeholder audience.

If the team is so small that the researcher will also have to iterate design, simply put on your different metaphorical hat and manage the clients focus accordingly.

This stage: discuss findings.

Next stage: iterate design.

Photo by Jailam Rashad on Unsplash

The contemporary UX researcher

It’s clear that researchers today need to be much more strategic than the traditional HCI training of old. As I’ve said several times before, research has to add clear value to stakeholders — otherwise research gets cut completely.

However, there still needs to be a faint line of separation between the research findings from one study and the specific iteration of design for the next.

there needs to be a line between the research findings from one study and the design iteration for the next

To be super clear before anyone gets upset, because of course the answer is always “it depends”…

I’m NOT saying

Researchers shouldn’t collaborate closely with designers

Researchers shouldn’t have informed opinions or make contributions to wider product strategy or future design iterations

Researchers should hand over a study and walk away

Researchers should avoid stakeholders questions about design next steps

That research and design should be separate at all times

I AM saying

Researchers have the power to influence stakeholders and should abstain from biasing others by leaping to specific design conclusions and recommendations

Researchers need to remain objective in order to retain research authority — a research presentation is not a design workshop

Researchers should be clear on their role in the project and team and allow others the same

If it has to be the same person that does research and design iteration, at least keep it as separate meetings, and absolutely keep specific design recommendations out of a research report.

Photo by Amanda Phung on Unsplash

How to do this

It is relatively easy to keep a slight separation between research and design iteration as part of Research Ops, which can also communicate roles and responsibilities to the team and any stakeholders.

Have a clear project methodology with discrete phases

Give research findings time to settle in stakeholders’ minds by having even small breaks between meetings and holding off ideation and solutionising — you will ultimately get more open-minded design ideation as a result

Have clear roles and responsibilities, so that even if it’s a small team, depending on the stage you call the practitioner “the Researcher” or “the Designer:

If research and design documentation are stored on a similar server (Sharepoint, Confluence), have separate folders, show clear phases of work

Although over time accumulated research findings and design discussions naturally merge, ensure that at least for early stage and standalone research findings documentation, “future work” is removed.

To be absolutely clear, there are no black-and-white solutions here. It goes without saying that the role of the researcher changes based on environment, research ops, project, company and individual. However there is rarely a good outcome for stakeholders or final design of product if a researcher refuses to discuss design iteration, or decides to start making design work on their own based on findings. Or if current findings and future ideation merge at all times.

A researcher is neither an island, nor a psychic.