Updating information in a repeated visit

Our user Ashwini Kalantri has sent us the following question:

In this questionnaire, most of the questions are update questions. We show the interviewer what was answered. Ask if this has changed. If Yes, then we show the question to update the variable.
This is usually 2 questions. One Yes/No question with the old answer in the label and one question with the options shown only if first question is answered as Yes. Is there a possibility to have the answer pre-filled? So there will be only 1 question with the old answer already selected and the interviewer only changes it if there is a change.

I see at least two ways of doing it a lazy and a better.

LAZY: have a section with all the questions designed as interviewer questions, preload the answers to them. Put an instruction on top of the section a la “I will now read you the answers you’ve provided last time, please stop me if anything has changed!”, then read the questions and answers. If you get a sleepy respondent, you will likely register no changes, even if they had happened.
The lazy method is simplest for the designers, of the questionnaire. But it requires attention of both the interviewer and respondent, as well as hard to check (in the office you will have a hard decision to make whether to trust the data that comes back with no changes marked).

BETTER: have a section with 3 questions per every bit of information you inquire:

  1. a hidden question for the old value, x;
  2. a gateway for the change “You told me last time X=x. Has X changed?
  3. a conditional question “What is X now?” asked when answer to #2 is affirmative.

This triples the number of questions in the questionnaire, and may come in conflict with some designs, which are sensitive to the number of questions (such as in the flat rosters).

This should more adequately measure the changes. But you may run into some difficulties to program the logic of the changes. Indeed, suppose you learn that the marital status has changed, and the person is no longer married, in that case you shouldn’t ask if the spouse’s name is still the same. This would necessitate a reference to an updated value, something that is sometimes you ask, and sometimes you imply - hence a need to bring in a calculated variable for the updated status. You can probably avoid it in the simple questionnaires, but will likely prefer in the more complex ones.

Yet the use of a variable doesn’t solve the problem if the question is used as a trigger for a roster, since a variable is not a valid trigger. Correspondingly design of the roster will be affected too.

Finally, sometimes we are interested not just in the change, but WHY the change has happened:

  1. Hidden (preloaded) question for old status “2019: in school
  2. Interviewer: “Are you in school now?” Y/N
  3. Interviewer: “In 2019 you were in school, but now you are not. What was the reason that you’ve left your school?” __ specify reason___ (after Q1=Y and Q2=N).

Sometimes there is a viable hybrid approach:
Q: “You told me you are married to Ann Johnson, is this still the case?” Y/N
If No - ask all the marriage questions anew as a separate conditional section.
The choice probably rests with how tightly these questions are knit to each other and to the rest of the questionnaire.

To check which questions may be preloaded, refer to this article.

Best, Sergiy

1 Like

@sergiy Thank you for the detailed response. This helps.

I tried a variation:

  1. No hidden question with old value
  2. Gateway question with label showing old value preloaded in the update question. The value of X is %y% Do you want to update X (Y/N)
  3. (variable_name = y) What is X now (pre-loaded). Displayed only when previous question is answered as Yes.

Do you anticipate any problems? We are referencing a future question, although its preloaded. It works in my testing.

This is broken now. I don’t know why it was working before and why it isn’t now.

Now the placeholder shows [...] until yes is selected in the gateway question which unhides the update question.

No it is not broken. By design a question that is disabled has no value, hence you see the three dots.

I have shown the three question combination that is to be used in this case in the top post in this thread. The hidden question is essential as a container to store the old/known value.

1 Like