Data, Design and Uncertainty

Originally published on github: Data, Design and Uncertainty

Something that’s been nagging at me is how much materials I’m reading (on data and design or data and storytelling) focus on working in an environment of certainty: goals are clear, missions are understood, time pressures seem nonexistent.

Data should serve, support and enable, so how do you navigate that minefield of uncertainty?

Let’s take a look at some approaches from people working in uncertain environments.

Understand the obstacles, yours and theirs

“Your competition is any and every obstacle your customers encounter along their journeys to solving the human, high-level problems your company exists to solve” says Tara-Nicholle Nelson in Obsess Over Your Customers, Not Your Rivals.

Nelson, who has a background in marketing, is reflecting on lessons learned from their approach at MyFitnessPal. The article is about rethinking competitor analysis but resonates for data people working with organisations where uncertainty is the main certainty.

Tara-Nicholle recommends using information (and data!) to discover roadblocks including:

  • user data
  • surveys
  • ethnographic research
  • online listening
  • subject matter experts
  • third-party data

Handily, the article includes some examples from MyFitnessPal to give some context on how to successful discover and remove roadblocks.

In my role as a consultant, I have some preliminary (but untested thoughts) on roadblock. The competition here for my customers is that they know my services (data + storytelling + design) are important but they can’t always articulate:

  • their goals for the project
  • how they’ll know the project has been successful
  • how the project supports their mission
  • their own data ecosystem and lack the means and framework for doing so (thanks to Ade for highlighting this)

Time (I believe) is another obstacle my customers face. Getting the right people in the room and giving the project enough resources and support to thrive can be a challenge. These are assumptions to test to help me understand my customers better and better help them get what they want out of our relationship.

It’s been useful to learn about obstacles, but I think there are more tricks of the trade, so let’s move on.

Ask the right questions to frame the problem

Asking the right questions to frame the problem is Ben Holliday’s recommendation. As a Chief Design Officer, the focus of this article is on designers, however, “framing the problem is something that teams really struggle with” resonates for anyone working with uncertainty.

Ben Holliday’s is to ask the questions:

  • Why are we doing this work? or What is our motivation for building this product or service?
  • Who are our users? or Who do we think would need to use this product or service?
  • What outcome will users get from this service? or What problem will it solve for people?
  • What outcome are we looking for? or What problem will it solve for our organisation?
  • What are our key metrics? or What do we need to measure against these outcomes?

Ben also covers how to ask the questions, starting from motivations then digging deeper into alignment and finally measuring success.

The questions could be even more useful with some examples and context: why am I asking this and what can we do once we know? I think of these situations like having a giant puzzle — answering each question gives you a piece to build up the picture so you can solve the puzzle. The questions are variations on those found in books on agile, design and user experience (UX), which may be why they are summarised.

The client is the expert, put them front and centre

“It’s not as sexy because it now places the client as the expert instead of the consultant” says Zeroth Labs. The Singapore-based start-up blends anthropology, data, and design with experimentation as a new approach to development consulting.

Like Tara-Nicholle Nelson, research is high on the agenda. Zeroth Labs’s describe their approach in Using anthropology, data and design thinking to disrupt development consulting as:

  • Conducting their own ethnographic research
  • Applying behavioral science
  • Testing, testing, testing

Essentially Zeroth Labs is understanding their customer’s customer using these methods to “build the capability for developing countries to make life better for citizens”. Another approach that could be useful for people working with developing companies.

Help your customers help themselves, by giving you advice

“Teach a man to fish and he’ll know how to fish — but get him to teach others how to fish, and he might actually get on with some damned fishing.” is Oliver Burkeman’s analysis of psychology research, Advice versus choice.

In Why it’s wise to give people advice, Oliver reflects that “giving advice reacquaints us with the knowledge we possess, which instills confidence, which motivates action”. Unfortunately, as the original research is behind a paywall, I can’t be certain if the interpretation is justified, but let’s go with it.

If it’s the case that asking our customers for advice about their areas of expertise will make them more bought into the project, build confidence and skills, then this sounds a lot like co-creation. One thing I can tentatively acknowledge is that as a specialists in data, my customers have the expertise, or can at least point me to the people who do.

