Infosearch Media Inc (ISHM)

[rattlewatch]

How long does a website redesign take?

(Here's a good article/blog ,ISHM website went down Mid November which means we're in the window.)

by Kim Bieler · March 03, 2010

The most common issue that comes up when companies come to us for a website redesign is schedule—the site needs to be live in four or five weeks, but we believe it will take twice that time (or longer). Why so long? I hope this article will answer that question.

Risks in the fast turnaround site
First of all, of course it's possible to get a website designed and launched in four weeks. But here's what can happen with these truncated projects:

Without identifying the website goals and requirements, any new design is only a guess at what might work. And that's not effective design, it's decoration. Which may, in fact, be the problem with your current site.
Decisions at the client side are rushed, which can result in cutting corners, settling for inferior solutions, dissatisfaction with the final product, and—in the worst cases—having to put the brakes on and start over.
Quick turnaround websites aren't over when they're over. Often, the launched site suffers from "coming soon" pages, proofreading errors, poor browser compatibility, and buggy interactions. To make tight deadlines developers may need to write non-compliant code that has to be fixed later.
So what do you get with a longer timeline? In a word: confidence.

There's a common misconception that designers sit around waiting for inspiration to strike. Nothing could be further from the truth. Because we can't rely on the genius moment, we have evolved a process that starts from knowns like research and goals and works through multiple concepts, testing, and refinement until we have a solution that best fits the problem. It's a process, just like any other, that's designed to mitigate risk, build consensus, and verify solutions.

Design process, phase 1: Discovery
Many firms, ours included, start with a discovery or definition phase where we figure out what kind of website we are designing and why. We need to know what technologies you currently use, what the constraints of the project are, where the content and images are going to come from, how much material will be recycled from the current site, and so on. We'll want to contact your hosting company to get passwords, logins, and server configurations. All this information-gathering will require documentation, some of which we will ask you to review and approve.

Discovery is the most important phase of the process but it's the one we are most often asked to cut corners on. It's natural to be impatient to get to the "fun" design phase. But it's not at all fun to be a week away from launch only to find out your server can't run the software, or you don't have any head shots for the profile pages, or you need a Spanish translation of the entire site.

On the client side, discovery is when we'll be asking you to imagine how the final site should look and behave. Your familiarity with the site and subject matter will be needed to compile an inventory of existing site content and decide what to keep, what's missing and who's going to be responsible for writing new content. We'll be making fundamental decisions about technology, approach, and objectives which can mean getting approvals from senior management.

Design process, phase 2: Design
In the design phase, we review all the documents we've generated so far—this might include a strategic brief, competitive analysis, user research, search logs, site surveys, or use cases, and any branding documents, style guides, and corporate communications. We switch gears from an analytical mode to a synthetic one—distilling the information we've learned and creating several design looks for you to respond to. Normally, we go through two or three rounds of iterations on the design, to hone in on the best solution.

Design decisions are often emotional ones—you may need to give your team time to get used to the new look and functionality of the site before they are comfortable approving it. Every design has tradeoffs which must be weighed and discussed.

The approved design look informs all the other pages of the site. At this stage, there are often transactional interactions and states that still need to be worked out and one-off pages with elements that need special design. Part of our work during this phase is generating the documents (style guides, annotated wireframes, requirements) that the developers will use to implement the site design.

Design process, phase 3. Development, testing, and launch
Developers need uninterrupted "heads-down" time to code the page designs and back-end functionality of the site. During this phase the design and client teams can relax somewhat, although inevitably issues arise—missing graphic elements, implementation decisions that must be resolved, unexpected software issues. If there are weaknesses or bugs in the system, we want to uncover them now, not when the site is public.

Prior to launch everyone needs to carefully review the site and flag any problems. On the client side, you should be finalizing any launch activities—press releases, announcements, staff training. If the redesign is large and complex, launch day can be an anxious one as first-time visitors begin to use the site. Even a perfect launch will have follow-up activities such as releasing style guides to in-house developers, training staff on how to make updates, and fixing any outstanding design or functionality issues.

What this means for you
How long does this process take? Anywhere from 7–9 weeks for an average-sized "brochure" site up to 6–9 months for a complex transactional or large, membership-based site.

I should make clear that this doesn't mean a brochure site will take 8 weeks of 8-hour days. A realistic schedule allows breathing room for absorbing information, considering solutions, decision-making, and other cognitive processes that benefit from subconscious as well as focused reflection.

Web redesign schedules are often handed down by management who are simply sick and tired of the existing site and want to see action. Schedules are then duly passed on to the designers who either push back or promise things we know can't be delivered. My hope is that by understanding the value of the design process, web teams can avoid the schedule debate by assuring management the project is on a safe, reliable trajectory that will result in a product everyone is happy with.

http://www.aptmediainc.com/apt-lab-blog/26-how-long-does-a-website-redesign-take.html