I’m writing a paper on evaluating state government web-based data query systems and am beginning to wonder if a single web site designed for “the general public” ranging from scientists to curious lay-citizens can ever really be user-centered.
The typical approach to creating data systems for such a wide audience is to 1) inventory all the data sets the department wants to publish 2) specify functionality for the query system (often based on ideas gathered in focus groups, or staff meetings), 3) build the system, 4) design the interface and solicit feedback from users on what they think of the system. Sometimes, two interfaces are designed (“easy” and “expert”), and subsequent user challenges in using the system are addressed with training workshops and “read me first” instructions. This approach is technology-centered.
User-centered design, in contrast, has developers 1) begin with a thorough analysis of segments of the audience (i.e., researchers, nonprofit grantwriters, and local government health departments) and what tasks they need to accomplish on the system, 2) choose data sets and methods for displaying the data to support the tasks users need to accomplish, 3) build low-fidelity prototypes (such as paper printouts, or “scotch-taped” mockups of the proposed interface design), and test with prospective users, 4) build the system, incorporating feedback from iterative testing. The result of a user-centered approach is a data system that allows users to focus on the information within it, rather than struggling with how to use the system itself.
Problem is, that when gov’t entities focus on the final packaging of data for a broad public, they lock up their data in clumsy interfaces — typically not really meeting the needs of the general public, and preventing access to the raw data for more data-savvy folks who would know how to analyze the data.
If you’re audience is everyone, then you’re probably actually meeting the needs of no one.
