Last week I attended a workshop on open data and resilience at the World Bank in Washington, DC. The workshop was timed with the release of their new field guide that offers practical guidance for governments and organizations as they build their own open data programmes. During one session, I sat with a group that was exploring how to connect open data with the people who are meant to use it.
All of this got me thinking about potential HDX Repository users and how best to categorize their behaviors. A lot of CKAN instances are about releasing government data, so their interfaces are focused on search. We are trying to create a place for humanitarian partners to share, find, use, and even comment on datasets. This makes the technical development more complicated.
User archetypes are one way to break down user behavior, making it easier to determine what to build first and, hopefully, helping your technical lead sleep a little better at night.
Here are the basic HDX user archetypes that I came up with:
Needs: reliable search; ability to narrow search results using filters; relevant tags; a way to request a dataset that can’t be found; clear metadata (source, contributor, caveats, license, date collected, etc); dataset preview.
Needs: intuitive navigation; top line metrics on datasets (total # of datasets, recently added/most downloaded data); curated datasets and visualizations; easy navigation to sites outside of HDX.
Needs: ability to personalize notifications for new and relevant content (datasets, visuals, blogs); apps for specific data.
Needs: data visualization preview; integration with data visualization software and statistical tools; comprehensive metadata; data quality ratings.
Needs: intuitive navigation; powerful search; easy uploading; clear metrics on datasets and users; data in a variety of formats; integration with sophisticated analysis and visualization tools.
Do any of these archetypes resonate with you? What are we missing? Take the 10-second survey below to help us prioritize what the HDX development team should be working on.
Once we settle on critical technical features, we will be exploring the services we offer with the platform. For example, does ‘the busy person’ need live support, so that she can resolve an issue quickly? Does ‘the browser’ need tutorials or videos to help him learn about the site? Does ‘the power user’ need detailed reference documentation? Tell us what you think.