Back in early December I gave a talk at WordCamp US about a website I built with Tracy. The talk was titled “Lesbians, Damn Lesbians, and Statistics.” You can watch it here:
Of all the talks I’ve given, I feel it was the least WordPressy of them all. That is, while I did talk about WordPress and why we made choices that we did, and how they relate to the data design, it wasn’t very code heavy. It was, instead, a case study in how and why and what.
A case study talk is complicated because you have to address what the topic is beyond WordPress. When you start with WordPress, and you’re at a WordPress convention, you don’t have to lay the groundwork. You can jump in and talk about custom post types and taxonomies. At a WordCamp, everyone knows about WordPress, or at least enough to skip over the basics.
On the other hand, your case study starts by explaining what the reason was that you built the site in the first place. What’s the purpose of the site and what’s the relation to WordPress. You start with the narrative of “This is my story.” And you have to do it fast because next is the why!
Once you have explained what the site is about, you have to explain why WordPress. When you’re doing a normal talk about WordPress things, you skip right over this. Everyone knows why WordPress. Because WordPress! But many times we ask ourselves “Is WordPress the best tool for this job?” We ask “Is it the right tool?” So in a case study, you have to build up your case and explain why.
This is hard, because you already jumped through those hoops to explain to yourself (and any business partners you’re working with) the rationale. Distilling all of that into a third of your talk, which means maybe ten minutes, is not easy. You summarize, you skip over things, and you still have to hit the main points or people won’t be able to make the connections for the next section.
Finally you have to explain how you did this. If people don’t understand what you did and why, the how becomes meaningless. This is because the brunt of your talk takes place here. This is the real WordPressy stuff, where you talk about how the what and why came together to be this thing. If people can understand the enormity of the data, they can conceptualize your logic.
If you’ve built everything up before, people will understand “Oh, she couldn’t make death a taxonomy because the overlap would cause problems and become unwieldy.” They’ll follow you when you explain about faceting searches and moving data.
The purpose of all this is to draw people in with a cohesive story that puts the code and the concept together. People remember songs because of the rhythm and pattern. They will remember your case study because of the story. We remember stories.
The purpose of your case study is to tell a good story that people remember and that connects them to your topic and your code.