That is the tempo.
Are you old enough to know that the title of this post is a Beastie Boys lyric? (Are you old enough to know who the Beastie Boys are?) Of all the tracks from their multiplatinum, 13-song "Licensed to Ill" album, "Slow and Low" is...one of the least popular.
Based on Spotify track plays, “Slow and Low” ranks 10th. From most to least: Fight For Your Right (to Party); No Sleep Til Brooklyn; Brass Monkey; Girls; Paul Revere; Rhymin & Stealin; She's Crafty; The New Style; Hold It Now, Hit It; Slow and Low; Slow Ride; Time to Get Ill; and Posse In Effect.
The lyrics are, admittedly, not great--"We got determination - bass and highs / White Castle fries only come in one size"--but at least they aren't as sexist or homophobic as the rest of the album was. (Google can tell you what the original title of the album was, if you need a truly cringeworthy example.)
But "Slow and Low" isn't just a subpar song from a problematic hit record from the 80s. It's also my preferred approach to creating a data visualization.
Joshua Milligan recently used his personal lessons learned from his time on the Iron Viz stage to write an extremely useful primer on speeding up your design process. You should read "The Need for Speed" on his vizpainter blog, as I'm sure you will find it useful and enlightening.
Few people have had such a public need for such dramatic dataviz design speed as Joshua, so he knows of which he speaks. If speed be what ye seek, I encourage you to take the advice of just such a Zen at the height of his considerable powers.
However, speed be not what I seek.
For me, speed happens on its own: it happens:
when I get into a state of flow;
or when I have pre-planned a series of actions that I am methodically working through instead of spiraling off in multiple directions;
or when I get a burst of energy from seeing the overall piece starting to take shape.
I have learned that in trying to go fast, I make mistakes. I cut corners. I miss pieces of every element I consider essential to creating something I'm satisfied with publishing in public.
By this, I mean the elements of:
research (figuring out the context of the data as provided, and asking questions about what other data would help to support the project)
data gathering (Google-fu)
data cleanup and shaping (if I had Alteryx or any Python skill at all, this would probably be faster)
analysis (charts on charts on charts, most of which get thrown away; lots of [Calculation1], [Calculation2] ... [Calculation647]...)
wireframing (layout, aesthetics, interactions)
rendering (actually building the damn things)
detailing (this includes Tooltips and final formatting)
publishing/promoting (yes, I think about how I'll phrase things in a tweet, how I'll label them on Tableau Public, if I'm going to blog about them, if I'm going to put them somewhere besides Twitter...)
"Dudebro," you might say (if you were the sort of person I don't want to know), "why are you doing all that for every little thing you make?
Not everything has to be perfect."
Well, true. Not everything has to be perfect, and nothing ever will be. But I know how to asymptotically approach my idea of perfect, and it is not by actively speeding myself up.
I know that the irritation I feel from putting something out live, and then finding an error in it (or, worse: having an error pointed out to me by someone else), is infinitely more bothersome than the pleasure I take in finishing something quickly.
And, not for nothing, but I'm picky about what I want to put my name on.
Consider that things we put on Public are 100% under our control. We don't have a client pushing us to meet a (possibly fabricated) deadline, or a stack of other deliverables that require us to do an 80% job in order to keep from falling behind. We can take as much time as we want, spend more hours if we want, or even not deliver at all, if we don't feel happy with the direction things are going.
I like having the freedom to be able to scrap an idea and start over anew without getting buy-in from Sales, Marketing, and IT. I can kill my gloriously creative ideas when they *just quite* don't work the way I want them to.
Or, put another way, I'm only responsible to me, and to people who I envision would be the audience; and doing right by those two...ugh..."stakeholders" means taking my time.
Simmering.
Cooking things up slow and low.
This week's Myers-Briggs Makeover? I thought it would take me no more than an hour. I got into it and realized that my initial assumptions were wrong, and that I'd need to come up with some new ideas.
I had several directions to go in, all of which required (a) manual data collection, (b) laborious research, (c) post-facto data shaping, and (d) for me to triage some of them at some point because I wasn't going to do all of them.
Eventually, as some of you have seen, I DID split the difference and ended up taking two completely different approaches, binding them together in the design through how diametrically opposed they are.
But this took, with both active and passive effort, the better part of two days, which includes probably 6-8 hours of actual fingers-on-keyboard time.
Is it worth it, to take this much time on every single thing?
Let me put it this way. When I look back at all the things I've made in the past I don't see the tally of hours it took to make them. I see the final products. If I still like them months and years later, then yes, it was worth it. And I don't often feel that way about things I did quickly.
The conspiracy theorists among you might say that, based on what I've revealed here, I probably sabotaged myself at #data17 and got myself ohhhh, nooooo, locked out of the live Makeover Monday session, darn, what a bummer. You might say that I didn't WANT to do a time-boxed session since the stuff I put out takes WAY longer than an hour to do.
To you people I say: the real reason I didn't make it to that session is because the waiter didn't bring @bfongdata her guacamole dip soon enough, so we got stuck at lunch for too long. Don't blame me: blame the waitstaff. I guess they were playing it slow and low themselves.
The moral of the story: there’s certainly nothing wrong with trying to increase your speed. But neither is there anything wrong with taking your time, letting your masterpieces slow cook, under low heat, until the designs are tender and delicious. It’s your prerogative, as the data chef, to do whatever you feel is necessary, for however long it takes, in order to produce the exact dish you want to serve.
If there are typos in this, I apologize. I wrote it quickly.