Workflow (in Exquisite Detail)

Awhile back, a buddy of mine encouraged me to write a post about workflow. I appreciate workflow and I take it very seriously. With as much stuff as we having going on around here at any given time, if I didn’t, I would be overwhelmed, and the fun, creative aspects of design and development would drown under the weight of chaos. Here’s the thing though. I’ve been incredibly busy working on tremulus. As I tidied up the last bits of the assets I needed to get off to Justin for incorporation into the second part of the Kickstarter video, I admit I’ve been coasting a bit today. Not slacking off completely, but as I haven’t had a day off in months, I admit I have been a bit casual today. When I get casual, I sometimes spend a bit more time on Twitter than my usual water cooler moments. Things are tying together and I’m getting to the workflow bit, but I’m building up to what prompted this post today. I was outed about writing this. Here’s the story. I mentioned we were storyboarding the second part of the tremulus video using SNC. Well, the friend in question, namely one John Rogers, asked what it was. It’s Mindola’s supernotecard. I just call it SNC because I’m a bit of a geek and that’s the file extension. So, question answered. However, he went on to slide into his tweet “You still owe the workflow blogpost.”

I mumbled a few humorous words, and thought, “My charade has been revealed. Now I must actually write this.” I mulled it over, and thought I might continue to goof off a bit more of the afternoon when he follows up with this…”People, you have no idea. The @RealityBlurs RPG development cycle is structured like a software cycle. As a process geek I’m awestruck.” Okay, now he’s appealing to my vanity.” I get it, John, I’ll write this. I’ll share my thoughts on all of this stuff with an uncaring world. And who’s going to read this? Most folks are off at Gen Con getting their game on. And good for them. Here’s the secret to why I haven’t formalized these words and shared them with you: workflow doesn’t sound particularly sexy. I use that word regularly in my discussions about products and pitches and all those sorts of things. We want our works to have some pop to them. They need to have a bit of sexiness. A right cross and some sexiness can get you a long way. Let me see if I can give you the lowdown on workflow, and see if I can present it in a somewhat sexy way for those who, like John and, admittedly, myself, are into process.

First some background information: You can skip this if you don’t wish to contextualize this  journey. That’s cool. You’re just cold, heartless, and likely a robot. On the plus side, it means you’re likely to already be programmed for workflow. Go bend things. Still here? We’ll keep this short. When the company first began, it was just me and the mouse in my pocket (or by my keyboard). I’ve always presented the company as a we because it sounds more stable and solid. I come from a family of entrepreneurs, and always thought it would not be my thing, and did the corporate thing for quite some time. I’ve done collections, been a loan officer, managed a loan company, worked for attorneys, done freelance graphic design, have had long titles which translated into “the chief tech guy”, worked at a web design house, and worked for International Paper as one of its first (only official) webmonkeys, and have worked with EDI (Electronic Data Interchange) for monolithic mainframe systems. I’ve written code in one form or another since my youth, but I learned a lot about process working in technical fields. Wanting to free myself from the corporate shackles, I let my hair grow long, disregarded all this good information I had acquired, and decided to keep up with everything in my head, scribbled on notebooks, and handled affairs in a largely bohemian manner. As the company grew, I couldn’t do that anymore. I was expending more energy trying to keep track of things than creating things and things would grind to a near halt. I had to get right with things or find another day gig. I got a haircut and buckled down. I began to use spreadsheets and Dropbox. I kept track of things, and things got done.

During this time, a longtime friend of mine, Frank Davis, reached out to me to catch up. He is a successful business guy (and a gamer to boot) and he lauded my modest successes while I lamented about having difficulty keeping track of things. He turned me on to Getting Things Done and another book I can’t recall the name of (it was a good book, I recall vaguely mice and email in/on the cover). This stuff made sense. I decided to formalize things and came to an inner understanding that corporate processes and other information I’ve accrued up to this point could only serve to better the company’s continued success and growth. Here is where the tale of workflow begins in earnest. I’ll strip out the personal bits forward and focus on what makes the wheels turn smoothly.

The Workflow

At its base level, words are merely discrete bits of data. Little blocks of information your internal compiler (your brain) turns into thoughts and images. In this regard, we can learn a lot from information technology practices.

1. Brainstorm. Come up with the product idea. What it is, doesn’t matter. Whether it’s a KS video or a new RPG game or supplement. Think your thoughts.

2. Create a rough draft. Write the necessary words. Make a storyboard. It doesn’t have to be perfect. In fact, it shouldn’t be. If it is, you’re taking way too long. Everything is an iterative process.

We’re going to focus on taking an idea from conceptualization to completion. Examples will focus on RPG stuff, since that’s largely all we’ve done to date. Keep in mind, however, the song remains the same.

3. Get it to the team. We’ll get into the specifics of how to do that later. Essentially, you want other hands (and eyes and minds) on your stuff. Nothing is sacred. If it’s a document, expect that steak to come back bloody and rare and still warm.

4.  Refine. You fix all the bits that were wrong and ship that back to the team. You repeat this until the document is polished up to your exacting specifications. Nothing is perfect, but there comes a point of diminishing returns. We’ll explore that more in a bit as well.

Essentially, that sums up workflow, but I doubt you, or John for that matter, would be particularly satisfied with that answer. If you’re technically minded, I’ll drill down into some more specifics of how we do some of these particular parts. Perhaps some of these thoughts/concepts will work for you.

Brainstorming is something which can be done either in isolation or in a group. I tend to work on that aspect of things all by my lonesome. It’s just the way I’ve always operated. I encourage my crew to do that as well. While you may think brainstorms are safe zones, everyone still holds back. Yes, I know there may well be exceptions, and teams which work together a long time may counter this, but I’m going with my gut on this one. Ideas are sometimes like dull swords that are sharpened once they make contact with contrary ideas. Writers (and most creatives) are largely solitary folks who are best left alone. I will undercut my own argument (maybe). If a team is told a brainstorming session is coming up and to work on ideas and bring them to the table to discuss, then they are more successful (and could, actually, support my argument). Noodle on that.

