Lessons learned from a website redesign

I’ve handled many website redesigns over the course of my career in the interactive and no matter whether you’re working on a small website, microsite, landing page, or mega-site employing the latest and greatest technology known to man for managing how to update a single piece of content, you’re always going to take something away from it. Each case is entirely different but it’s very helpful to reflect back a few days after you’ve successfully launched the site and analyze what you’ve done right and what you may want to change in the next episode. Here’s some tips from my own experience on things to do better.

Document everything. It doesn’t matter if you’re in a meeting, on the phone, or if it’s digital, make sure that you document everything so the team is all on the same page. Scope creep can occur at anytime and you don’t want to be caught with your proverbial “pants down” because you didn’t remember that at the October meeting, the client asked if you would add this one thing and you said yes, but then forgot to tell your development team and now they’re saying it can’t be done without additional time.

There’s no need to reinvent the wheel. There’s nothing wrong with simply using a third-party vendor unless there’s an absolute need to create something from scratch. Often times that will help cut down on costs and these days you should be able to import/export feeds and then brand whatever page you want.

Gather together your assets and resources BEFORE you begin work. Once you’ve put together your requirements on what the scope of work is, make sure you have your team in place. You’ll soon know whether you need to have a front-end developer, flash developer, QA tester, copywriter, etc in place before any project gets done.

Also, don’t neglect getting assets. If your client has a specific brand guideline or templates that they’re currently using…get them! Don’t forget about any print collateral that may exist. Anything and everything is useful to help the team get started. Are there any web analytics that they can share with you? What about best practices that the team may benefit from? Leave nothing out.

The RFP may say they want their site to make coffee, but really they don’t. Typically the client has listed out in their Request for Proposals all the nice ideas that they’d like to make. I would take each requirement seriously but still keep in mind that they’re not looking for a “yes man”. They want someone who will offer their services to create what they want, BUT at the same time, they’re looking for industry professionals to help guide them and create something awesome and lasting. So put in a good effort in the proposal and try to address what you think you can offer. Just don’t be unreasonable or unimaginative.

When in doubt, test EVERYTHING. You have been contracted to create something for a client. Don’t assume that what your creative, technical, or other production team is perfect. Honestly it’s better to test everything. Have multiple sets of eyes looking at everything from browser-compatibility, proofreading and spell-checking, checking to see if it’s possible to break anything, etc. While the client may be pressuring you to go ahead and show something, it’s better to do things once rather than going back to the site and making never-ending changes because you forgot to fix it.

Don’t be an expert when you’re not. If you’re talking to the client and they ask a technical question, unless you’re doing the work yourself or are managing that team, don’t answer in a definite response. What that means is unless you’re 100% proficient in talking about SQL servers, .NET framework, LAMP architecture, Content Management Systems, API, MySQL, etc., then you should have a technical liasion in the room with you. If you don’t have one handy, I would recommend telling the client that you should get a definitive response later after consulting with your talent. Better to get an answer later rather than wiping egg off your face when you have to go back and recant what you told them.

There’s nothing wrong with a phased approach. Don’t try and cram everything within a specific timeframe unless it’s absolutely necessary. And if you do, you better have one helluva dedicated team! There’s nothing wrong with going back and implementing a phased approach (with the client’s blessing, obviously). Site work takes time and regardless of what you think, there are many steps in getting something launched and perfect. Don’t think that creative execution can take a couple of days. Depending on the complexity of the design, you might be looking at multiple days. And don’t forget that you have other projects to possibly worry about as well!

Setting unreasonable deadlines that you’re not comfortable with isn’t a good thing. Look at a project plan and scope everything out carefully. Examine each step and budget appropriately how you can make the client happy but protect your team and integrity at the same time.

Scalability is key. Your relationship with your client doesn’t end with the website. There is maintenance and other needs that they might want so you should build the site to scale. Don’t simply create some back-end system that will need to be overhauled in a few years because you didn’t account for it to have an RSS feed. This goes back to prudent planning in the early stages. Sites need to grow so don’t hinder them from doing this.

Have you forgot about hosting? Don’t neglect talking to the hosting provider. Make a clear distinction on what you’re doing and what the hosting provider will do to maintain the servers. The client needs to be clear so they’re going to contact the right person should the site go down. Talk to the hosting provider early in the project to make sure that they support the right environment. Yes, in your proposal you suggested using ColdFusion, but if the server doesn’t support ColdFusion, will the client need to pay to upgrade the server to have your solution? Why not have a “Plan B” and see if you can’t offer your solution in a way to accommodate the server? If that doesn’t work, better have another solution on deck…quick!

These are just a few lessons that I’ve learned from my times managing site redesigns. I’m sure there are more lessons that you may have learned and would love to hear them. Please feel free to share them in the comments below.