Before you redesign an existing website, let me take a moment to explain an alternative approach that will ensure success.
I have written before about how I am not a fan of periodic redesigns of existing websites. I believe they damage the user experience and are often an unnecessary expense for the business.
However, I accept that not every website is in a suitable state to be iterated upon over time and that a more extensive rethink may need to happen.
In this post, we will explore how I work with my clients to manage the redesign of an existing website.
We begin by looking at how most organisations are getting the redesign of their existing website entirely wrong.
Why Most Organisations Get the Redesign of Their Existing Site Wrong
Typically the redesign of an existing website begins with somebody within the organisation merely concluding that it needs doing for whatever reason. However, rarely is this conclusion based on any concrete data. Typically it is made because the “design looks a bit out of date” or the “technology is not fit for purpose”. That is because a worrying number of organisations do not have any clear idea of their site’s key performance indicators.
Even more concerning, this decision to redesign an existing website often results in throwing out the entire site and starting again. There seems to be little attempt to isolate the problem and fix it.
Next, various stakeholders are brought together to decide what the new website needs in terms of functionality. Again, these stakeholders rarely base this on data or an analysis of user needs. They merely decide based on their observations.
Only once these decisions have been made does the organisation bring in digital professionals. That is often in the form of commissioning an outside agency but can also involve taking the brief to an in-house team who is often treated as nothing more than a service department that is expected to build the site.
In either case, the specification for the redesign of the existing website has already been defined without any input from those who most understand the potential and limitations of digital.
At this point, quotes are provided and timescales set with only limited discussions about whether the project is necessary or its scope correct. Once the quote is accepted, work begins and scope creep is the enemy and deadlines are unmovable.
That leaves no room in the redesign of an existing website to learn and adapt during the build phase. Yes, some minor tweaks may be made along the way, but with the constraints of the specification, timescales and budget all set, little real change will occur. Once again, user feedback is largely ignored.
The result is that the organisation has no way to know whether all this effort and money was worthwhile until after the website is launched. Only then will they know if the new website performs better than the old one, presuming, that is, they have any metrics by which to measure its success.
Worse still, once the website is launched, the money dries up, and people move on, meaning that there are no resources to fix any major issues that come up. Yes, there will be some minor maintenance, but that is it.
How then can these problems be avoided?
10 Steps for The Successful Redesign of An Existing Website
My key to the successful redesign of an existing website is recognising that digital projects shouldn’t be run like traditional projects. With digital, it is easy to learn about what works and what doesn’t, as well as quickly adapt to what we learn.
With that in mind, here are the 10 steps I use when redesigning an existing website.
Have Clear Goals
Before I even think about redesigning an existing website, I establish a clear vision of what success will look like. Without clear goals, I have no idea whether I need to undertake a redesign or what the new site will need to achieve.
Typically I tend to focus on three critical areas:
Once I can clearly express my client’s business goals in terms of measurable metrics, I turn my attention from what the business wants to what the user needs.
Do Your User Research
To encourage people to act on a site I need to know them. I need to understand what questions they have, what tasks they want to complete and how they want to interact with my client’s site.
That means it is crucial that I carry out user research before I start thinking about the specification for the project. It makes no sense to define content and functionality before I know that the user wants those things.
Once I know what users are looking for and what my client wants to achieve, I can now look at the existing site and make an informed judgement about whether it needs redesigning in its entirety.
Benchmark the Existing website
I take the key performance indicators and user research I worked on with the client and use them to assess the existing website. In most cases, I also carry out some usability testing on the website too and sometimes look at the competition for a frame of reference.
Doing so provides me with a much more objective view of the state of the website, rather than just redesigning it on the hunch of my client.
Even if it feels obvious that a redesign is required, this step is still advisable. The client may be wrong and even if they are not, benchmarking an existing website helps me ascertain just how much of a redesign is required.
Establish What Can Be Kept (if Anything)
I hate waste and inefficiency. I believe in salvaging what I can from an existing website, rather than starting from an entirely blank canvas each time.
If the site’s content is good, keep it. If the technology platform does the job, don’t change it just because the developers want a new shiny toy. But, most of all, do not create an entirely new design if you can evolve the existing design.
That isn’t just a monetary consideration. That is also because existing users normally don’t respond well when you make changes. You break their mental model of the website and so increases their cognitive load. If possible we want to avoid that.
It is also important to stress there is no reason we need to change everything in one go. Sometimes it is easier to ‘upgrade’ a website in stages. I have to make this judgement on a case by case basis and to be honest there are no hard and fast rules here.
However, if I conclude the content needs changing (which it often does), I always start with that before looking at technology or design.
Start with The Content
It feels like the content is the most neglected part of any redesign of an existing website. Clients are often unwilling to pay money for a professional to create their content, and it is often the last element of a redesign of an existing website that the client addresses.
This attitude towards the content is dangerous as it is the content users come to your website for, not the design or technology. Also, it is impossible to create a compelling user interface for a website without understanding what content it will be supporting.
I, therefore, start the redesign process of an existing website with the content and I always make sure that content begins with user needs, not just what the company wishes to say about itself.
Until I have the first draft of at least some of the content I will not even think about design. I will also need an outline of all the content that needs creating in order to structure the information architecture.
Work on The Information Architecture
Once I understand what content needs creating, I start to address the information architecture. For me, that always happens before the design, because I use the process of creating the information architecture to establish the visual hierarchy.
With my site structure in hand and at least a first draft of content for some of the critical pages, I can start to work with a designer to address the redesign of the existing website. That is a process that happens through the creation of increasingly sophisticated prototypes that I will test relentlessly.
Prototype and Test the Interface
My first explorations into the redesign of an existing website may well be nothing more than a few sketches. However, even these can be tested to see if the user understands the basic premise of a site and spots critical components.
Sometimes I move into something like Sketch to start refining the design further. These prototypes can be tested using flash tests, preference tests and other forms of design testing.
However, the problem with tools like Sketch or Photoshop is that they are possibly the worst way to show the interactive and dynamic nature of a website. That is why I quickly move into the browser.
Once in the browser, I can start to build a prototype of the site structure and even input the first pass of the content. This prototype may lack a refined design, but it will allow me to carry out usability testing on the information architecture and findability of content.
This prototyping phase is all about testing and iteration with the prototypes moving increasingly towards an approach I can be confident about.
The final iteration of this prototype will become the template from which the final site is built. That replaces the specification, but is instead built on evidence and allows me to avoid endless discussion and debate.
Once I am confident in my prototype, we move into building the final redesign of the existing website.
Build a Beta
The beta build mainly uses the prototype as its starting point but produces it to a release ready standard with full functionality and the ability to work at scale.
I work with the client to refine, and after testing, finalise their content. I spend time with the developers helping them understand the prototype and be clear about what they are building.
I also spend a lot of time with the client, developers and designers establishing a design system and associated pattern library for the redesigned site. From my perspective, this is a critical part of the process as this will help ensure the website can evolve post-launch.
That is important because I don’t wait for the site to be perfect before going live.
Launch a Minimum Viable Product
I have seen too many redesigns delayed as those involved endlessly tweak and agonise over every detail. That strikes me as absurd because in most cases the site is already considerably better than what is currently live.
I think this stems from a print mindset and the feeling that once it is published, you will no longer have the opportunity to change things. But that should not be the case with the web if you have the right attitude, funding and relationship with developers in place.
In most cases, I treat this initial ‘go live’ moment as about two-thirds of the way through the ‘project’ rather than at the end. Instead of launching a perfect site, I begin with a minimum viable product.
Some clients fear that they may alienate users if they launch a less than perfect website. In such cases, I start with a public beta. In this scenario, the existing site remains online, and users are invited to try the new site.
In either case, I closely monitor user behaviour when we go live so that we can learn and iterate upon it.
Embrace Continual Iteration
Once a site goes live, you will find me obsessing over analytics and using tools like Fullstory to watch user sessions.
If the site is an open beta, then I watch closely how many users who check out the new website then stay on it, and how many retreats to the previous site.
But whether open beta or live site, I am tracking the metrics I defined with the client at the start to establish how well the site is performing against the previous version.
Based on what I observe, I will start to optimise the site and make improvements. If I spot something that is under-performing I may run an A/B test using possible fixes and see if they perform better.
Over time, I typically step back, but the work continues with the client taking on the role of monitoring the site and testing possible improvements.
By continually optimising and iterating on the existing site, it avoids the website getting into a state where it will ever need a complete redesign again.
Of course, to ensure that the site continues to get the attention it needs it will need a team of people continually working on it. The site will move from being a capital expense to an operational one.
At the very least, the site will need a product owner who is ultimately responsible for its success. Unfortunately, all too often, and despite my best warnings, I see websites flounder once I step back because nobody is dedicated to its success. Instead, responsibility is shared across many and so it ends up at the bottom of everybody’s to-do list.
So, let me end with some key takeaways to make sure your next redesign is your last redesign.
- Avoid redesigning your website if at all possible. Instead, evolve and upgrade it as required.
- Stop treating your website as a capital expense every few years and instead continually invest in it.
- Have clear goals for your website.
- Validate and test at every step of the journey.
- Use prototypes instead of writing long specifications.
- Start with the content.
- Make sure somebody owns the website and is accountable for its success.
So, I hope this glimpse into my methodology has helped, and if you need a guide through your next redesign process, I am here to help. Just hit the button below!
Stock Photos from Brian A Jackson/Shutterstock