In my projects, like the CRM and digital transformation project for Freedom Studios, I’ve encouraged a collaborative approach. We started with me leading the way, transitioned to me facilitating, then ended with my customers telling me what they needed. By the end of the project, we had clarity about the goals and capabilities of the CRM, new skills in the organisation and confidence in the system.

Co-creation works when customers are willing to put the time in and use the outputs outside the project. If whatever lessons you’ve learned are put aside after the project, it’s unlikely any changes will stick.

And in conclusion

Here’s what I learned today about approaches to getting clarity as a data professional working in uncertain environments:

  1. Understand the obstacles, yours and theirs
  2. Ask the right questions to frame the problem
  3. The customer is the expert, put them front and centre
  4. Facilitate them to advise you
  5. Collaborate and experiment to find the right approach

How do you deal with uncertainty? Comment below or tweet me.

What’s there? What’s missing? Quick guide to understanding data completeness

When we talk about coverage or completeness, we want to know a couple of things. First, what’s there? and second, what’s missing? We want to survey the land and get a short but complete overview. How do we do this? We look at our data from more than one angle.

A map is not the territory…

Data is a tool

It represents something we’re interested in. That thing could be cars, loans, flowers, or cups. Whatever it is, we want to record or review information about it. Knowing can help us sell the right cars, guide our clients to the right loans, report on the state of the flower industry or manufacture more instragrammable cups.

A white cup in focus on a table with a blue tablecloth in the background

Data describes concepts

It represents ideas we’re sharing. There are many styles and shapes of cups in the world, but the icon of a cup is pretty much universally understood. I may not know the style or shape of your cup but I understand “cup-ness”.

Cup Icon by Design Revision

How does this help us understand completeness?

Let’s take a step back. We’re unlikely to be interested in every cup that ever existed, so we have a scope. Let’s say we’re interested in cups we make and sell. Our universe of cups is limited to just those cups.

We want to know a few things about our cups: the materials we used, how large or small they are, that sort of thing. So we decide on headings or columns for each of the attributes (information about cups) that we’re interested in.

cup schema

This list of things about cups is the schema. It’s a template that describes what we want to know about cups. It isn’t our data on cups (we’ll add that under the headings) but it gives us some direction about what to record.

Unlike the concept of a cup, the schema of a cup isn’t intuitive. We’d struggle to instantly recognise “cup-ness” by looking over this list. We’ve taken reality, abstracted it to a concept then made that into a schema which is the container for our data.

So back to completeness. When we talk about completeness, we could be talking about the concept or the schema. These are different questions but together gives us insight into the state of our cup data.

  • Concept – How many cups are we reporting?
  • Schema – How many cup attributes are we reporting?

Concepts & Schemas: How are they different?

In general, when we talk about a concept of a cup, we have a list of information we need to understand “cup-ness”. So we may agree it’s not a “cup” unless we have these things: cup#,  name and type. That’s close enough to our concept of a cup that we can ask questions about the number of cups. This is the sort of information we use to plan campaigns, make strategic decisions and launch new cups to the market.

In reality, we don’t record everything diligently. We miss things out for a host of reasons. This is even more obvious when we aren’t recording the data ourselves.

Data has gaps

Understanding where those gaps are is important. Gaps affect how we report on concepts. If we’re missing cup names, that reduces the number of cups we report. We use information about gaps to improve our data collection so that we can make better strategic and planning decisions.


The upshot? To understand how complete our data is, we survey our data landscape in two ways: by concepts and by schema. We can count conceptual cups or count cup attributes to find what’s there and what’s missing. The two strands help us understand what’s going on in our data.

  • Some things (or attributes) are more important than others, they map to concepts;
  • Some things are conceptual (“cup-ness”) others are schematic (the cup attributes);
  • Some things are more useful for planning and strategy (concept) and others for improving data quality (schema).





Legacy Code Rocks: Open Data with Edafe Onerhime

I just loved chatting with Andrea on the Legacy Code Rocks! podcast. Listen: Open Data with Edafe Onerhime

Edafe Onerhime is a consultant on Data Science and Data Analysis who has over 20 years of experience answering difficult questions about open data. She has helped governments, charities and businesses make better decisions and build stronger relationships by understanding, using and sharing their data. In this episode, we discuss the history of open data, its importance in building communities and its similarities to open source and open science.

Have a good open data policy

Can I Trust Your Open Data?

