Data consumption

Over the past few weeks I’ve been thinking about concepts of “data products” and how the approaches and methods of Service Design and User-Centred design might be applied to designing data that isn’t encapsulated into a user interface.

Quite often people in the world of Service Design come from backgrounds that aren’t particularly technical. The concepts of data that are crucial to good data design can therefore feel somewhat abstract, or too deep down in the tech. Trusty tools like entity-relationship modelling can be regarded as engineering concepts, not design facilitation techniques and artefacts.

But being able to create good data products that provide information in structures and formats that are consumable and practical for people to use in various forms is very much a human-centred rather than engineering challenge. How you get data into those products is where the engineering sits.

One idea that has been bouncing around my head is to describe different types of data needs, generic and high-level but related to what people will do with data. So far I have identified the following:

Data to action

Much of the data we need in day-to-day life is required for us (or for a system) to then take appropriate action. When I use the self-checkout at the Co-Op at the top of our road, after I have finished scanning items, the final total to spend is data that requires me to action the payment. The data of my doorbell ringing is telling me that I need to answer the door.

The timeliness of this data is likely to be important, but not all actions are required to be instantly triggered.

Data to monitor

We might use data to primarily give a view of how a service is running, and then escalate into action if something appears to be going wrong. The data of your speed on the speedometer of your car, for example, is there for you to monitor your performance, and then take action (slow down) if you go above certain thresholds.

Similarly, information in a contact centre about call waiting times or call handling times will give managers the information to, for example, deploy additional staff when certain performance thresholds are breached.

The timeliness of this data is important, and the data itself is likely to be time-related (readings at points in time).

Data to assure

Sometimes we need data which is highly unlikely to be used, but is there to provide a level of assurance. Backups of information kept in case of a system failure would be one example. Many transaction records are there for assurance too – there potentially for reference but rarely if ever accessed.

My hunch would be that for most organisations, by volume (excluding audio or video) most data exists for assurance, either real, obligated (through regulation) or perceived (I’ll keep this data just in case).

Timeliness is probably not so much of an issue here.

Data to gain insight

Data for insight is where I think a lot of people’s thinking goes when talk turns to “data”. Data warehouses, cubes, lakes, cottages, fabrics and beach huts (I might be made some of those up) provide the ability to slice, dice and otherwise abuse data from (usually) multiple sources. From that we can draw insights, and from those insights take action.

Except that often these platforms aren’t used like that at all. Too often the slicing and dicing is used to produce data that sits in Powerpoint slides to provide assurance within an organisation. Maybe the shift we are starting to see is that data goes straight to the people (or the systems) that need to take action without the people in the middle with spreadsheets. And with all the risks of reinforcing biases from historical data that that might entail.

Are there any other types of data consumption that I have missed?