The Process

There's a method to the madness.

The Approach

Our increasingly dynamic, multi-faceted, and datafied world requires new visual data languages in order for us to make sense of it.

The central goal of our work is to craft unique, elegant, intriguing, and expressive data experiences that empower people to take part in the digital society in a meaningful way.

Consequently, our projects reflect our position not only on how to present data and information, but also how to collect, how to measure, aggregate, compare, juxtapose it, in which granularity, for which people in which context, and to what end — aiming at a holistic view on human-data-interactions.

The Process

To that end, we have developed The Process — a robust system that consistently leads to solid, and occasionally to genre-defining outcomes. It is based on the practical experiences of over 15 years of applied data visualization projects in various team and client constellations.

The following principles have become core tenets:

  • Purpose-driven
    We clarify Why, What and For Whom before worrying about the How too much. The application we build needs to make sense, and needs to help make sense.

  • Hands-on
    We design with actual data, using code and in contact with our audience. Excellent data design emerges only from an open dialogue with the data, and by confronting users, designers and project stakeholders with intermediate data representations. "Data goes here" is not a valid design strategy for data-intense projects.

  • Iterative
    Explore, design, evaluate, rinse, repeat. Insights cannot be simulated, they need to be experienced. Visual languages need to be tested, and refined.

  • Truth > data
    All data is incomplete, biased, and imperfect. But some data is closer to the truth than others. At all times, our goal is to show the right perspective on the data. We think and act foremost like a journalist — not like a salesman, entertainer or engineer.

  • Stay flexible
    Dynamically adjusting The Process to the project at hand is part of The Process, and no method can replace reading the room and thinking on your feet. Keep listening — to yourself and others.

The Phases

There are four main phases to a full project. We can end at any phase, but none of them can be skipped.

0. Pre-project

Before we start working, we need to establish the fundamental viability of the project:

  • Does timing, budget range, and purpose of the project align on all sides?
  • Are all fundamental requirements met?
  • Are there any red flags?
  • Is it evident that our highly specialized skills and approach are the best possible match for our client's needs?
  • Is everybody ready to follow The Process?

1. Discovery

The question of how we visualize data must be embedded in a crisp understanding of why, what and for whom we are visualizing.

The discovery phase clarifies these questions in a data-driven, user-centered way before diving into the "solutions" mode.

There are three important, parallel streams of exploration:

I: Listen, observe and understand
Strategic objectives and user needs

  • What would be the impact of an ideal project outcome? Can we quantify it?
  • What would be a project failure?
  • Who will use and see the product? Are there different user groups?
  • What are they hoping to get out of it?
  • How else is doing something similar? What else has been tried before we came on board?

II: Iterate, test, experiment, play
Get your hands dirty and be inspired by the data material

The other important source of information in this phase is the data itself. We use low-fidelity, easy to use prototyping tools like Tableau, RAW, Illustrator etc. to generate many quick views on your data. It is essential that we work with actual data right from the start. We cannot start this phase without a realistic, high quality data sample.

This data deep dive helps us to:

  • Understand the scale and texture of the data
  • Explore the semantics of the data dimensions, and discuss fitting metaphors
  • Be directly in touch and get inspired by the data material: find insights, data stories, shapes the data suggests, but also limitations, shortcomings and gaps in the data

In short, we try to get closer to answering the question — "What would the data want? And what does it have to offer?"

III: What's the genre?

Finally, the tone and format of the project is crucial to define in this phase as well: Will it be a scrolly-telling web-site for a wide range of audiences? A highly-specialized tool for experts? Infosnacks between metro stations? … A perfect match needs to be made between projects goals, constraints, and opportunities.

The outcomes of this phase are a crisp concept of the project, covering

  • data assessment
  • project objectives
  • audience characterization and tasks
  • exploratory data visualizations, basics of a visual data language
  • promising data perspectives
  • project format

Only covering all these perspectives will provide us with a clear scope and direction for the following project phases.

2. Design

The design phase is all about decisions on how we achieve the objectives laid out in discovery. Good design is always tightly intertwined with the content it presents. We think about about what to show; what to leave out; what to highlight; how to structure information; what rhythm, visual flow, and pace, you want your story or tool to have.

The results from the discovery phase provide us with ample material to develop the information architecture, centered around the most important data perspectives and user tasks: What are the main functional components? How do they play together?

Second, we develop a rigorous, coherent visual, motion and interaction language that informs a refined look and feel for the project. Our design is centered around the most fitting visual encodings — given structures the data suggests, our users' mental models, their information needs and actions to be taken. Our aesthetics is never self-serving, or added as an afterthought, but deeply informed by the data and user interaction itself.

We design systems, mapping data to perceptual channels, reacting to user input. This can only be done through code, using iterative design strategies, with real data.

Consequently, the main deliverable of this phase is what we call the "80%" prototype: a working implementation of the key data views, demonstrating the most important user flows and interactions, built on a realistic, but static data set.

It is complemented by documentation around behaviors and features not obvious from the prototype, as well as a style repository. Together, this serves not only as a specfication for the implementation phase, but also proves that our ideas are viable and lead to interesting insights and valuable perspectives on the data.

3. Develop

We take crafting the production version to a high level of refinement very serious. Real artists ship, and the greatest conceptual idea will not fly if it's not executed on point.

Our strategy is to build from the inside out — produce a Minimum Viable Product around the most important use cases first, before expanding further.

Not all design decisions can be made in advance. Also during the production phases, a vital ongoing discussion between code, design and data analysis remains important. We keep evaluating features and trade-offs, and tweak designs once we see how they work in real settings.

We make sure to feature freeze well before final launch, in order to leave enough room for testing, refinement, and the detail touches that make a software product shine. The last 20% are the second 80%.

We will always trade a less important feature for better help contents, promotional material and technical documentation. You can have the best solutions, which are worthless if nobody knows about them.

4. Deploy and assess

The Thing is out, and it's time to celebrate!

We de-brief and check back with our initial notes. Did we meet the defined goals? How did The Process play out this time? How could things have worked better?

And, a lot can be learned from observing people interacting with it. How much time do users spent with your visualization? Which options do they discover and which are they missing? When they comment on or link to it - which parts of the project did they find most interesting to mention and refer to?

It is advisable to keep iterating after the initial launch. Once the product is out in the wild, one sees more clearly its strengths and weaknesses.

There you have it. Thanks for reading so far, and looking forward to collaborating!

— Moritz Stefaner