Design process

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.

 

2 Responses to “Design process”

  1. Thank you for this post that structures the experiences of the EMAPS experiences made so far very well. I read through the four phases against the background of the multiple facets of climate change adaptation (different sectors, different spatial/administrative/political levels, different stakeholder needs) and after a few minutes of reflexion on the proposed phases and suggested objectives I would like to add a few comments or open questions which could be discussed among the project partners.
    Phase one points at the central question of how information can be visualized in order to enable users to build their answers and it emphasizes to keep in mind who the users are. As climate change in general and climate change adaptation in special are highly complex and characterized by large uncertainties visualized information can support answering questions and increasing knowledge in various fields of climate change adaptation:
    • visualize the problem (exposure, sensitivity, impacts of climate change): helping to understand the problem of climate change by visualizing the scientific and public/media controversies
    • visualize opportunities for actions (adaptation to climate change): helping to support stakeholders (towards politicians) and politicians (towards the public) in the decision-making process on adaptation actions by visualizing different and controversial adaptation options and their consequences
    The role of researchers (domain experts and data experts) is well described throughout the phases; however the role of experts and users (and their needs) as well as the relationship among and the interaction between these groups could be described more explicitly. This of course depends very much on the specific context in general but especially in climate change adaptation. Potential user groups in climate change adaptation would be:
    • researchers (especially in the explorative phase of research on climate change adaptation)
    • politicians (decision-makers at different spatial/political levels)
    • stakeholders (NGOs, administrative units, representing different sectors of adaptation)
    • the public (supporting public participation)
    In our meeting with researchers from the CHANGES project in mid-August 2012 we will discuss – among others – this post and explore first ideas on connecting researchers and decision-makers from the CHANGES project with EMAPS. The next CHANGES project meetings are scheduled for September 2012 (Romania) and November 2012 (Germany).

  2. Thanks for sharing this Michele. Reading your article and Mark’s comment was very instructive. My first question is more or less the same than Mark’s : are “domain experts” the same as “users”, or the second a subcategory of the first, or are they entirely different sets of people ?

    Regarding the link between communication design and controversy mapping : from a controversy mapping perspective, the category “domain experts” is problematic, because rather than finding a solid basis upon the consensus agreed upon by “all” experts, we tend to search a basis in their disagreements. I think it affects all phases of the process that you describe, though not changing them entirely. We can not rely on a definite set of “domain experts” we are in contact with to stand for the whole community we ultimately wish to address.

    I think that rather than answering research questions, what we do is modify them, displace the users’ perception of what counts in the situation they find themselves in, enable actors/users to position themselves within their domain activity etc.
    As an outsider, I have the feeling (maybe I’m wrong though) that communication design tends to reinforce existing power relationships between data producers and data users, whereas controversy mapping tends to destabilize those power relationships or blur the distinction between producers and users (which makes mapping a very “political” activity). To put it as a question : does making particular things “visible”, as you say, also necessarily reinforce their authority ?

    My personal take on the process : we start with a particular selection of experts who are the primary users of the maps but our aim is not to answer their research questions, but rather little by little to accommodate the questions of other users on the same maps.
    Another way to say it : I am wondering whether the goal of the process is to reconcile the users’ needs and the data vizualisation, or to slightly displace these needs through the vizualisation. This displacement should be small enough so the maps still interest them, but big enough so they start to interest other kinds of users.
    To exemplify with Mark’s categories : if we make maps designed for politicians, then maps designed for researchers, then maps designed for the public etc. I think we will miss the point (unless we are able to connect those different publics through the maps).
    In the end, this raises the point of our own positionning and “ideology” in the process (to be provocative).
    I don’t know whether these thoughts will help, they are meant only to feed the discussion !
    Cheers,
    Axel

Leave a Reply

Spam protection by WP Captcha-Free