5 Documents You Need for a Successful Website Redesign
We’ve already talked about how important it is to do your due diligence when taking on a website redesign – figuring out your audiences, securing buy-in from your leadership, selecting good partners and vendors, the importance of quality content for your website – and we’ll be diving in deeper later in this blog salon about working with staff to create and revise quality content.
As you continue to bring together all these great resources, it will be helpful to compile them in a format that will be useful to your team and your vendors. During our website redesign, we ended up creating a number of documents that helped us fully scrutinize and contemplate all of our options. No stone was left unturned, which helped our stakeholders feel more comfortable with some of the drastic changes we were suggesting.
1. List of audiences/use cases
You should now know how to figure out who your audiences are – a crucial piece of information since they are the people who will be using your new website! Turn that information into a list or matrix format (whatever suits your needs best - we used a Venn Diagram) so that all of your stakeholders can agree that these are the most important people to consider in this project. When there is a disagreement during any part of the process, go back to the audiences list and ask yourself, “What would best serve the needs of this user?”
To know how to best structure your content on your new website, you have to know the structure of the content on your current website, and how the two will differ. Depending on the size of your website, this may take a fair amount of time. We ended up using a combination of an Excel spreadsheet (that had a ton of important details) and a Visio flowchart (that just gave a snapshot view of the top 5 levels of pages).
Our Visio flowchart was a one-page chart that visually represented the hierarchy of the top levels of pages on our new website. Each page that was listed included a call number that referenced the Excel spreadsheet (so you could quickly find additional information) and the name of the page owner. A variety of colors and icons represented different types of pages that were specific to how we built our site: redirects, hubs, jump sites, etc.
Our Excel spreadsheet listed a row of information about each and every page we wanted on our new website:
- a call number to designate hierarchy within the website
- the new name of the page
- the URL of the page on the current site (if it existed)
- the content status (was it new content, did it need to be revised, or could it be copied/migrated directly?)
- the content type (this is where “batching” comes in handy – treating similar pieces of content similarly, i.e. news, bios, events)
- container type (which type of page would this content fit on, based on our design wireframes?)
- categories (a subset of “content type”)
- tags (we used tags across our site to dynamically pull content)
- source and notes (any additional information we needed)
Having these two very detailed sitemaps helped us place all of our content based on our new navigation before every building the website – which helped us avoid any oversight, and prompted decisions that could be made prior to crunch time.
3. Design wireframes
A wireframe is like a blueprint of the design of your website – it is a skeleton of how your website will look (often leaving out most stylistic elements). We had multiple rounds of design wireframes, starting after we had done our initial analytics research and user testing, each one more detailed than the previous iteration.
Once we had gotten a good sense of the problems we wanted to solve with our old website, we could design wireframes that fixed those problems. At this point, we also had a better idea of the types of pages our new website would need and the types of content we’d want those pages to hold, so we could make a wireframe for each page type that included some additional functionality or design details. When we decided that our website would be responsive, we also created wireframes for different versions: mobile, tablet, and desktop.
- Our first wireframe was made in Visio – it included some of the most important items we knew our new website had to have. This is the first time our site started to take shape.
- Our second wireframe was made in Photoshop – it was build on a 960-pixel grid, so it was much more to-scale than our previous iteration. Also, by that point, our navigation was more developed. It’s interesting to compare this to the new AmericansForTheArts.org because you really see the similarities, even though this was created 15 months prior to launch!
- Our third wireframe brought content hierarchy into play – we used grayscale to distinguish which content we wanted to get the most attention on the page. This would ultimately help our designer create a design that would draw the user’s eye to the places we intended. (We’ll discuss the design process in more detail later in this blog salon.) This was a tricky process because we (of course) felt that all of our content was important, but we understood that not everything could be front-and-center.
- Our fourth wireframe was our most detailed version – we created this after selecting our designer, and then we made a “mash-up” of our third wireframe with the wireframe template that our designer typically used. This iteration was created in Axure, and each item was numbered so that you could find additional descriptive information on a separate document.
An RFP (or Request for Proposal) is a document you send to a vendor that outlines the details of your project, asking them to submit a quote listing the services they could provide and at what cost. You will likely send an RFP to each of the vendors during your selection process (read our blog post about finding the best partners!), and their response (or “proposal”) will help you make your final selection. Make sure your RFP is an accurate and thorough representation of your project, and use it to ask the right questions of your potential vendors.
5. Vision and Requirements Documents
Sometimes these can be combined, but we created them as two separate documents due to the scope of our project.
Our Vision Document was just that – our “vision” for the new website based on all the work we had done. It was a document we created internally that housed all of the information we compiled during the research phase of the project – it included everything from background on our organization to our analytics and audience results to the goals we had for the website design and functionality.
The Requirements Document was more technical – we worked with our development vendor to define every detail of our project, from technical specifications to framework to content types to integrations. It detailed the cost of the project as well as the total scope, which was crucial during the building phase because it allowed all the stakeholders to understand what was included and what was extra.
If we had a disagreement during the building of the website, we could go back to the Requirements Document for the final call. If we came up with a new idea (or maybe came across a roadblock we hadn’t anticipated), we understood (as clients) that it would cost us extra because it wasn’t included in the Requirements Document. Doing your due diligence to make sure your Requirements Document is comprehensive, complete, and accurate can save you thousands of dollars on a website project.
Though creating all of these documents may seem daunting, they are not all created at once – they are done over time, as you compile information and feedback. And they should all be living documents – you should continue to edit and tweak and reference them throughout the entire redesign process!