Think about your food without seasonings or salt, that’s what a digital data collection tool without conditions is like - tasteless. Having noted that, too much seasoning/salt can also make the food uneatable.
The use of conditions is a very vital piece of work when building or developing a digital data collection tool. By conditions, I’m referring to display condition (skip logic), validation condition (constraints), required condition (mandatory fields), and default values (autofill).
It is the duty of the tool developers, programme/field experts, and data analysts to ensure data collection tools meet a certain level of standard. Beyond coming up with questions that can be used to measure the performance of a programme or initiative, it’s important to think through and carefully so, how each question is collected, and validate or invalidate other questions. It’s in this thought process that questions are properly sequenced, structured, and to a great extent rid of possible wrong responses.
Conditions significantly contribute to the improvement of data quality for new and existing systems. I’ll try to highlight the relevance of each condition type in this article.
Display Condition, also known as Form Filtering or Question Display Logic is used to filter the content (the visibility and accessibility of folders, lists, or questions) of your application/form for a specific use case. It determines the conditions under which questions are displayed. The use of display conditions averts having conflicting realities within your record/dataset. For example, you don’t want a pregnant man but a pregnant woman in your analysis hence it’s important that the question ‘Are you pregnant?’ is only available to be answered when the preceding response to the question on gender is female.
Validation Conditions check responses to make sure they meet the constraints that you specify. It works such that if the entered information does not meet the logic you specify, a flagged message pops up for the user and blocks them from submitting the form. It ensures responses meet specified constraints. The use of validation conditions increases your chances of having correct responses entered. A good example that reflects the lack of a needed validation condition is having a future date of birth in your dataset. A good validation condition to avoid this is setting the field collecting date of birth to throw up an error message when a date of birth later than ‘today’ is entered.
Required Condition determines conditions under which an answer must be provided for the form to be submitted. Simply put, it determines the conditions under which questions are required. This is similar to the display condition in function but without the skip. The use of required conditions averts error of omission or omission of needed response. For example, if a preceding question had inquired if a woman is pregnant or not and the response is affirmative, then a follow-on question on pregnancy duration is required but not required for women whose responses were not affirmative.
Default Value displays a value upon accessing a form question and can be changed by the user. This is often used when we don’t want a field without value. A good example is having zero entered as opposed to having null values. Some analysis requires zeros for the right insight to be gotten. Another example and common in a case management setting is the collection of follow-up data on a question with registration data. Default values (registration data) are used as placeholders to give users the opportunity to update or leave as is during the follow-up entry.
The consequences of not taking time out to pay due diligence to the use of conditions are numerous. This includes but is not limited to dirty data, misleading data, biased data, missed analysis opportunities, and ultimately wrong insight or information.
There’s a need to make careful considerations when setting conditions hence the need to work with field/programme experts and analysts/statisticians to be certain our tool is relatable and fit for purpose.
Finally, based on our initial seasonings or salt analogy, one may argue that seasonings or salt can be added after the food has been cooked but you’ll also agree that it’s hardly as tasty or evened out as cooking it along with the meal. This can be likened to data cleaning, it’s much more an arduous task than setting conditions before data collection. Also, remember some seasonings require a level of heat to add real value (aroma and taste) to the meal. There are some data quality issues that conditions can avert but no amount of data cleaning can resolve them.
