Information design is one of the most interesting fields to me that relates with the User Experience. How users perceive and understand the information based on what we show them and how they interact with it, it is like trying to create a language that goes beyond the interface and the standards. It is challenging and, sometimes, uncertain.
However the other day I had a déja vu while one of my mates was sharing a research made on an data analysis use case. Suddenly I felt I’ve been solving the same problem of information design over the last three years.
We talked about how raw data becomes information, and how there should be another data that represents the meaning of that information, and how past events may affect to current indicators or not. We talked about the visualization of multiple charts were the only way to understand some concepts, and how users should decide the events and configuration to provide real meaning beyond the data values.
I’m not going to enter into specifics on that use case, but the problem that reminds me the same kind of question was the one that I worked for years: the Electronic Patient Record (EPR).
In an EPR there are some information which indicates current health status: vital signs. This can tell you if you’re alive, getting better or getting worse. It is also a clue to start investigating what made you feel bad.
That’s one level of information based on data collected directly from a person. Of course you can collect more data like a blood test or a urine test or similar.
Another level of information is just the history of every visit to your doctor. All of them with symptoms, diagnosis, and treatments. Those events could be related between them by episodes (let’s say a flu, a pregnancy, a surgery…) and, in a different level, related by the diagnosis of an illness (let’s say cancer, diabetes, etc.).
The problem you have is that you need to navigate information from different layers based on different levels of the data abstraction. And you want to find correlations, make differential analysis and causations at any level, because you don’t really know what’s the cause of the problem.
What I thought it was similar is that when we model the problem, we have to provide meaning to the data abstraction and that requires an understanding of the user mental model (In my case how doctors research on data).
Another leg of this problem is how users can interact with the data to find how it is related. We cannot solve everything with a static picture of the data.
Last, but not least, we needed to represent very clearly what is the data in a relevant present (24hours, 7 days,…) and what belongs to the history, and how history is explored and contrasted with present data.
Somehow I felt the problem was always the same, and the only thing that makes it different is the kind of person who typically interacts and uses the data. So the solution should start to understand his/her mental model and define the model of the data meaning based on them, instead of the defining the data model of the system that is meant to represent it.