We’d like to share in this post our thoughts after the workshop at Young Foundation in London: it gave us the opportunity to think over the (communication) design process in the context of controversies mapping and the way this process should work in order to produce meaningful visualizations and to make the whole EMAPS project more effective.
The relationship between mapping of controversies and communication design is a recent one, and – in our knowledge – there are no documented case histories we can build upon. We’re experiencing since two years the application of communication design specific competences in cartography of controversies: we worked mainly with students so far, and with a limited scale both in terms of people/organizations involved and project duration, compared to EMAPS. So we really think that the EMAPS project in general, especially in this phase, is a great opportunity to discuss, define and test a possible model for our design process, through a typical learning by doing approach. We’re now finalizing the work on ageing and moving towards the next (and bigger) controversy; we’re now in the middle of a new iteration with new users and stakeholders: what better opportunity to refine our design process, building on what we learned in London? Well, evaluating workshop’s maps is difficult because the visual design criticalities are mixed with data ones: if a user, using a map, doesn’t find anything interesting, is it a design criticality (we’ve not been successful to convey the data richness) or a data one (the data is useless for user’s needs)? The same data, shown in a different way, would have been more effective?
In our experience, it is very difficult to answer these questions.
Why is it so difficult? During the map creation and the workshop, we identified two main criticalities that can be summarized in two main issues:
- The “Why”: it is not clear to the user what kind of information data should convey (like the Wikipedia maps). “Why are you showing me this?” It should be clearer from beginning why a certain data is useful to answer a research question.
- The “What”: drawing the maps, we found difficult to identify the data features we have to spot out. From the same dataset, we can focus on several features: which ones are useful to find an answer the research question? Before designing it, we must be able to answer this question: what the user must see with this visualization?
We strongly believes in data visualization potential. While our role is closely related to the final output, our involvement should not be only a “cap” on top of the research pipeline. Visual design doesn’t just make things more catching or sparkling – it makes things visible. Data errors, mistakes and criticalities will be more evident in visualization. This means that an effective visualisation, based on faulty data, will return a faulty interaction with the user.
As we are using protocols that often return uncertain data (due to the nature of the subject matter), it is important during the whole process to evaluate whether we’re still creating information that really answers the research question.
If the above information (why we are presenting that data, what should emerge from it) is clear and shared, the design process is more robust and simpler to evaluate.
As we saw during the first experiment (London) the process is neither standard nor linear. It is a process made up of many loops, which are difficult to predict. Our suggestion is to break it in four main phases in which design have a different level of involvement to evaluate the process effectiveness.
The description below is qualitative: phases are not temporally equals, depending from the context they can be longer or shorter, and sometimes can overlap. Our main objective, the one we’re asking your opinion, is to set a series of goals for each phase.
First phase: hypothesis
Dialogue between domain experts and data experts in order to identify research questions that is possible to answer using chosen methods. Both of them must keep in mind who the users are: will they be able to get the answer from the data produced?
Even if the data is not yet available, researchers should identify what kind of information they will create: which are the objects? Which are their properties? Are there links between the elements? Are there different kinds of objects?
Design won’t play an active role in this phase, but it must have a clear knowledge of the research question, the used protocol, and what kind of information should emerge from visualization.
The definition of the data architecture (elements and properties) is the base for a visual hypothesis: how can we visualize this kind of information in order to enable users to build their answers?
At the end of this phase, the designers should know:
- The research question
- The analysis method that will be used and the output (data) it should give back
- Why that kind of analysis is useful to answer the research question (it must be explicit!)
Second phase: data extraction and validation
Data experts should identify what are the data sources, the analysis protocols, and set up the data extraction.
During this phase, it’s important for the design part to identify the data format they’ll need for the visualization, and the process to get it from raw data.
Moving from the raw data to visualization or interactive application implies lots of work on data itself: each visual model requires data builded in a specific way. Actions like data cleaning, normalization and transformation occupy much of the design process. These actions must be replicable as raw data can change (a new extraction, the identification of an error in the protocol…).
Objectives of this phase are:
- Data format definition
- Setup of data transformation process
Third Phase: sketching
Sketching in the framework of data and information visualization is not a linear process, but a cyclic one: depending on the complexity of the research questions and the data provided, it can require a different number of iterations.
As the data we’re using most of the times is unpredictable before the extraction, we have to proceed by trials and errors. We call “sketches” simple visualizations, produced on sample of real data, useful to evaluate the initial hypothesis. We want to remark the importance of using real data in this phase: the same visual model can be effective with a specific data but useless with another one. Just drawing an ideal case is not a valid proof.
Sketches validation requires the involvement of data experts and domain experts. Is the visualization respecting data features? Is it showing something real? Is the visualized data useful to the initial question? It’s useful to identify some research sub-questions to test the extracted data.
A second cycle of revision/validation is held with the final users. Can them find an answer to the research question with the visualization?
These two kinds of cycle help designers to correct the visual hypothesis to meet researchers, experts and users needs.
Fourth phase: production
This phase is the finalization and implementation of the visualization / interactive application. All the corrections and suggestions are already gathered in the previous phases, there is a full concordance on the shown data. Design can focus on communicative issues (perception, interaction features,…) having a clear vision of the visualization objectives. Revision cycles are focused on fine-tuning of visualization (readability, visual hierarchy…) and on interaction patterns (if producing an interactive application).
This post is an open proposition, we really need your help: tell us what you think about it, in order to define a shared model of our design process.