Weeknotes – series 03 episode 05
Wellcome data labs
I was excited to learn about Wellcome Data Labs, a part of the Wellcome Trust that's combining data science and user research. I don't know of many other teams that are embedding user research and UX (User Experience) practices this closely with data scientists and, even better, they are blogging openly about it.
Although the title nearly put me off (Tableau Best Practises Put to the Test), this is a really good blog post that looks at how the team did usability testing and challenged some bits of received wisdom around how best to design data interfaces.
I had a chat with Laura Kösten, a PhD candidate at the ODI (Open Data Institute) and a senior research assistant at the School of Electronics and Computer Science at the University of Southampton.
She showed me some of the stuff she's working on, including this data summary tool which helps publishers to describe datasets, with the most useful information that users need.
IF, according to their website are a "technology studio, specialising in ethical and practical uses of data". They have a really nice pattern library of data sharing components, which is just beautiful as well as really useful. They seem to work mainly in the space of ethical data collection and privacy, but I still think there's some overlap with the publishing and maintenance of datasets.
They also have some data ethics principles which are available to download in poster format too.
My favourite is "understand the flow of data". This is really hard and so important I think.
Writing requirements as user stories
We had a meeting with one of the teams at Defra (Department for Environment, Food and Rural Affairs). I suggested that a good way for them to share their requirements with us would be in the form of user stories.
I pulled together a few notes (leaning heavily on the excellent advice in the GOV.UK Service Manual).
- As a… [who is the user?]
- I need/want/expect to… [what does the user want to do?]
- So that… [why does the user want to do this?]
In my experience the middle bit is quite easy to write, the user groups are a little more difficult, and the "so that" bit is really difficult.
It was good to have some time to think about user stories and what they're good at. When they're written well they help us to focus on the users and why they are trying to do something.
Obviously, you need to do user research before you can write any of them well, but even with that solid understanding I think they are still a challenge to write well.
Chat to Jeremy Yun
I had a chat with Jeremy, an interaction designer on the GOV.UK publishing platform. He's working on a service that visualises content performance for publishers in order for them to make better decisions about the content they publish.
We talked about the common problem of giving data and visualisations enough context, so that less data literate people can still make use of them.
Things we could try measuring
It lead me to think more about measuring the performance of data publishing and what the metrics could be…
Apart from common stuff like increases in page views and user satisfaction, what kind of metrics are important to data publishing?
These are some early (hopefully educated) guesses combined with a few I’ve pinched from other places…
- Increase automatic publishing workflows
- More organisations publishing
- More datasets
- Increased data quality
- Increased data standards
- Openness of formats
- Completeness of metadata
- Regular updates
- Reduce requests (increase self-serve)
- Reduce duplication (more shared code lists and reference data)
- Ability to format/filter data to low granularity
I also wonder how we could measure inclusiveness? If open data is meant to be easy to access, how can we prove that people with lower data literacy are able to use it? And I'm not talking about the public here, but busy people in central and local governments, who aren't data experts, but still need to use this stuff.