To get a bit more technical, I largely use Mindola’s supernotecard to do brainstorming. I’ve had it for years and it is simple and works well. There are other programs I’ve worked with that have a lot more horsepower and bells and whistles. In all likelihood, you won’t ever use or need those bells and whistles. They are a distraction. Eliminate distractions to optimize your output. This program lets you make note cards, plain and simple, and you can create decks, and sub-decks, and structure information in a hierarchical fashion. Out of the box, it’s not that sexy. If you want to get the most use out of it, you split the display, and adjust the view where you have the file structure (decks) displayed on the right side of the screen so you can easily drill down to anything at any given time. This power and flexibility has enabled me to draft adventures in just a few days and is one of my most valued tools. It’s free and isn’t crippled. It’s so good, though, I bought the license, and encourage you to check it out. That being said, I’ve found Microsoft Office 2010 to have some useful tools in the Navigation panel. This requires you to format your document as you go, so if you just want to focus on the words, stick with supernotecard. It’s good stuff. I’ve written many actual products using this program. When I’m done with the rough cut, I export it as an RTF file and give it another pass in Word (or pass it on to the crew, if I’m particularly busy or lazy at any given time).

You need to label this document, so you can keep track of its growth. From working so long in the technical arenas and being intimately familiar with CMS (change management systems), I use a versioning system. I’ve done this about as long as I started coding. (Well, technically, after the first time I overwrote a good file with a bad file by using the same name. This was in the days before computers were nice enough to ask you if you were sure you wanted to overwrite something.) This sticks with me. To that end, you want to have a clear name. Nothing cutesy. For example, with tremulus, it’s called simply tremulus_v1.0 or whatever. And here’s where we get into the particulars of what’s going on there and this is going to tie into the next portion of our discussion where we talk about our project management software, Basecamp. Just think of it as a private piece of cloud computing wherein you can store all your assets for any given project (because that’s what it is). Anyway, the guys know NOT to change the version number. Some of them did that at first, so you have to educate your crew. That’s confusing. When a reader or editor is assigned to look at a file, like tremulus_v1.0, they review it, make their annotations, and return it with their initials appended on the end. For example, tremulus_v1.0_TC_review. I don’t care if they put extra stuff at the end. As long as they put their initials and preserve the integrity of the version, we’re good with it. At a glance, we can discretely compare iterations at a glance and we can easily do a compare/contrast should it become necessary. However, and I do stress this heavily, we do require anyone who touches a document after the rough draft is created to track changes, and it then gets kicked back to either the writer or up the editorial food chain. This goes for the original writer as well. They can accept/deny changes, but any new words they scribble, they track. Why? Because it allows additional eyes to easily appraise these hot spots and determine if they are good or evil. This should not be overlooked. Let’s follow this thread on out. Once the document gets finalized, it then moves on to layout (and this is often concurrent with art direction which is beyond the scope of this discussion) and then kicked back for more eyes. Again, there is a version number of the laid out version (typically a PDF) and it should be very solid at this point. You don’t want to have to make a lot of changes on a PDF. Sometimes, it happens. And never gripe about your team catching errors. Better them than the general public.

Now, about versioning. Your versioning system may vary, but here’s what works for me. I use incremental versions for small changes. For example, if someone makes minor corrections (or I add just a tad to something), I’ll kick it up by a .1. So if I added a paragraph on sanity into an otherwise robust document, I’d kick it up to tremulus_v1.1. As the originator and hub of the company, I’m the one who generally makes these changes, though my e-i-c has that discretionary power as well. Make sure you trust your team to abide by this. Since we’ve been doing this for years, they know we only jump version numbers for major overhauls or when I’m tipping my hand to say, numerically, we’re at a stopping point. For example, tremulus_v4.0 is about to get thrown back up into Basecamp as I’ve made a number of incremental changes. And the changes are not done just for them. Even alone, I’d be doing this. I do it on iterations they may not even see (especially if I’m uncertain I like the rewrites I’m doing on large swathes of text). It’s easier for me to go back to a previous version (like I did yesterday with v3.8 and v3.9) and save it over the new version then it is to undo (if I’m tracking changes) or hunt down (if I’m not). This, too, will save you immense grief in the long run. That’s my versioning system in a nutshell. If you want more detail, just ask.

Finally, we’ll touch on Basecamp just a moment. Basecamp has been written by me quite extensively, but, in the spirit of comprehensiveness, I’ll talk about it again now. Basecamp is a cloud-based project management system. You can access it from any computer at any time with your log in. It is not free. It is, however, worth every penny spent on it. It allows for an intranet of sorts without establishing one of your own. You can set up discussions and route conversations and everything through it. You can tie said conversations down to the finite level of a comment thread on a specific to do item. This level of granularity means you do not have to set up elaborate filters in your email or try to search through all your emails to find something. We set up all our projects separately (such as tremulus and Agents of Oblivion) and we can grant or deny access to whomever easily. We can upload art assets and all other file types with great ease. We’re also using it for our tremulus playtest. I set up a group explicitly for the playtesters where they can discuss things in a closed environment, we can track likes/dislikes, and it’s easy to get new versions of playtests to them without fiddling with some of the alternative, free solutions which can eat up time and may not have such a solid company like 37signals behind them.

There you go. If you like the demystification of process, you may well have found this sexy, if you don’t, I hope you found it entertaining on some level. Regardless, I’m certain you’ll have a deeper appreciation of what goes on behind the scenes.

Until next time, I bid you, dear reader, adieu!