How I felt coming into an workplace as a researcher.

As a Phd candidate in the social sciences, I was raised on practices that could draw out a project for months.

Any research done in university, you had to run the gauntlet of literature reviews, research proposal approvals, ethics applications (which could take months to come through), literature reviews, participant recruitment, draft interview scripts, literature reviews, still waiting on ethics approval, peer-reviews (and did I mention literature reviews?!).

The process is long and convoluted. So you can imagine the huge culture shock I experienced moving from the academic research realm into the tech space.

In the Product Team at HotelsCombined, we work under Agile. At times it is fast-paced and we get stuff done — quickly. There is no time for anyone to QA a research proposal, or ask anyone if I can have permission to unleash my research onto the public (we do have ethics in place, though!). I am a research team-of-one, which means it is up to me to conduct big research projects, as well as establish the research practices and processes. I have had to work hard to condense my practices without jeopardising the validity and reliability of my data and findings.

There have been a lot of ups and downs, but here are some tried and tested things I have learned along the way (and still learning) working as a Researcher ‘team-of-one’ under Agile. I can achieve a whole quarterly research project within 5–6 sprints that works for me and does not undermine the data.

Establish the Right Environment

Thinking ahead and being prepared is key!

This is cruical.

Spending half a day to plan out your research and set deadlines around the number of sprints you need is important. You’ll need to consider the time it will take to recruit, gather data, and report. Not only is it a good way to manage yourself, you can also set expectations for stakeholders on when they can anticipate the research to be completed.

This is especially important if you work in a company or organisation that relies on the research to be completed before any design and development work can commence.

Setting up a research practice and processes is the first step to take, despite the size of your team. Any type of infrastructure, processes, data management, and communication should just come with the researcher role. But establishing these prior to doing any research project — or during some down time — will make sure that any research project (big or small) can be done efficiently and quickly.

Here are some of the processes I have set up to make sure that not only myself but our designers can plan and carry out research independently and quickly.

Create Templates

With most research projects, we have to hit the ground running. In some cases, there may only be one sprint to get usability testing done. To make this process easier to get started for the designers, I created a series of templates for research plans and a script for obtaining informed consent for interviews and usability testing, so all they have to do is fill in their relevant details and go!

Start a research data repository

Before I arrived at HotelsCombined, data from any type of user research was stored in many ways — on the local server, Evernote, or a document on a designer’s Mac. We needed one place for all of our data, so any of us could refer to the data when we needed.

There are many different tools to use, but we use (and love) Dovetail. It is a product that is still in its infancy, but it has a lot of amazing features, is easy to use, and the support you receive from the guys who make it is equally as good.

We specifically use the tagging feature to make it quick and easy to reference past research, and it also has a feature to store audio and video files, and photos. All of the prior research is now stored on there for easy and quick access for when we need it. We also use it as a synthesis and analysis tool.

Other ways to store and collate research data are:

However you choose to store your data, make sure it is categorised and stored appropriately and in a way that is easily and quickly accessible.

Build your Research Participant Pool

Any researcher will tell you how freaking hard recruitment can be. It depends on the cohort you are studying — some societal groups are open to research participation, while others are a lot more difficult. The ones that are tricky to recruit, are obviously the ones that will take much longer to reach and schedule.

If you use a recruitment agency, then great! However, if you are restricted to a budget then recruitment is all on you.

Building and maintaining a group of participants that you can access at your disposal, will reduce recruitment time significantly. How you can do this depends on the type of organisation or company you work for, and the extent of your research capability.

Be Flexible

Being flexible to change doesn’t need to be painful.

As researchers, we can get stuck in our ways on how to tackle a project. Some of us also have opinions and ideas on how a method should be carried out — remote vs. in-house; moderated vs. unmoderated.

This is all ok, but when you have to do a bunch of interviews within a sprint it is not ideal to get too picky. So, be open and resourceful to using a wide range of methods and tools to gather as much data as possible within a short amount of time. Further to this, if you allow flexibility to your participants you will further your reach of people who you might not otherwise access. For user research under Agile, quality should override quantity.

An example of this happened for me recently. I planned to do interviews but had only one sprint to get them done. Rather than waste a sprint trying to find participants who could come in-house, I opened up the criteria to include remote interviews. Most of those participants for that study lived interstate. This allowed me to not only recruit participants quickly, but I also was able to have contact with people who provided great insights that I might not have otherwise been able to access.

Also do not be afraid to get creative with the tools you use, if it makes gathering and synthesising data more effectively. Be open to suggestions from others on how to make any recruitment and analysis quick and easy.

Keep it lean

Don’t try to fit in more than you can handle.

Keep deliverables to a minimum!

I have three ways of reporting my findings company-wide — Confluence, Slack, the UX Wall, and Infographics. This all came about from trial and error on what was well-received and what was not. My ‘official’ reporting goes on the UX Research Wiki page in Confluence. A typical report will contain the research plan, and ‘researchy’ details such as the sampling method for each study, the number of participants and my findings in every possible detail. The reports are long, full of jargon, but it is there as the official research report for anyone who wishes to read it.

However, not everyone does! So I will also present high-level findings at sprint reviews, and create quick and simple infographics so that people across the company can get the insights at a glance. They have been well-received, and probably my most successful deliverable. The infographics are placed on our UX Wall as well as on Confluence for anyone who is working overseas. My Confluence posts then are posted to the User Research Slack channel I established so people across the company can access them.

To create the infographics I use Piktochart. It is great for novices, but also it saves time in trying to find the right icons, fonts, and layouts. You can have limited use of it for free, and even the limited templates they provide are still useful. For something more advance — or if you are up for a challenge — Sketch or Photoshop will also do the job.

It comes down to knowing your audience, and catering your insights reporting to suit that audience. An epically long research report is redundant for busy stakeholders, and not everyone will understand what you mean by ‘convenience sampling’. Providing a ‘one-look’ guide helps to convey your findings in a way that suits everybody.

Synthesise as soon as humanely possible

Sometimes I do not wait until the very end of data gathering to start synthesis and analysis. If I see themes emerging after a few interviews or usability testing sessions, I begin to synthesise and analyse. Synthesis and analysis should be an organic and dynamic process, and by pulling insights as they emerge helps to keep your analysis momentum going. It will also save you considerable time doing it as it happens, rather than setting aside a whole day or two to do it. You can then begin your reporting sooner.

Drip-feed data and findings

Presenting insights in small amounts can be beneficial.

When you present your findings and insights to any stakeholders keep it high-level and relevant to your audience. It is also helpful to ‘feed’ your findings to your stakeholders as they emerge and are ready to present.

I trialled presenting my research findings all at once to our developers in an ideation workshop, and then again during a planning sprint. What I found happened was that they had a cognitive overload. Throwing a tonne of dense insights on top of what the research project was trying to achieve, meant that they could not take in all the important information.

When I presented my findings as they were ready and during the quarter, allowed everyone on the Product Team to be over the insights, with only a quick refresher needed later. It also saves everyone a lot of time in organising, attending, and carrying out long, dry powerpoint presentations.

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here