Best practice #1: start with the end-user, not the data
In most organisations there is a (big) gap between data teams and end-users. This gap manifests itself in a difference in data literacy, language, data trust and more. Two weeks ago I led a short discussion at a data conference about some of the challenges surrounding this gap and the best practices that can, in our experience, help to bridge this gap.
Since the best practices were received well, I want to share them in a series of blogs over the next few weeks. Since many data-related problems are recurring at a wide variety of organisations, I think it is worthwhile to put some to paper. Maybe it will help you!
But before we dive into the best practices, let’s very quickly touch upon three challenges we used as a starting point during the talk. The best practices aim to bridge these problems.
Most end-users, think decision-makers or managers, are not data-experts. Far from it. Among most, data literacy is very low. This literacy deficiency results in a big gap between the data experts and the decision makers.
Most people are not data experts. They don’t understand the complex tools and methods associated with data. They don’t know what they can use data for. They don’t know what questions they can ask of data. And they often don’t trust the results.
Miscommunication between data teams and policymakers
Miscommunication is a result of the first problem. Data experts are way ahead of end-users in terms of understanding what is possible with data and how to use it. This results in miscommunication and friction and lessens the potential impact tools built by data experts can have.
This was a third problem that comes as a result from the first two. If you don’t understand the models behind it, will you trust the outcomes? An early warning system can predict a food shortage in Burkina Faso, but if the model isn’t trusted by decision makers, the insight is lost.
Insights from tools and algorithms were often ignored because the data wasn’t understood or trusted.
After determining some pressing problems, we switched the conversation to best practices. How can we (start to) overcome these problems? Are there practical tips and tricks that help?. In the coming weeks I want to share several with you. Today we look at #1.
Best practice #1: start with the end-user, not the data
The most common data implementation track we see starts in the office of a data team. They have the knowledge and the skills to look at available data and develop a valuable new tool that can improve a certain aspect of the operation. This tool is then handed over to the relevant end-user. But here it hits a snag. While the tool might be capable, the end-user often feels like receiving an extra burden, lessening adaptation and impact.
In our view, this is exactly the wrong way to go about it. Don’t start with looking at the data available, but start with what the end-user wants.
That is easier said than done. A big part of the difficulty lies in the fact that the end-user often doesn’t know what (s)he wants from the data. What is possible and what isn’t. Low data literacy is a big limiting factor.
To overcome this, asking the right questions is key, but what are the right questions? In our experience we should not start at what kind of data someone needs, again, she often doesn’t know, but start at the goals she needs to reach. The one asking the questions then needs to see what data to use and how.
The expertise needed for this is rare, since it requires someone that can talk to both sides, knows what is possible from data and knows how to ask the right questions.
What are the right questions? In our experience we should not start at what kind of data someone needs, again, she often doesn’t know, but start at the goals she needs to reach. The one asking the questions then needs to see what data to use and how.
One of the tricks we use is to develop hypotheses with the end-user. These hypotheses are not about what kind of data she needs, but what she needs to reach her goals. The tool is the means to reach those goals.
Let’s illustrate that with an example. Say the end-user is responsible for the roll-out of a new product in the Netherlands. Together with her, we can determine one or multiple hypotheses. A relatively simple one would be ‘Our ideal customer has a higher education, is between 25 and 35 and lives an active lifestyle.’ We can then use that hypothesis to find the right data sources to answer that hypothesis.
Of course, a Smart Map usually doesn’t contain one limited hypothesis, but dozens. But combine multiple and we can determine what the right user groups are, what the ideal place is for rollout and how we should proceed.
Getting these goals and translating them into actionable tools is not easy. You can use a variety of brainstorms, workshops, interviews, demonstrations and design sessions to come to the most valuable solution.
In each custom project we do, we start with a four week Quick Scan, where we use the tools and tricks mentioned above to get a clear understanding of what an end-user needs. We deliver design mock-ups before we start writing a single line of code. This ensures that an end-user truly gets the tool they need to increase the impact of their work.
To sum it up. In our experience a successful final product is always built with the end-user in mind. Ask the end-user the right questions before you start building. Don’t ask what data they need, ask what goals they need to reach and translate those into the data tool the end-user needs.
Keen to know more? You can schedule a call here, or check back next week, when we’ll talk about best practice #2: collaborate in the building the tool they need.