While developing an effective data portal1, its potential users’ data needs must be the primary focus of its design.
The traditional segmentation of users based on “who they are”, such as journalists, policymakers, or even portal maintainers (including those who update data), is often inadequate. It does not account for specific motivations for digital platforms dispensing data products. Delving deeper into users based on “what they want to do with the data” allows for a more tailored approach to designing data portals that can better meet their users’ needs. While it is still essential to consider the broad role of the individual, prioritising the individual’s specific goals and needs when it comes to data use is likely to be a more practical approach to design.
A way to understand and categorise data portal users is by the depth and frequency of their data needs. Visualise a coordinate system whose horizontal axis ranges from occasional data needs on the left to frequent data needs on the right and whose vertical axis runs from basic data needs at the bottom to detailed data needs at the top. The resulting four quadrants define four types of users, what some2 have called miners, tourists, harvesters, and builders (Figure 1):
The users in the upper left quadrant, with detailed but occasional data needs, are the miners. They dig into large volumes of data for thorough research or analysis. They prefer to download data in bulk and perform analytics in their choice of tools, preferably offline.
The users in the lower left quadrant, with basic and occasional data needs, are the tourists. They’re there to view data out of curiosity or inform personal decisions. They like simplicity in finding and viewing data quickly and easily.
The users in the lower right quadrant, with basic but frequent data needs, are harvesters. Besides viewing, they also like to download data to inform basic research or economic decisions. If the interface is too complex, these users will not be willing to put up with it unless it significantly improves their ability to access and download data.
And the users in the upper right quadrant, with detailed and frequent data needs, are the builders. They need functionalities to access data persistently. They combine data from various sources and build mashups and applications. And they appreciate Application Programming Interfaces (APIs) for automatic data fetching.
Users with basic data needs are more common than those with detailed data, and visitors to data portals with occasional data needs are more common than frequent ones. So, the largest group consists of basic and occasional data users, and the smallest group consists of detailed and frequent data users.
So, what should be the approach to designing a data portal?
Overall, taking a data user-centred approach when designing a data portal is helpful. This means considering the different types of users and their data needs and designing the portals to meet the needs of most users while still providing the necessary functionality for other user types. By taking a long-term view and adopting an approach of gradual progress, it’s possible to start with a data portal that is optimised for the most common user base and meets the minimum needs of other user types. As the portal evolves and usage increases, additional features and functionality can be added to cater to the needs of a broader range of users.
But more broadly, by mainstreaming user research practices for gaining insight into the needs, behaviours, and motivations of the people who would use a data product or service, the developers and deployers of data portals can gain a deeper understanding and use that knowledge to inform their decisions and improve their offerings. By regularly engaging in user research, one can stay attuned to the changing needs of their users and ensure that their services continue to meet the needs of the people they serve.
 For the definition of a data portal, see the UNSD’s Handbook on Statistical Organization, 2021, which states, “A data portal is a web-based, interactive data and metadata platform with databases modelled for specific data types and domains such as microdata, macrodata or geospatial data”.
Thanks to Eric Anvar and Stacey Bradbury for reading drafts of this.