Software Engineer | CS @ Auburn
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.
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!
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.
It's time to dive into UX research.
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.
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.
Discuss the wireframe options with your team and narrow down the layouts that will work best for your users.
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.
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.
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.
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 your 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).
Now it's time for browser compatibility testing. There are two approaches you can take.
Make note of any bugs that are identified and triage. Determine if/what problems need to be addressed before the go-live date.
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.
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.
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!
Create your free account to unlock your custom reading experience.