13 questions to ask before redesigning a website

To create the perfect website redesign, you'll often want to start afresh. However, you risk losing useful elements and throwing the baby out with the bathwater.

It's better to perform a thorough site review to ensure you keep the great bits of an existing site, protect your client's ability to amend and maintain the site, as well as developing the brand in the best way possible. Here we explain the best way appraise a site prior to redeveloping it.

Getting answers to the following questions will help you to develop a cohesive plan and ensure your next project goes without a hitch.

01. Does the site need redesigning?

Possibly the most important question of all. A site redesign should have a purpose - it's not just an end in itself. The client may assume that the best way to refresh a brand is to refresh its website, but sometimes that's putting the cart before the horse. Just asking the question at the earliest stage possible can help clarify the client's thinking and save you a lot of time further down the line.

02. What are the brand guidelines?

A redesign of a site belonging to a global brand is always going to need to follow some guidelines. There's a good chance that the brand has developed over time and the marketing departments may have changed the way they look at things, allowing more freedom for certain projects to push the boundaries of the base brand guidelines.Smaller sites may still have guidelines that the client wants you to work to. Always take this into account.

03. Is the visual hierarchy salvageable?

A well-designed site could easily appear tired and in need of a refresh, but may contain a great visual hierarchy and images. It's worth maintaining an open mind here; there's no need to lose things for the sake of it. If it's good design, then develop it and make it even better.

04. Does the server support what you want to use?

Often on a site redesign you are tied by hosting agreements that may have been in place for a long time. Although it's pretty much always easier to take new web jobs into a hosting environment you use, you will find occasions where you need to adapt. This means getting your head around a different control panel and making sure that the set up they have supports any libraries or plug-ins you need.

Sometimes, you may not actually have an environment that supports your preferred language. For example, you want to use .NET but the client's hosting is running PHP. At this point you need to make a good business case for uprooting and moving the site elsewhere. You may also find that the client's IT department govern these changes meaning you may have no say in the matter.

05. Does the client want to keep the existing CMS?

You can't teach an old dog new tricks. This is quite often true of non-technical people; once they develop a way to 'get stuff done', they persist with it no matter how inefficient or odd it may seem to a tech-savvy person.

If the site is old, it may be using a dated CMS that's at the very least in need of updates running on it or, it could be running on a simple homemade CMS. Can you show that the CMS you would use is going to make the client’s lifer easier, the site better, or save them money?

06. Is there so much legacy data that moving is pointless?

A big directory-type site can contain lots of legacy data. Imagine a tooling website that sells small fabricated parts. It could easily have several thousand items that have built up over time. You need to balance the urge to use a certain technology with the appreciation that this data somehow needs to fit into your new database scheme.

In some cases, the client will be on-board with this and is happy to get an intern in to do data entry for a month or two. In others cases, you need to see if you can work within the old data structure or offer a good migration solution within your budget.

07. Is there a business case for your technical solution?

When a client is paying money to develop its website, the bottom line is that they are looking for a return on investment. Will your technical solution offer something, whether that's extra stability, scalability for the future or extendibility for the company's growing needs?

If you aren't set up for the project (i.e. it needs to be in a language you don't use), then you have to make the call on whether the changes you need to make in order to facilitate it are actually worth the clients while. Sometimes, it's right to say, "I would love to, but...".

08. What is the existing codebase like?

Sites built in the last three years will often be built using divs rather than tables. There is mileage here to develop the existing codebase dependant on the size of the project and how well the code was written.

If the site you are redeveloping is small, or built with tables, then personally I would draw a line under it and develop a new site structure from scratch to ensure the best mark-up possible.

09. How does the user interface need changing?

Perceptions of what is good practice change over time as we learn more about how we use the web and as new devices emerge. A perfect example is the concept of the fold. A few years ago, you would aim to keep content above the fold and avoid scrolling. However, the development of portrait-style mobile and tablet usage has educated users to expect to scroll. The recent swathe of scrolling parallax-style websites proves this.

Complex drop-down menus can be quite awkward on a small device as tiny links are hard to press with big thumbs! Evaluate the key demographics that the site will be targeting: is there a high proportion of mobile viewers, or do the majority still use IE7? Ideally, do this with the help of site analytics. You may be surprised at the results.

10. What's the site architecture like?

Reviewing the site information architecture is also most helpful when accompanied by some analytical data from previous years. You can then see if the content the client thinks is the most important is being viewed most by the users, and take steps to address this to help increase exposure of content within the site.

11. Do you have access to source files for compiled solutions?

Is the site you're going to redesign built using a system that compiles the site? If you only have access to the finished site as the original creators are no longer around, does anyone have the source files and can you make any use of them in order to develop the project? You would hope that at handover of the original site, the client was provided with the code and resources that are used to build the site, but this if often not the case.

12. How might changes affect the website's SEO?

Don't forget about information in the existing site, such as metadata and any tracking such as Google Analytics. The site may well look awful but be doing really well with SEO. It would be a real shame if your redesign impacts this negatively.

13. Is there new technology that will achieve goals in a simpler fashion?

It's not bad to shift to a new technology if it's going to do a better job. I would argue that rebuilding an old Flash site in HTML5/jQuery is worth the effort as you open the site up to devices that cannot see the old site and provide a current scalable technical base to build on.

Hopefully keeping these things in mind will help you to fully evaluate your next redesign before you dive head first into CSS and Photoshop. Remember this isn't a definitive list, but rather just the basic things you should take into consideration.

You may find it helpful to develop an actual checklist document that you can run through each time you evaluate a site. You can then use the same thing for ongoing reviews of the site to ensure that you help it to achieve the maximum it can for your client.

Words: Sush Kelly

Sush is a senior interactive designer at Imaginate Creative Ltd, a creative agency in Leamington Spa. He blogs at www.sushkelly.co.uk. This is an updated and extended version of an article which previously appeared on Creative Bloq.