You want people to use your data. They want confidence that they can trust your data and rely on it, now and in the future. A good open data policy can help with that.

An open data policy sets out your commitment to your open data ecosystem. It should detail how you will collect, process, publish and share data. It will set expectations for anyone using your open data and if you stick to it, lead to confidence about what to expect.

You can create your own open data policy from the Open Data Services  open data policy template, check out the Sunlight Foundation guidelines or Socrata’s How to develop your open data policy article. Here’s some open data policies in the wild:

Remember: It’s not enough to have a policy, you have to stick it to build trust and confidence in you as an open data publisher and in your open data.

Make It Play Well With Other Data

How do I make my open data as useful as possible? How do I connect it with other data to boost insight? How do I answer really tough questions with open data? Make it play well with other data – make it interoperable.




(Computer Science) of or relating to the ability to share data between different computer systems, esp on different machines: interoperable network management systems.

 Why should you care about this?

If you want your open data to help answer questions, solve problems, boost the economy by fuelling innovation or used in research, you need to go beyond names and places.
Do these mean the same company?
  • ACME
  • ACME Limited
  • A.C.M.E
How about now?
  • GB-COH-123456: ACME
  • GB-COH-123456: ACME Limited
  • GB-COH-123456: A.C.M.E
Bit more confident? You can take that code 123456* and find the company on Companies House (Hint, that’s what the GB-COH- tells the machine using your open data!). Go you, you’ve just opened up a whole new world of information! This example is using a shared standard way of talking about organisations, find out more on
(* P.S This is just an example, ACME doesn’t really exist!)

Now what?

You can start to answer question like this:
Answer tough questions with good quality open data
Answer tough questions with good quality open data
These codes or Identifiers are  a gold mine. Every country has agencies that give codes to businesses, charities, non profits and more. Use those codes where you can.

Can I share codes for anything else?

Of course! You can identify places, things, categories, types and much, much more.

Tip: Make your open data more useful by making it easy to connect with other data.

See all the tips in one place: Good Quality Open Data

More on: interoperable
Courtesy of Collins English Dictionary – Complete and Unabridged, 12th Edition 2014 © HarperCollins Publishers 1991, 1994, 1998, 2000, 2003, 2006, 2007, 2009, 2011, 2014

Information commons for the UK charitable sector

Exploring how 360Giving underpins the data infrastructure for charitable grant making and how it supports an information commons for the sector. It all starts with a little clarity.

For 2 years, I helped funders open up information flow in the non-profit sector by publishing what they fund. This is powerful insight. Understanding the 360Giving data standard is crucial for more funders to adopt it.

Funders need to know:

  1. What is the data standard?
  2. What must be provided, what’s recommended and what’s optional? (and why?)
  3. How does the standard fit together?
  4. How does our data map to the standard?
  5. How can we ensure we’re telling the true story of our funding?

Supporting the standard meant creating tools, reports, and visualisations to provide clarity and provoke discussion (the standard isn’t static, so your voices as funders, data users, tech and non-profits are hugely important).

One question I hadn’t answered to my satisfaction was “How does the standard fit together?”. So I created a data visualisation to explain what 360Giving helps you share and how it’s put together to support good quality open data on funding.


360Giving Data Schema Visualised
360Giving Data Schema Visualised


With funding information shared in a similar way, charitable grant making organisations can ask & answer questions like:

  • How can we share the story of our funding?
  • Can we find partners by sharing our grant making?
  • How can we tackle our shared missions together?

Sharing data openly connects organisations. That’s why open data is the basis of a shared charitable sector information commons. Historically, the non-profit sector had it tough – no-one wanted to fund infrastructure. Here’s what Friends Provident Foundation‘s Danielle Walker-Palmour had to say at a social investment event:

No one wants to fund infrastructure – we need to think of infrastructure as a commons to achieve our sector’s collective goals.

Times and perceptions are shifting; Barrow Cadbury‘s Connect Fund is making headway investing in infrastructure for social investment. Similar initiatives are expected to follow.

A shared commons of information needs standards that make information simple to combine, easy to understand and usable by organisations of every size. The 360Giving data standard is an integral part of the commons and the sector’s data infrastructure. The goal? A shared information commons that sees more of the non-profit sector working together, seamlessly.

Here’s the original Twitter moment: