Benefits of Internal User Research
Why we should validate ideas and concepts with colleagues
User testing with employees gets a really bad reputation. For years, I refused to test anything on internally, with the fear of skewing data, integrating biases and considering inauthentic behavior as a genuine reaction. There are many arguments against user testing with employees:
- Employees are (generally) loyal to a brand, which may make them feel strongly positive (or negative) during the user test, regardless of what is actually being put in front of them. They are less focused on the prototype, or potential feature, and are more likely assessing their feelings of the company, as a whole
- Internal participants may know, or be friends with, those involved in the study. This can heavily influence behavior during a test. You don’t want to tell someone you are friends with that his designs suck. Instead, you may participate in a white lie for fear of insulting or disappointing colleagues
- People working for the company have their own internal motivations and opinions on the best course of action for the business. If you are testing a feature that is aligned with those motivations, there may be more positive feedback, and the opposite can be true as well
- Tech knows tech, so sometimes, developers might give very technical feedback, or may say something is not technically feasible. It may be difficult for employees to step out of the company box they are stuck in and give innovative feedback
- Employees may have prior knowledge about the study, and definitely have prior knowledge about the company. They know the company’s jargon, and the way the company thinks about ideas, which could make them preform or understand better than an “outsider.”
I am absolutely not arguing with the above, as they are all really great points against user testing with employees. I know, for a fact, it is significantly harder to observe authentic behavior when testing internally, which is the entire goal of user research.
However, I would like to provide a counterpoint. Just like everything else, internal user testing does have a time and place, and can offer some benefits.
Benefits of Internal User Testing
Of course, internal user testing cannot be viewed in the same way as user testing, and the “findings” need to be taken with a large grain (oxymoronic, but true) of salt. When used in the right circumstances, internal testing can be extremely helpful, if you know what to expect and how to interpret what you hear.
Here are some (unexpected) benefits I have come across when I finally gave in to internal user testing:
1. Internal user research is free!
This is probably the most common pro of conducting internal user research. Conducting research takes a lot of time and money, from recruiting, planning the research, talking to users and compensation, there is a solid amount of budget you need to consider. There are definitely ways to lower a user research budget, but very rarely are interview sessions free. When dealing with internal research (under 99% of circumstances), you are able to get this free feedback. You aren’t going to get all the insights you may normally get with users, but you are getting feedback, nonetheless.
2. People are easier to recruit
Recruiting can take a lot of time. Obviously, employees are much more accessible than users, and are more willing to give their time to the company (especially when there are cookies and candy involved as “compensation”). With internal tests, I have posted a message to our general Slack channel and have scheduled 7 tests over the courses of the following two days.
3. It promotes UX research to the company
Inviting employees to try out prototypes or concepts increases the visibility of user research in the company. Although I have given many presentations on what user research actually is, people are much more interested when they are actually taking part in the research. It opens up the opportunity for employees to understand what we do as researchers, and why it is important for us to talk to our users. In the past, this has led to more UX support, in general, and a larger budget.
4. Employees are able to give feedback and help the product team
I have seen product teams completely siloed in companies, and that makes me really sad. To me, everyone who works in the company should have the ability to influence the product in a positive way, and internal user testing is a great outlet for that. When I first started trying internal user testing, we put something in front of an employee (an account manager) and they said, “wow, you are really going to make our users do that?!” That moment opened my eyes to a whole new (and different) world of feedback that I could gather internally. Not only that, but employees feel more empowered to make a difference, and contribute!
5. You test your user testing protocol before speaking with users
I would have to say, this is my favorite reason for conducting internal user research. I can run a pilot test of my research script, and see which of my own questions don’t make as much sense, and where the flow maybe gets confusing or awkward on my side. This gives me a small heads up to where the conversation might get stuck, and gives me some pointers of how to work through these before I head into a user testing session
When to do internal user testing
I definitely don’t use internal user testing for everything, but, whenever I do, it always compliments actual testing with real users. I usually focus on user testing in these scenarios:
- Feedback on a prototype before putting it in front of users
Internal testing is a great way to find bugs, typos and generally confusing information before you put something in front of actual users. The number of times I have found a issue with an Invision prototype, or confusing copy during an internal has been numerous, and allows for better feedback once you are speaking with your users - Testing out a research script
As I already mentioned, I really appreciate running through my user test in a semi-realistic scenario before stepping into a user research session. Not only can I find problems with my interview flow, but it makes me feel more confident when it matters most - If you are building a product for employees
Some products are actually built for your employees, which is the perfect time to run internal testing — in fact, this changes it from internal testing to user testing - When there is internal resistance to UX research
Whenever I have started at a company who is resistant to the value of user research, I always start by running usability tests internally. Although the information is not the same, it can still highlight issues with feature or concept ideas that were not thought of upon conception. Testing with stakeholders can break down the barriers and open up the possibility of communication and discussion when it comes to “gut decisions” - Gathering basic feedback on a very confidential concept
Sometimes conducting tests on a confidential subject can cause some issues with recruitment and user testing, especially if it is highly sensitive and the company is worried about others finding out. In this case, you employees have already signed NDAs, and are less likely to cause confidentiality problems than external participants
Internal user testing will not get you the same results as testing with your actual users. You can’t expect to walk out of an internal user session with the same, deep findings you would had you spoken to a real user. It is great if you were able to get some great, innovative ideas out of the session (especially if your internal stakeholders use the product), but I always make sure to tag those insights as “internal” and see if I hear these same ideas in external user testing.
Some tips to maximize internal user testing
With all this being said, there are ways to maximize your internal testing results, and here are a few tips I have to offer:
- Recruit a diverse pool of employees
Make sure you recruit people who have been there for a long time, but also those who have joined recently; and be sure to pick from different teams. I always try to include the most “diverse” mix of employees possible - Incentivize with food
I use food as an incentive for everything. If I know people will not want to be in a meeting, I will bring cookies and candy to help get people excited about what we are about to do. Since you aren’t compensating your employees for their time, I always like to offer them some sweets as a thank you - Maintain your expectations
Ensure everyone involved in running the test understands that this is not the same as speaking with an actual user, and that the results are geared more towards making sure the prototype or concept makes sense, and is acceptable to put in front of users. You will probably get more than that type of feedback, but to always remember that feedback came from internal sources - Let employees know what type of feedback you want
I generally preface these sessions letting the participant know what kind of feedback I am looking for, such as feedback on how the prototype looks, the content of the prototype and, of course, whether anything is generally confusing. I will also ask usability-related tasks and for opinions, but I do want to make sure to maximize the type of feedback given the method type
Remember, internal user testing is not a “get out of jail free” card from speaking with your actual users, so please refrain fro only talking with employees. When used in the correct circumstances, and in conjunction with user testing, doing user research with your employees can be a really helpful experience!