Process
Thanks to the great pre-effort form our data journalist, we had a solid base to build on. We decided to develop an interactive piece and on day one we all sat together at a table: a journalist, a developer, a designer – and later a photographer too.
There are two parts involved to tell the story of the environmental impact of Spaghetti bolognese:
- the process of picking ingredients and
- the result score board of what's been chosen.
Working in the role of the designer for this project, I focussed on how to find the solutions for those two parts.
1. Mental Model
In both, the picking process as in the scoreboard and the meal's ingredients play an important role. In the first stage I laid out and structured the decision tree of ingredients. At the same time I also explored possible visual languages.
To make the ingredients "pickable" a mental model needed to be defined – or simplified: The experience can either simulate a shop or a kitchen. So we asked ourselves: will an ingredient land in a grocery basket or directly in a pan once it's been picked? We decided on the latter and to pursue the cooking metaphor because, like in a recipe, it applies an intuitive order to the ingredients. Also there’s a more emotional appeal and aesthetics to cooking known from instagram and other platforms.
2. Interaction & Feedback
While the above mentioned parts are easy to separate – first picking ingredients and secondly showing the result – there's also the possibility of giving more direct feedback after an ingredient has been chosen. This would probably enhance the fun of interactive exploring.
Imagine these two variants of interactive models:
A slideshow that moves forward whenever the user picks an ingredient and – once all ingredients have been picked – presents the result on the final slide.
A set of two-sided cards, each showing an ingredient on the frontside and the (hidden) result on the backside. Once a user clicks on an option, the card immediately flips and unveils the ingredient's result.
Since the story is all about commenting on the outcome, this decision wasn't easy. Texts were even planned to be partly generated depending on what had been chosen and it was decided to tell the story along boths results, the ingredient's and the overall results
To find out if direct feedback is something desired by a user, we did A/B user testing and got a clear feedback: users don’t want to get disturbed in the process of picking ingredients and are satisfied to have a summarized result at the end.
3. Layout
Choosing the slideshow interaction model, we needed to solve certain space problems. Therefore I sketched out every slide to get a feeling of the amount of information and space in use.
Since we wanted to show not only the final slide but also the separate ingredient results, providing multiple result slides wasn't a solution. To gain more space, we decided to go for a vertical layout and to place a picker wizard on its top. Like the slide show, the wizard let's the user pick the ingredient options but – once completed – it won't display results on the final slide. Instead the result will appear below the element.
We learnt from testing our interaction models to award the user when all ingredients are picked. Therefore we decided to directly display the final result first – followed by the results of the ingredients.
4. Design & Visualization
The finetuning of the design included
- finding a visual unity for the ingredients and
- finding a form of visualization for the result score – for ingredients and the final score
Using an iconic language for ingredients was imminent as they were introduced in the picker wizard and later re-used on the scoreboard. I started by creating sketches ...
... which I digitized and colorized by the use of very simple background shapes. It resulted in a colorful and playful set of icons:
For the result scores I explored different kinds of visual expressions of data. Using a vertical layout made it obvious to use a horizontal scale for measuring the whole and its parts, the ingredients.
I started by using a strip plot to encode the ingredients and the whole recipe's UBPs (Umweltbelastungspunkte). Because of the filigranity of the strips, we decided to use a bee swarm plot: its y axis has no means but allows for a better density visualization. In the beginning, we were thinking about letting the user try out the recipe multiple times and let him/her see the "improvement" expressed by the two bars in the example below. In the end we decided against multiple attempts to keep things simple on a technical level (browser reload is everyone's friend).
For rendering the final bee chart everyone of the team was involved. While I designed it in terms of colors and dimensions, for working in the browser it needed to be split into two layers. The first one was plotted out in R by our data journalist and contained the swarm of all possible recipe combinations. The developer then included this bitmap image and laid over the selection ring at exactly the right x axis position to highlight the dot of the chosen recipe. Or to “to highlight a dot”: While the result was only simulated, it was technically the only way to let the browser visualize the over 30k possibilities.
