How to Plan a Business Website Redesign

Modern websites in big organisations are important pieces of business processes. Redesigning or rebuilding them is usually a complex project which has to be meticulously planned to be done right. It often comes as a surprise even to the companies themselves just how important the website is and how many things have to be taken into account. I want to offer a summary of how to go about preparing and planning your website redesign. A checklist if you like.

The blow steps are listed in a logical order. They will however not be always happening one after another. Some parallelism will happen. Elements of the plan will require re-visiting and some level of iteration is also inevitable.

1. Identify all stakeholders

This will be the first step in a website redesign planning process. A corporate website does many things to various users. It is not just the sales or marketing that are interested in what you are doing. You have to make sure that all important interests are accounted for.

Identifying all stakeholders will ensure that you:

• do not miss any important aspects the website should take into account
• manage expectations of all interested parties

We wrote a completely separate blog post listing potential stakeholders in a website redesign process. You can head there to better understand the types of stakeholders and their potential impact on your project.

2. Identify what you have

Before planning the new website, you should do a full analysis of the current one. It is tempting to skip this part in an “out with the old, in with the new” approach, but the consequences may be dire. 

The main objective of an audit of the current website is to identify all the data and functions which have to be preserved. In particular, these will be:

• Content audit - what content do you currently have on the website and why
  • Which content drives traffic?
  • Which content is a regulatory requirement?
  • Which content do users currently visit and look for and why?
  • Do you want to keep it, discard it, change it? 
• Traffic - how do users use your website and where do they come from:
  • What URLs do you have that get traffic? What will be the plan for each of them?
  • Do you need to preserve them to keep the SEO intact?
  • How is SEO set up on the current website? How not to negatively impact this?
  • Are there any links popular in social media?
• Tools and data - what else does your website do?
  • Do you generate sales/leads? Do you have forms that get filled by customers?
  • Are there any sales funnels that are being used or work well currently that you do not want to lose?
  • Do you track users in any way? How will that be transferred?
  • How to keep data from before and after migration comparable?
  • Are there any integrations with external services? (CRM, ERP, other?)

A solid audit of the current website is important. You have to be sure that you are not destroying value which is already there.

3. Plan the future

When you know what you have and you identified all stakeholders, you can finally start planning the new website.

List all the things

List all the general content sections (eg. homepage, news/blog, products, user manuals, documentation, careers etc) that the website will have.

List all the functions, user journeys, requirements etc that you want to take into account. This will include all the requirements that you gathered from your stakeholders and which you decided are important and have to be included in the scope of the project. 

List all other functionalities, requirements, items et.

List everything.

This does not have to be a list with a lot of explanation, just a reference list which includes everything you have to take into account. 

Once you have that you can move to detailing specifications.

Map out the new website

This step is an iterative process of site mapping, planning content and perhaps a bit of wireframing. The aim is to plan out how all the content from your list will be mapped out on the new website. Eventually you should get to a moment where, on a general level, all content and functionality is planned out in a sitemap. Main pages (eg homepage) can have rough wireframes  or descriptions showing what they will contain.

The process is often iterative. It is fairly difficult to accomodate all requirements at the first attempt.  Also when the site mapping process is started it often induces creativity. New better solutions come to mind, which, at this stage, can be really easily incorporated.

It makes sense to focus on this part. This is the moment when it is the easiest and cheapest to introduce changes to the website plan.

This is also the best moment to include your stakeholders. Depending on who they are and what their involvement is, you might talk to them about the whole website or only about certain sections. Level of detail discussed will also vary depending upon the party.

List functional requirements

Not all the requirements that you will identify in your list will be content ones. Many will be additional other specifications eg:

• SEO requirements
• Accessibility
• Editorial workflows and editorial experience
• Search specifications 
• Multilanguage mechanics
• Integrations with external/internal systems/services etc

Specify these elements as well. These do not have to be very detailed. At this stage I would recommend high level requirements descriptions focusing rather on the goals rather the actual implementations. Eg. “editors should be able to add new pages build out of sections” rather then “by clicking on the ADD CONTENT button users will open such and such form”. 

Asses timelines / budgets / approach 

When website is mapped out and all requirements understood it’s time to assess what you are up against. 
Knowing what you have and where you want to get, you can estimate the effort. At least on a very high level you can estimate 

• how much work this will require
• how long it will last
• and how much it will cost

Often at this stage it turns out that the goals are too ambitious to be delivered all at once. Usually the reasons are:

It would be too expensive. Your budget will not allow building everything in this budgeting cycle (eg. fiscal year) or does not allow such an expense at all.
It would take too long. We advise to plan to deliver first benefits of the new project within 6 to 8 months or earlier. If you have to wait longer to deliver anything useful, your plan is not correct. You will put your company under pressure and you risk delivering less value. 

If that is the case, this is the best moment to start adapting:

• Plan for phases - we always advise clients to split work into phases. Especially large projects that are to take a long time, should be split into phases with the first phase planned in such a way to deliver results in 6-8 months or less. Then further phases should be even shorter with 2-4 months being a good time span.
• Cut scope - asses if you really need all the features. Perhaps business objectives can be achieved even when you do not deliver everything that is desired?
• Simplify  - see if any of the objectives that your requirements are trying to meed, could perhaps be achieved with simpler solutions.

Eventually you should end up with a project that is feasible within your timeline and budget.

5. Assemble your team

The team that will be responsible for delivering a website is usually assembled as the project continues. On various stages, new team members join and others leave. Typically there will be a core project team which stays with the project from start to finish and other participants that may join only in particular moments.

It is very important to create a team which has time to deliver the project. Creating a team out of a group of people who have their other daily duties will not work. Building a great website takes time and effort. It cannot be achieved successfully by someone who has just a few hours every other week.

6. Plan delivery

When all the dots are in place, you can finally create a timeline for the delivery. We in Droptica are proponents of agile methodologies and we always suggest that you should choose an agile approach to building websites. That said, we still believe that a good plan is important. Setting clear milestones with dates allows you to track progress. You can of course adjust and adapt, but you will be doing so consciously.

Create a plan which outlines what has to happen by when for you to be able to deliver the website in time and budget. You will be able to track progress as you move through the project.

Your plan is complete!

You now have a full website development plan.  You can start building your website and you are much better prepared to do so than many other companies out there. 
Good luck!