How To Plan A Website Redesign

I recently led a corporate website redesign, which involved a move from Drupal 7 to Drupal 8. I wanted to share my process for tackling this kind of CMS-based project.

Disclaimer: The process outlined below is a guide. Feel free to adapt it to fit the scope of your project.

Table of Contents

1. Setup
2. Phase I: Requirements Gathering
3. Phase II: Research
4. Phase III: Information Architecture
5. Phase IV: Wireframe
6. Phase V: Design
7. Phase VI: Build
8. Phase VII: Content Migration
9. Phase VIII: Test
10. Phase IX: Deploy
11. Phase X: Maintain
12. Summary

Setup

Choose a project management application (Todoist, Notion, Basecamp, etc) and set up your project.

1. Create a section for each phase of the project.
2. Add tasks to each section as they come up.
3. Share the project with your team to keep everyone on-task and up-to-date.

I used Todoist for my redesign and appreciated the built-in shortcuts for adding tasks, tags, and due dates with one line of text. It was a huge timesaver in my busy office. That being said, I will probably try Notion or Basecamp next time—just to experiment with a different system. There are many other great PM choices out there though!

Phase I: Requirements Gathering

Gather the basic project requirements and confirm the "ideal" timeline for completion (if it's known).

If you're planning to use a CMS, research platforms now and get quotes if needed. Understanding the basic features and associated costs can help you identify the platforms that will work best for your project.

Tip #1: Don't commit to a timeline until the end of Phase II. Research can take time and reveal unknowns that could impact the scope of the project or the platform you end up choosing.

Tip #2: Set expectations early that the timeline is subject to change and that you will communicate any changes early and often.

Tip #3: Know who you need to communicate with—and get approval from—throughout the process. If this information is unknown, make sure to get approval from all stakeholders—at the very least—before starting Phase VI and Phase IX.

Phase II: Research

It's time to dive into UX research.

Steps:

1. Determine which types of research make the most sense for your project.
2. Implement your chosen research tactics and gather data.
3. Pull analytics from any available sources (e.g., Google, Facebook, Twitter).
4. Compile a report with all of your findings.
5. Discuss findings with your team and any additional stakeholders that need to be at the table.
6. Based on findings, brainstorm a list of all features that could address user pain points.
7. Feature Triage—distinguish "Must Have" vs "Nice To Have" features.

If you're planning to use a CMS, this is a great time to cross-reference your feature wishlist with the built-in capabilities of different platforms. You may realize that a must-have feature isn't included with certain platforms—and this could significantly alter your project timeline.

Phase III: Information Architecture

Information architecture refers to the way that content is organized on your site. One way that this architecture is represented is with navigation menus. A well-organized menu is essential to a good user experience.

Print out your existing sitemap and analyze the structure of your site (read: how the pages are organized). This is also an opportunity to conduct a content audit.

• Is this content interesting or useful to your user?
• Did the analytics highlight any common—or unexpected—paths that users are taking to access certain types of content?
• Does it make sense to reorganize certain sections or pages?
• Does it make sense to condense—or break up—certain pages?

Once you've reorganized your IA, you'll have an idea of the sections you'll need to create—along with the total number of pages you'll have to build—on your new site. This information is especially useful if you're using a CMS because it will affect the content types you'll have to build during Phase VI.

Tip: When the IA has been finalized, assign someone to start writing any new content that will be needed, and start proofreading existing content that will be migrated to the new site. (That includes confirming contact information, spell-checking names, flagging graphic elements that are no longer on-brand, etc.) It will take time to complete this process if your site is large.

Phase IV: Wireframe

Start sketching your wireframes! Grab a paper and pencil—or iPad and Apple Pencil— and start brainstorming. Don't be afraid to research other sites for inspiration, different layouts, etc.

If you're using a CMS, make sure that you sketch wireframes for each content type you'll be implementing on the new site.

Once your sketches are complete, create final versions of your wireframes with your UI software of choice. Some popular options include: AdobeXD, Sketch and Figma.

Discuss the wireframe options with your team and narrow down the layouts that will work best for your users.

Phase V: Design

Take your final wireframes and turn them into full-color, interactive prototypes. This is an important step for integrating brand elements into the wireframe. Feel free to experiment and create multiple prototypes.

If you're using a CMS, this is another opportunity to determine what features—from your prototype—are already built into your chosen platform. Determine if any custom modules need to be developed. Adjust your timeline accordingly.

Discuss the prototype(s) with your team and finalize the design. Send a link of the final prototype to all essential stakeholders. Make any necessary changes.

Phase VI: Build

Once the design is approved, it's time to start building! Set up your server, framework, platform, libraries, etc.

If you're using a CMS, you'll need to complete this phase in 2 stages.

1. Site Building—install the base theme, install modules, configure settings, etc
2. Custom Theming—customize the CSS, implement custom JS, build custom modules, etc

Tip #1: Incorporate accessibility best practices as you customize your theme.

Tip #2: Bugs will come up at this point in the process. Be prepared to alter your timeline at this point in the process. If you have to change your go-live date, communicate with all essential stakeholders. If you're not able to push the launch, revisit your feature wishlist and triage again. Consider what features can wait to be implemented until after the site is live.

Phase VII: Content Migration

Migrate your old site's content to your new platform. This can be done automatically or manually. An automatic approach may work best if you're migrating between two versions of a CMS platform. A manual approach may work best if your site is small or if your databases are not compatible. Make sure to research your options.

Tip: Incorporate any accessibility features that couldn't be added during Phase VI (e.g., alt text for newly-migrated images) at this point in the process.

When migration is complete, send a link for the test site to all essential stakeholders. Provide a deadline for users to test the new platform and proofread content. Encourage them to use different devices and browsers and make note of all feedback you receive (e.g., broken links, typos, features that don't work on certain browsers).

Phase VIII: Test

Now it's time for browser compatibility testing. There are two approaches you can take.

1. Manual testing—install different browsers on your device and pull up your site on each one to manually click through.
2. Automatic testing—subscribe to a browser testing service (like BrowserStack or Browserling).

Make note of any bugs that are identified and triage. Determine if/what problems need to be addressed before the go-live date.

Phase IX: Deploy

When testing is complete and your site has been approved, it's time to deploy! Confirm the go-live date and time, as well as the process for publishing the new site. Choose a non-peak time, preferably early in the week, to give yourself plenty of space to troubleshoot.

Phase X: Maintain

This phase often gets overlooked but as I work more with older sites, I appreciate the value of a well thought-out maintenance plan. It's easy for a site's IA to grow out of control over time—and for vanity pages to creep in. This is where a solid web content strategy comes into play. It will help you establish an audit schedule for a site's content, along with guidelines for managing that content. This will make long-term maintenance (and future redesigns!) less painful.

I'll write a future post with tips for developing a web content strategy.

Summary

Redesigning a website can seem overwhelming, but there is a systematic way to break it down and tackle it. While the steps outlined above are not necessary for every project, it worked well for my CMS-based redesign.

Have you tackled a redesign? Did you go about it in a different way? I'd love to hear about it!