Research at conferences: a gift or a curse?

5 principles for conducting research at a company conference

Illustration by Gizem Vural

Picture this, after several Google searches and reaching out to your professional network, you’ve identified the top three UX conferences you’d like to attend this year, and now you have to build a case to convince your manager. You’ve already been turned down numerous times in the past and know that, although it would be amazing, attending all three is highly unlikely. When you add up all the costs — registration, flight, ground transportation, hotel, food — your company could easily spend over $5000 for you to attend just one of these conferences.

Fortunately, you built a strong case around how your attendance would not just benefit you, but also your team and the business as a whole. Your manager is convinced and off you go!

At the conference you make sure to sign up to a variety of lectures that address important questions and challenges relevant to you and the rest of the team. After all, when you get back there’s an expectation that you will recount your experience and share your learnings.

Is this scenario familiar? As UX professionals we’re always talking about empathy, and yet when it comes to conducting research at conferences we seem to throw empathy out the window. We ignore our own experiences as conference attendees and instead get caught up in our own agenda.

Now imagine what it would be like at a company conference, where similarly to the scenario above, your customers have invested thousands of dollars to send one or two of their top tier employees, and they’re being targeted by people to participate in research activities on their way to an important session.

In this article I will provide you tips on how to capitalize on every opportunity while conducting research at a company conference. Before I do, however, I’m just going to come out and say it — I’m not a fan of research at conferences; the reason is ROI.

Expectation vs. Reality

When your company spends a few thousand dollars on research, there’s an expectation you will bring back actionable insights. The problem is that conferences, more often than not, are simply not a good venue to capture this type of data. And why is that?

1. Participant motivation. Participants (or their companies) have spent a lot of money to be there, and it is for a reason! They want to learn about the latest and greatest and they want to network, and they are not going to waste this rare opportunity by participating in activities that don’t provide them any immediate value.
2. Wrong environment. Conferences are loud, chaotic and full of distractions — hardly a venue that simulates your user’s real environment or even a lab for that matter. In research, context is everything. Therefore, the space, environment, and the research participant’s state of mind all influence what type of information we will capture — this is no different at a conference.

I get it — it’s tough being a researcher when resources are limited and the opportunity to get in front of your end users are few and far between; you might say to yourself, “hey, at least I’m talking to users.” Here’s the problem: a big part of our role as researchers is to establish trust — this is why we spend so much time strategizing how to best present our findings, research plans, etc. We want, or better said, we need stakeholders to see the value of our work so we can establish a healthy working relationship and ensure that our findings make it to the final product. So when you’re presented with the opportunity to conduct research at a conference you have to ask yourself, “Given the amount of money my company will exhaust to send me to this conference, is it really worth it? Could I use that money to conduct better, more meaningful research? Is there a better, more effective way to gather the information I need?” As a domain expert it’s your responsibility to do the due diligence and set expectations from the start. That’s how you begin to build trust.

It’s not all bad news!

Conferences are still a great place to get in front of a lot of people (customers, colleagues, etc.), and there is value in that. So what should you aim for when conducting research at a conference?

1. Networking. As a researcher who works on B2B enterprise software solutions, I’m constantly on a mission to connect and build relationships with product managers and sales reps — who oftentimes serve as liaisons between design and the customer, and have a world of knowledge. A company conference is often the first time you’ll get the chance to meet in person, which can help form a bond that is difficult to achieve over the phone, and can be the difference between an ignored email and a proper client introduction. In addition, you’re at a venue with hundreds if not thousands of potential research participants. You may not be able to get all the time you need with them during the conference but you can always capture their contact information and connect with them later to run a more in-depth study.
2. Formulating initial hypotheses. As I mentioned before, conferences are often not the ideal venue to capture deep insights. However, if you plan accordingly (I will get to that later in this article) it can be a good place to help your team identify design opportunities and narrow the scope of your research.

So if you do plan on conducting research at a conference, here’s a list of principles to help you make the best of your research:

1. Do your homework. Make sure you know what the conference is about. What is the purpose? What is the format / agenda (lectures, workshops, etc.)? Who will be your point of contact for logistical matters (i.e. reserving a room)? Who’s attending and do they fit your research participant criteria? Create a conference profile with the what, why, and who of the conference — this will help you determine next steps.
2. Collaborate. Work with your product managers and sales representative — they can connect you with participants before and during the conference. You might even be able to tag along in one of their client 1x1s.
3. Be realistic. You should never try to boil the ocean with your research, especially at a conference. Craft a research plan that applies to this unique environment by setting realistic research goals and be flexible with your methodology choice.
4. Make it worthwhile. The lectures, workshops, etc., don’t stop during your research sessions; you have to give participants a compelling reason to ditch their agenda and come talk to you. For this reason I tend to gravitate towards evaluative research at conferences, as it’s a great way to get feedback and get research participants excited. If your research is generative try to have some swag to give away or include a sneak peak to another popular product (demo) — this is another example where partnering with product managers and sales reps comes in handy.
5. Don’t be selfish. Be mindful of people’s time — if you schedule them for 25 minutes DO NOT go over that time. Remember why they’re there and be appreciative of the fact that they’ve given you any time at all. Also, the conference is not the be all end all — you now have a potential lead you can follow up with at a later date, and chances are if you stick to the schedule they will be more likely to speak to you again in the future.

Conclusion

While conferences present us with the opportunity to engage with customers face to face, they are not necessarily the best venue for certain research methodologies. Therefore, as with all research, it is important you first consider your research goals and whether, given your available resources, a conference will be the best venue to inform them. In the case you choose to move forward with your research, remember to write a research plan that conforms to the constraints of the conference environment and considers the research participant’s state of mind. At the end of the day, your findings will only be as good as your methodology.

Margie Mateo Villanueva is a Lead Design Researcher at IBM. The information and views explained in this article are those of the author, and does not necessarily reflect IBM’s positions, strategies or opinions.