Working with developers and designers

I wrote a post for IdeaLab earlier today.  It’s a short update on ReportingOn development, framed as a weighing of the pros and cons of a few different development platforms.

It occurred to me near the end of it that I should treat this project as if the developer was someone other than myself.  (Yes, at some point in the next year, I’m planning on hiring out some design work on the site, and possibly some development for a specific purpose or two, but not right away.)

So here are five tips for working with Web developers and designers:

1. Content is king:  Your new hire or freelance pal can’t magically build a site out of nothing.  You need to know exactly what type of content lives on your site.  That doesn’t mean you need to write a bunch of fake entries or create phantom profiles, although that couldn’t hurt.  It means you need to know what belongs in each space on the front page, and where the links on that page lead.  Please don’t tell a designer what you want “it” to look like if you haven’t talked about what “it” is.  This happens all the time.
2. Start with a pencil:  That’s right, it’s time to whip out ye olde dead tree times two — paper and pencil.  Personally, I prefer swiping a sheet of 11×17 from the nearest printer.  Lots of room for notes at that scale, plus, you’re going to want to draw all sorts of crazy arrows and add captions and numbers and diagrams and… maybe that’s just me.  But either way, this is your first prototype: Paper and pencil.  Pen if you prefer to live dangerously.
3. Prototype in HTML if you can:  If you know enough HTML (and preferably, CSS) to build a little dummy page with links that go nowhere, by all means, do it.  Not only will this exercise help you build out a map of your site, showing you and your developer friends what needs to be a link and where it might lead, but if you’re good with HTML and CSS, these dummy pages might even become templates you can plug dynamic code into later.
4. See more than one option:  Once you’re relatively settled on branding and a rough color scheme (stick with words for colors at this stage, not hex codes), you’ll want to see multiple iterations of the design.  Consider these rough drafts, not final products to accept or reject.  Now is the time to finalize that color scheme, make some decisions about where to place those blocks of content, and eliminate any features that feel superfluous.
5. Don’t pixel-push:  Seriously, do you really think it’s going to matter in the end whether or not there’s just a little bit more whitespace around that heading?  It’s not going to matter to your users.  If precise design and perfect typography is your thing, hire someone who is an expert at putting those elements in just the right spot.  It’s nice if you can get it all looking just the way you pictured it in your head, but you should really just hire people you can trust, and then trust them.  Chances are, they have built more of these than you have, and their judgment (and experience) is there for a reason.

And a bonus tip: Pay attention to the dominant trends in Web development and design.  If you’re involved at all in the building of Web sites these days, you should at least be taking a cursory glance at A List Apart, 37signals, and the work of Khoi Vinh, Dan Cederholm, and everyone you see in the blogrolls or posts on all these sites.

The goal here isn’t to throw around buzzwords; it’s to better understand the real words your developers and designers are using.  Don’t say “AJAX!!!” without reading about it first, for example.  You’ll have a better time talking with the construction crew if you have some level of familiarity with the materials.

Your tips for working with humans who work with code?

In the comments…