January 11, 2008
I just opted in to our design documentation standard, to do the right thing. I mean, we always do the right thing, but we’ve not really defined the ‘right thing’ very well up to this point. However, we’re just getting our design process rationalized across the team, including the technology we use to interface with other teams, vendors, agencies etc. We’ve always had the super web design component standards out there, which I’m sure you’ve all seen, but internally, well, it probably isn’t a surprise to anybody out there who is part of a reasonably sized design team to know that there’s always been a number of different ways in which we initiate, manage and deliver our design projects
Not any more. No sirree. The few good people here that have been tasked with coordinating our activities are just starting to cement some of the pieces in place. These are not new ideas. We’ve talked about the need to do this for about 10 years, and in that time, the size of the organization has grown many times its original small, lithe, sexy size. Now, more than ever, we need to be able to track and tune projects on a predictable path, to set expectations, engage the multiple teams you need to engage with these days, and even just understand what the project we’re currently working on actually is (surprising how often you stop in the middle and realize you have no idea what it is you’re supposed to be delivering. That’s not just me is it?. Oops.).
Which brings me to documentation. I’ve always been the kind of rapid prototyping kind of person. If you want to see what the web pages will look like, I’ll write them, and then you can tell me what you think. Context, you see. So what if it takes a bit of work to do the initial set up and a few frantic nights of html hacking to make it look like it will fit seamlessly into the Solutions section, when you know really that it won’t actually look like that because that section is actually implemented on a hack of a content management platform and none of those components will really sit together like that? At least you see it in context. Trouble is, you can’t, as I often found, take that development site to the publishing and engineering teams and just say “I want that one”. They want to know things like “what happens when I click this”, “how many of those can you have”, “has this been reviewed?”. How unreasonable. Its just a mockup, its not supposed to actually work, you know.
Which is where the new documentation standards come in. Some sickeningly efficient folks in our team have been doing this kind of thing the right way for years. You know, they’re the ones who have actually qualified somehow to be a designer. People like me, however, just have never had a clue. So, how serendipitous it is that Creative Suite 3 finally gets delivered to me (after protracted supplier delays), and I get my hands on InDesign, for that is the tool of choice. Our friends at Eight Shapes did a grand job, a while back, of working on a design documentation framework that supports our component set and incorporates “mapping & annotation standards, artifact modularization, and tricks of the trade learned over years of experience” (their words, but they’re the right words). What this means in practice, is that I can now develop fully annotated design specifications, with consistent wireframes, nomenclature, and interaction definitions, which are understood by clients, designers, publishers and engineers alike. This is nothing short of a revelation to me. I mean, it doesn’t actually do the designing for me, so I can still get that hopelessly wrong, but its a huge change for the better on the project and process management front, and its a self-documenting exercise. I also get to learn a new application, which is nice. Oh, and, of course, I get new friends on Facebook, so I now know what Nathan’s Star Wars character is, which is always useful.
Listening Post: White Stripes: Bone Broke
