Perhaps the most common mistake I see with website redesigns is jumping in at the deep end — going straight to design or code. My theory about why this happens so frequently is that it’s very human. We love to create. Specifically we love to create things — be it gardens, machines, books, art, homemade bread or websites. So the reason we give site planning short shrift is that it doesn’t seem to create much — at least not much that’s tangible or lends itself to sharing with others.

So this week we’re going to be looking at two of my favorite redesign planning “deliverables” — things you can not only share, but also help the planning process in a big way.

1. A Redesign Blog

This is optional, but it’s such fun and so easy to share that I’d strongly encourage you to give it a whirl. Some of the reasons you might want to take this extra step are:

• Transparency
• Another way to get feedback
• A central place to store planning documentation
• An easy way to try out new technologies and see how you like them
• A way to give periodic updates to leadership and staff

I recently set up a blog for our redesign, and have already gotten good feedback on it — particularly from our Communications Committee representative to the Board. It gave her something to show at the most recent Board meeting.

For blog software, I chose WordPress.com. I’m steeped in WordPress.org, which is not exactly the same, and I wanted to learn first-hand what’s different. (An aside: I’ve been surprised at how many differences there are.) I also chose a theme with a simple and neutral look — to keep focus on the redesign, not the blog.

2. A Redesign Roadmap

I learned about “redesign roadmaps” 10 years ago in the first edition of Kelly Goto and Emily Cutler’s excellent book Web ReDesign: Workflow that Works and have been using them ever since. They fall somewhere between to-do lists and full-blown project management software like Microsoft Project.

Until now, I’ve always done them in Excel. But for this redesign, I’ve experimented with a Google Docs spreadsheet. So far, I don’t like it as much as Excel, but that’s probably mostly because I’m not as familiar with it. Goodness knows the price is right.

Just pick some software that works for you and is good for list-making. If you have any particular favorites, I’d love to hear. There are tons of list-making apps, but I’ve never gotten serious about any.

Start small. You don’t have to itemize everything right away. In fact you can’t at this stage. The list will grow in time, especially over the next few weeks.

Here’s what my current roadmap looks like thus far. And here’s what my roadmap for our previous redesign ended up looking like.

One tip: when things pop into your mind that you might otherwise forget, be sure to capture them here. Don’t worry if they’re minor. My lists typically end up full of tiny details for just after launch — things I can’t do before then (for example checking to be sure the 404 page is working correctly).

Also you don’t have to slavishly follow the list in the order it’s written. As a general rule you’ll go sequentially, especially for what project managers call “dependencies,” i.e. a series of steps that necessarily follow one another. But as soon as you have a team in place, you’ll want to do some things concurrently. For example, you can’t edit content before you gather it, but your developer can be coding while your editor is editing.

In a way it’s all rather obvious, but the beauty of the roadmap is it’s plotted out so you can see patterns — and it’s tangible. You don’t have to clog your brain up with remembering these items, you have something to show leadership, and at any given time you can look to see what team members might work on next.

Speaking of the team, next week we’ll be working on that very thing — lining up people with the right skills to get the different jobs done. Until then, have fun creating your own deliverables.