Programming mistakes

Research is a profession that should be carried out by experts. The biggest threat to quick and cost-efficient research is that the quality is almost always suffering. DVJ wants research to remain good. Even when it is quick and against low cost. For this reason, we regularly share examples of mistakes and best practises in the market. We share our thoughts and possible solutions to improve research. By following these tips, we can make research better. This time the honour belonged to Research Expert Wieneke Bron.

What makes me enthusiastic about being a researcher is the everyday challenge of obtaining exactly those insights that can support clients in their decisions, small or big. To get there, it is not only important to ask the right questions, but also (and maybe even more so) to ask them in a way that respondents can easily and truthfully fill in the questions.

To maintain the ability of developing engaging questionnaires, I’m convinced it’s important to regularly take on the role of respondent by filling in questionnaires yourself. While I was doing this, I recently came across a seemingly small, but possibly rather impactful mistake.

After I stated I did not own a company, I still got asked how many employees my company had. Of course, I was not able to answer this question.

These types of mistakes can be quite damaging. They result in frustration among respondents because they are forced to choose an option that’s not true. This can lead to drop-outs or annoyed respondents that answer questions more negatively, possibly influencing your questionnaire’s outcomes.

Furthermore, to be able to analyse the outcome of this question, answer options of respondents not owning a company have to be recoded which will cost extra time. Maybe this question was even used to obtain a specific target group, which it will definitely not do in this manner.

This mistake could have easily been prevented by thoroughly testing the survey and checking all your routings. This is in my opinion a strong example of programming and sending out a survey too quickly, which can eventually result in more time loss than gain, and possibly result in a negative impact on your outcomes.