It was quite a contrast with the Tufte experience. Instead of a room of 600, I found a room of 60. This led to a lot more interaction between participants and with the presenter, something I appreciated. One of the biggest differences between Tufte and Few is their purpose in talking about design. Tufte is much more academic and esoteric---design as more form than function, in some ways. But Few, like most of us, recognizes that while it's all well and good to talk about what design should be, at some point, we have to get practical about things. This is his purpose in writing and presenting.
Another contrast between the two gurus is how they view the audience. Tufte's reflects his Ivory Tower existence, with a basic premise that you present the data and the audience decides how they want to evaluate and use it. Interactivity is great, I think, but most of the people I work with are not data literate. And judging from the conversation I had with several others at the Few workshop, their co-workers and audience are no better with data. Few's view of the interaction between designer and audience is that the designer should listen to what the audience needs/wants---and give that to them in a way selected by the designer that is the best format for the data. I find this to be a much more practical approach.
Each morning started with a "pop quiz"---a series of questions about the upcoming ideas for the day. I thought this was a great way to get things going, not just from a management perspective (latecomers didn't interrupt the presentation), but as a teaching strategy. I wish he'd set aside time at the end of the day for everyone to review their answers. Not doing so misses a fabulous opportunity for people to reflect on what they'd learned throughout the day.
Most of the day was a traditional lecture format, with a one-time small group assignment included. I would have liked him to break up the lecture with a few pauses for people to have some partner talk about ideas. There was a lot of material to process along the way. I have no beef that all of the examples were business focused---the workshops were targeted for that walk of life, and I am but a humble educator. But not everyone works with profits and losses. The principles of good data design may apply across the board, but not everyone's roles are the same. If we really want to make changes in the way we use data to communicate, there needs to be opportunity to think about how to apply new learning.
He didn't share anything that you couldn't learn from reading his books, which was my only real disappointment. Not to say that his ideas about data design aren't worth a second (or third) tour through the material, but I believe that presenters should use "live" opportunities to extend their thinking. If we're there, we've probably read the material---help us take the next step.
All that being said, this was a worthwhile opportunity to learn---my quibbles are more about the way things were said than what was said. I would recommend the workshop to anyone interested in the basics of data design. Here are a few of my takeaways:
- I liked that nearly all of his examples were built in Excel. As he pointed out, Excel is not a design tool; however, it is a data tool that nearly everyone has...and if you can make something look good with Excel, then you have no reason not to make your data shine elsewhere.
- For Few, what makes a dashboard unique (vs. other reporting tools), is it's purpose: monitoring. It should allow the audience to scan the big picture, zoom in on specifics, and link to supporting details. He really pushes the idea that there should be no scrolling---the dashboard should fit a single screen---but in a time where you can't guarantee which device will be used to view the data, I don't know that you can make no-scroll a "must." The best you can do is limit it by being thoughtful about what you present.
- Details matter. I think this is the one piece that is most misunderstood by most people. The colors you choose, the lines you use, the way your organize content should be just as agonized over as the data quality going in and the questions you draw out. Typically, this piece is tossed aside. If it wasn't, there would be so many crappy visualizations out there.
Hadn't seen this clip from The Onion before...but it was the very first thing shared at the workshop. Thought you might enjoy it, too.