In order to sprinkle some star dust into the contents of my book I’ve been doing a few interviews with various professionals from data visualisation and related fields. These people span the spectrum of industries, backgrounds, roles and perspectives. I gave each interviewee a selection of questions from which to choose six to respond. This latest interview is with Jan Willem Tulp, a freelance Data Experience Designer. Thank you, Jan Willem!
Q1 | What was your entry point into the field: From what education/career background did you transition into the world of data visualisation/infographics?
A1 | I come from a software engineering background. At least, that’s what I’ve done professionally before I started my freelancing career. But I come from a very creative family (my dad is a visual artist, my brother is a character designer) and I too wanted to become an artist when I was in high school. I even went to a different high school so that art and art history could be part of my exam, which was not offered at my other high school. But I also liked technology a lot. So, ideally I wanted a job where I could work on both, but at that time it was hard to find it. I studied interaction design, with that intention in mind: during my studies we both learned how to program and to make visual designs. So, for me that was the perfect education. However, at that time companies were either looking for graphic designers or programmers, not someone who does both. So, I ended up in programming jobs, as I turned out to be a fairly good programmer. In my spare time I still dabbled in Photoshop, 3D Studio Max, web design instead of web programming, etc. So, when data visualization started to become a commercially interesting opportunity, I took the leap to start my freelancing career as a data experience designer, creating data visualizations.
Q2 | We are all influenced by different principles, formed through our education, experience and/or exposure to others in the field – if you had to pick one guiding principle that is uppermost in your thoughts as you work on a visualisation or infographic, what would it be?
A2 | My guiding principle is actually that you should focus on learning principles. Becoming a specialist also has it’s value, but even if you’re in a niche like data visualization, it’s very valuable to focus on principles. In my case on programming principles, design principles, interaction principles, visualization principles, etc. The thing is, this world, especially the digital data visualization world, is changing rapidly: new technologies, new tools and frameworks are being developed constantly. So, you need to be able to adapt. But principles are much more timeless. If you know what you want to create, then using technology is just the means to create what you have in mind. If you’re too fixed on one type of technology, you may be out of a job soon. So, keep learning new technologies, but more importantly, know your principles, as they will allow you to make the right decisions.
Q3 | How do you mitigate the risk of drifting towards content creep (eg. trying to include more dimensions of a story or analysis than is necessary) and/or feature creep (eg. too many functions of interactivity)?
A3 | This is a very challenging one. I recently changed my process because of scope creep I experienced. I must say that the risk of scope creep is larger with clients who are not very experienced with data visualization projects than people who are more used to doing these kinds of projects, simply because the former has a much harder time to understand at the beginning of a project what a possible end result can be. And therefore they get a lot of ideas once they see the first concepts. The big ‘problem’ with data visualization is that, if you would compare it to traditional graphic design, you are not entirely free in what you can design; with traditional graphic design, even though you have constraints there too, you are not tied to a dataset. In other words, for a data visualization project, part of the process is figuring out what a good visualization is, taking in to account the goal, target audience, intention, vision, constraints, etc. for the project. And so during the process you will find out what works and what doesn’t. In my experience, if you have too much communication about the visualization itself throughout the process, it is very easy to lose focus, and to extend or drastically change the scope. So, what I now prefer in most of my projects is to have a fixed number of review moments during the project. During this time I will present the progress to them first. This allows me to explain my rationale behind my design decisions, and what I think works and doesn’t work. Then I also explain what my vision is for the next revision and the remainder of the project. And then the client can ask questions and we can discuss changes. If these changes are deviating too much and involve too much work, then I will make a separate estimate for that. Not coming from a graphic design background the concept of ‘client presentation’ was kind of new to me, but I began to realize more and more that data visualization is also very much a design job, and a client presentation can really help having a smoother process (and having fixed revision moments!).
Q4 | As you will fully appreciate, the process of gathering, familiarising with, and preparing data in any visualisation/infographic design task is often a sizeable but somewhat hidden burden – a task that can occupy so much time and effort but is perhaps ultimately invisible to the ultimate viewer. Obviously, pressures during this stage can come in the shape of limited timescales, data that doesn’t quite reveal what you expected and/or substantial data that offers almost too many possibilities. Have you got any stand out pieces of practical advice to share about your practices at this stage?
A4 | I primarily try to solve this in the process itself. Although, you get a better understanding of the data throughout the process, so you can only deal with it to some extent. In my process I first want to do some exploration of the data, even in situations where other people have already done some analysis and know the key insights. I still need to know the structure of the data, the quality, and its potential for a visualization. If insights are not known before the start of the project, then it is important to communicate at the beginning of the project that if you have a certain goal in mind for the projects, or some ideas of tasks a user should be able to do, that after the data exploration phase you may come to the conclusion that the data does not support the goal of the project. The thing is: data is leading in a data visualization project — you cannot make up some data just to comply with your initial ideas. So, you need to have some kind of an open mind and ‘listen to what the data has to say’, and learn what it’s potential is for a visualization. Sometimes this means that a project has to stop if there is too much of a mismatch between the goal of the project and the available data. In other cases this may mean that the goal needs to be adjusted and the project can continue.
Q5 | Whilst there is a great deal of science underpinning the use of colour in data visualisations, a lot that can be achieved through applying common sense. What is the most practical advice you’ve read, heard or have for relative beginners in respect of their application of colour?
A5 | My advice would be to use the HSL color space to come up with colors that match well. There are many tools, online like Kuler from Adobe, but also just a regular desktop color picking tool that offers HSL color picking. The trouble with an RGB color picker is that it is really hard to influence individual components of a color. With HSL you can separately set the Hue, Saturation and Lightness of a color. This is also useful because people distinguish colors primarily based on contrast. So, if you want to make a contrasting color palette, set a few lightness levels but keep the rest the same. Also, if you want some categorical colors, you can leave the lightness the same, and pick some hues that look nice together. But from a visualization point of view, they have more or less the same visual emphasis, which is great if the categories are of equal (semantical) value. A final benefit of using HSL color space is that you can programmatically easily generate colors that would work together. In general, it’s much easier to work with than trying to accomplish the same thing with RGB color pickers.
Q6 | Do you have some advice on what helps you demonstrate such a strong capability to take complex and/or complicated subject matters and make them accessible and interesting to your audience? Linked to this, how do judge the sweet spot of accessibility – not oversimplified or dumbed-down but still understandable to non-specialists?
A6 | A key factor here is the target audience. I make drastically different design decisions if the target audience is the general public who will look at the visualization one time and move on, or if the target audience is a group of experts that will work with the visualization on a daily basis. The general public might need some more introduction, guidance and annotations, whereas the experts know what it is about, and they may not need it at al. In my experience it is therefor an additional challenge if your visualization needs to support both the general public and experts. Usually they have different questions and needs, so that’s very tricky to do in a nice way. I don’t think there is a general rule to find the sweet spot, but I do think it has everything to do with your target audience. I do however try to keep being critical of my own work. I constantly ask myself: can I read this label? Is it too small? Are these elements overlapping to much? Is there enough contrast between these elements? etc. I think a lot of work goes into the tweaking of the visualization: getting the basic concept right is one thing, but to make it look good and work well and make it easy to understand involves a lot of tweaking, being critical (and creative!) and also apply general interaction and design rules. But as an advice: keep questioning your own work, constantly, all the time!