Of all the reasons for data quality problems, I find user interface design issues to be the most interesting. This may be because it is tied to the software requirements, and I have worked as a requirements analyst for a number of years.
There are numerous examples and studies that show the user interface can directly affect data quality. In one example, users left the default option for a field – hemorrhoids – which led to flawed data that showed most patients to the hospital suffered from hemorrhoids.1
Another example is a user interface that did not allow users to enter a complete foreign address so parts of a foreign address were missing or not in separate fields. In each of these cases, the design must have been based on user requirements. There must have been requirements on the default value, such as:
- When entering a new patient, the system shall default the Reason for Visit to “Hemorrhoids”.
- When entering a new patient, the system shall allow the user to select the Reason for Visit from these standard reasons: x, y, and z.
And these requirements must have been discussed and thought out. Was the problem due to the requirements, the user interface design (it was too difficult to select the right option), or maybe the users who needed more training or just did not take the time to enter correct information?
Well-designed on-screen data entry forms that are easy to read with clearly labeled and organized fields could reduce input errors and therefore improve data quality. The requirements for the interface are also important. Consider the following restrictions and checks included in numerous applications which improve data quality:
- Limits on options available for selection by a user. For example, if a user should select only active projects, the system would limit the projects available for selection to active projects. Closed or completed projects would not be included in the list.
- Validation of data values and records at time of entry. A blank field or data outside a certain range may not be allowed. When a user enters and submits data, the system verifies that the data can be accepted. If not, the system may reject the data and display an error message. Or the system may apply adjustments or corrections.
- Limits on the editing or deletion of data. Users may not be allowed to edit data once a certain event has occurred. Or users may only be able to edit a field by editing another related field.
These restrictions are all based on requirements and rules for the system. For the examples above, there would be functional requirements such as:
- When creating a task, the system shall present the user with a list of active projects from which to select the project.
- If the user indicates that the request is complete without entering at least one Unit, the system shall prompt the user with the message, "At least one Unit is required," and shall not continue until a Unit has been entered.
- The system shall allow a user to change the value for Total Cost only by changing Labor Cost and/or Non-Labor Cost.
There is the need to be "quality-conscious" when developing functional requirements for an application. It is important to reduce the occurrence of errors in business processes, in data entry etc. And, analysts need to ensure requirements and rules that impact data quality are explicitly stated – not implied or assumed. This will help to prevent data quality issues. For the hemorrhoids example, maybe the field needed to be left blank and a selection required when submitting the form.
Author: Fahmeena Moore, https://www.linkedin.com/in/fahmeenamoore
Fahmeena Moore has over 6 years of experience as a Business/IT/QA Analyst and an additional 3 years as a finance professional. She has always been interested in data quality issues.
______________________________________________
1 Mónica Bobrowski, Martina Marré, and Daniel Yankelevich. A Software Engineering View of Data Quality. Retrieved December 7, 2013, from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.5713&rep=rep1&type=pdf