I’m often asked how I moved from my "words-based" world of academic research to the more "visually-led" world of user research.

Spoiler alert: it wasn't as easy as I anticipated.

Quite honestly, I believed I would breeze right from academic research into the world of tech and product. I used my MA in Psychology, and academic research studies, as a huge selling point during my interviews. I spoke with the confidence of a five-year-old who was sure to be an astronaut when she grew up.

It wasn't quite as idyllic as I expected. As I worked in the field, I quickly realized there is a huge gap between social science research and UX research. It forced me to learn a few of the biggest differences between academia and the "real world.”

For example:

• Learning how to communicate differently
• Tech/design language and concepts
• Working with many different roles
• Doing faster research without jeopardizing the quality
• Completely different environment
• Many, many meetings
• Learning about business

This doesn't mean you’re doomed if you’re coming from an academic background. It just means you have to adjust and be willing to learn a different way of doing research.

FYI: If you're planning a career transition (or just walking into a set of new opportunities), we wrote a UXR Getting Started Guide you might want to read.

The biggest difference between academia and UXR

UX research and academic research aren't completely different worlds. There are some similarities, and I know people from an academic background tend to inject more of that "academic" process into their user research practice.

However, many people who try to place academic research into a tech company struggle. This is because the majority of people in a company do not have the same background. There is an entirely different understanding when it comes to the tech world versus the academic world.

The most significant difference is the environment in which each "grew up." Academic research operates in a slower and more methodological domain, while user research operates in an extremely fast-paced setting. This is the most major adjustment I had to make when moving to a tech company.

In academia, I could take my time doing the research, and my studies would often span over months. Sometimes it took weeks or months to get approval from the IRB. Then, in a lackadaisical way, I completed my study.

But tech is different. Many companies use a framework called Agile methodology. It usually means teams work in two-week development cycles. So, when those two-week cycles come about, you have to have already completed the research, handed it over to the designer, done any other tests, and have development work ready to go.

To give some context, I have to touch base with teams every one to two weeks to make sure I am ahead of all their projects. I usually run 10 usability tests within a week and juggle several projects at once. It's possible but very different from what one may be used to in academia.

Teams need things done fast, and you need to be weeks ahead of everything to ensure the research is done before development starts. Now, this doesn't always work out correctly. I've failed at this many times, but it is crucial to learn this mindset. The company will move fast, and, to deliver a positive impact, you must move quickly with them.

How to make the transition smooth:

I highlighted the differences I have found above, but I think it is essential to explain how I overcame the other hurdles:

• Learning how to communicate differently. I am a written/verbal person. I could fill a whole powerpoint presentation with so many words, you would be reading for hours. One of the hardest things I had to learn was how to present my findings visually. Instead of writing a research report, I use charts (rainbow charts are great), bar graphs, video/audio clips, and photos from the app/website to convey what I need to get across.
  
  This is much more effective in people understanding what I am trying to explain to them. The old adage "a picture is worth 1000 words" is absolutely correct in this. I recommend looking over UX portfolio pieces done by others to understand how to do this more effectively. And lots of practice.
  
  
• Tech/design language and concepts. Agile, Scrum, sprints, waterfall, lean, user stories, requirements, prototypes, generative, usability testing. A new world means learning a new vocabulary, and there is a lot to learn.
  
  Read as much as possible about product and tech environments to learn how they talk. This was the easiest for me to start with and gave me confidence when I was sitting in meetings or talking to teams. I've been in the field for over five years and still struggle with some technical jargon, but getting the basics is important!
  
  
• Many, many meetings. This took me some time to balance. Since I am the bridge between the user and the different areas of the company, I am often in meetings with all the different teams.
  
  I understand what they need from me, and I share the findings with each of them. It means hours spent in rooms talking with internal stakeholders. Then you have 60-90 minute research sessions on top of that.
  
  With practice, you will learn to say "no" to, but you do tend to spend the day talking to many different people (which is exciting, but sometimes those used to working in isolation).
  
  
• Working with many different roles. Not only do you learn about user research, tech, and product when you start in a UXR role, but you also have to familiarize yourself with many different departments.
  
  Unlike some academic research, user research doesn't (and shouldn't) work in a vacuum. You will be able to work with marketing, sales, account management, customer success, and even more.
  
  With this, however, comes learning about what these other departments do and how you could best help them.
  

• Learning about business. The business world is on a completely different spectrum than academia. The cool thing about user research is that it can work on many different levels—from more tactical to operational to strategic.
  
  With this, however, it is vital to understand how businesses operate (read: they exist to make money). When I started with user research, I wish I had done more research (no pun intended) on how business works, and how user research fits into that larger world of business.
  
  This is less important when you are starting out, but very important when it comes to strategic alignment. Read as much as you can about how successful businesses implement user research.

6 tips for getting into user research:

1. Look at 100 user research job postings and scour the responsibilities. I found the most common to be conducting research sessions, usability testing, note-taking, recruiting. I then made my previous experience sound as relevant as possible in this context.

It wasn't easy. Yes, I had experience recruiting participants and some interviewing experience, but usability testing was out of the realm of my knowledge, as well as understanding how a tech company worked. But I did tout the fact that I had worked in a research setting before, and that did help.

2. Stalk all the well-known user researchers on LinkedIn. I read about their day-to-day descriptions of what they did. Reading their responsibilities helped me understand the different skills I needed, outside of what recruiters posted on job descriptions. It also helped me know if this was a viable life-long career.

3. Find companies that have an established research team or a senior researcher. This way, you can learn. I was the only UX researcher at my first internship and had to leave after eight months because I needed a mentor. I was lucky enough to find one in my next role. He helped me take my researching skills to the next level and is one of the reasons I have succeeded in this field

4. Apply to a million jobs. I think I applied to 67 jobs when I was first starting. Some of them, I would have never got in a million years, but it was worth trying. What is the worst that can happen? You never hear from them again, or they say no thanks. I disregarded some of the "requirements," and I think you should do the same. In the beginning, I looked at and applied to roles where they wanted 1–2 years of experience. As Dory might say, just keep applying.

5. Go to meetups and meet user researchers. Connect with others in the field and ask them how they got into user research. Networking is also fantastic for finding internships or potential opportunities. Hate networking? Check out my guide to networking as a user researcher.

6. Many positions were looking for a portfolio or a case study. Now we get to the hardest part. I had NO idea what a case study for user research was. After some googling, I understood this was an example of work. Well, I hadn't done any UX work that I could show. I started working on a few personal projects. This, right here, is my number one tip: If you have never done user research before, the best thing you can do is read up on it and start doing research.

Pick an idea and try to map out how it would work at a company. I created a competitive analysis, wrote a research plan, did some discovery research, card sorting, usability tests, and came up with some insights. Pick something you are interested in and do a research project on this. I have an article on what can be included in a user research portfolio. I post prompts on Medium, so feel free to respond to those.

‍
Although the road can be steep, it is fascinating to be able to take an academic stance on user research and to bring that lens to a company. You will always have a unique perspective that you should celebrate and use to your advantage in your user research role!

About the author

Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs. To get even more UXR nuggets, follow her on LinkedIn.