5 Lessons Learned from a Large-Scale Website Overhaul
The process took nearly 2 years. And if I had to do it all again, here’s what I’d get right the first time.
A bit of background
I was a user experience manager, specializing in online content strategy at Canada Post, Canada’s national postal service serving over 16 million addresses. In 2016, it became clear through data and customer feedback that the company’s high-traffic website (278M visitors in 2018) needed to be rebuilt from the ground up.
Imagine this: hundreds of webpages detailing B2B and B2C products and services owned by multiple business units in two official languages. Some of these pages looked as if they were designed over a decade ago, some had missing or outdated information. All of them had to be rewritten, redesigned and reorganized into a system that made intuitive sense to our customers. And it seemed everyone in the company was interested in having a say.
Now, I was very fortunate to work alongside some extremely talented colleagues who tackled this project from the perspective of their specialties (user interface design, interaction design, user research). This was in no way a one-man show. But as the project unfolded, my role transitioned into product lead and the building and maintenance of the website became the flagship of my product portfolio.
It also became one of the more interesting challenges in my career to date. Here’s what I learned as I attempted to balance the needs of the customer with the expectations of over 20 stakeholders.
1. Map out stakeholders early on
In a stakeholder-heavy project, be prepared to have a lot of conversations. Before you start investing time in them, hit a whiteboard and plot out a stakeholder map. Get as much feedback on it as possible and don’t prune until you’ve exhausted your resources. Is there a say from legal? How about the brand team? Try your best to understand who’s responsible for what and to what degree. From there, you can bring the list down to only key stakeholders. Aim to get agreement on the final list to avoid the chance that more people pop up once the project is in full swing.
2. Conduct stakeholder workshops to gain alignment
Our team had done a lot of user research up front, but we realized that it was equally as important to give a voice to internal business owners. These folks live and breathe their product or service. They have goals, strategies and often a clear vision for the future. In some cases you might find, as we did, that stakeholders from the same business unit have conflicting ideas. It’s important to bring that to the surface early on, and a great way to do that is by moderating stakeholder workshops.
We started by breaking down our stakeholder list into smaller, complementary groups of about 8 people. We wanted a mix of perspectives so we invited representation from marketing and product, both entry and director level. All working together to help shape user goals, business goals, our voice and the content we wanted to prioritize.
The outcome of these workshops not only gave our designers a clear path forward, they became very useful in keeping stakeholders on course during the revision phase.
3. Set the rules of engagement
The revision phase for a project of this size can easily become a tangled web of marked up Word documents. In the beginning, we had multiple stakeholders from the same business unit take it upon themselves to rewrite and redesign entire pages. Every writer and designers nightmare!
We felt it was important to empower the design team to make the final call given a multitude of perspectives. So we determined it was necessary to set and communicate some rules of engagement:
- Each business unit would have 1 representative responsible for collecting and amalgamating feedback on behalf of said business unit. This way stakeholders would have to settle their own differences of opinion.
- Only the comment tool could be used in the document. We didn’t allow for the overriding of the work our content designers. All stakeholder comments were weighed against the discoveries from our user research. In the case of conflicts, the user usually wins!
- With each page revised, stakeholders had to fill out a form stating whether any information was missing or inaccurately portrayed.
Done this way, the design team would receive comments to consider on content and layout in one synthesized document, saving time and a lot of back and forth.
4. Stagger user and stakeholder feedback
In a project with many moving parts, it’s easy to lose the voice of the user with the pressure of deadlines.
At first, we designed the project workflow to front load 2 rounds of usability tests ahead of 2 rounds of stakeholder feedback. Given the longer lead time for research recruitment, especially when the user is niche, we thought it was best to complete this step before feeding our work into the scrum team. Initially, we expected stakeholder feedback to be minimal given we had a strong jumping off point having done the workshops.
But this workflow allowed for a crucial oversight that didn’t become obvious until we launched the first batch of webpages. Early metrics showed we hadn’t made as significant an improvement as we hoped from the previous design. We were forced to step back and ask ourselves: Over the course of 2 rounds of stakeholder feedback, how far did we move away from what we heard from the user?
As we reset to tackled the next chunk of the website, we took the opportunity to redesign the project workflow to ensure that through the 2 rounds of stakeholder and user feedback that the user had the last word.
The outcome of the change was significantly better feedback from our user base after launch and an overall System Usability Score of 86 ( industry standard is 68).
5. Document and communicate major content and design decisions
In a company as large as Canada Post, there’s no doubt that on a weekly, if not daily, basis someone in the business has a request for a new page or a tweak to an existing one. After spending months bringing the website to a new standard, it would be remiss to let that standard slide due to lack of awareness of the new status quo. And the design team shouldn’t be bogged down with the role of gatekeeper.
That’s why it’s important to document and introduce to stakeholders the new system that was built. This not only adds legitimacy to why things needs to be done a certain way going forward, but it also helps onboard new designers who will have to build upon this new system. At Canada Post, we decided to launch a design system called Mercury. It covers everything from design principles to tone of voice to how we design buttons.
You may not have the time or resources to launch such a robust artifact. But you can start small by keeping a working document pinned to your design channel on Slack or on your company intranet. A unified system will help you scale your website more quickly while avoiding the slow creep of creating pages that feel like they’re a distant cousin.
A large-scale website overhaul can seem absolutely daunting at the outset. But a little structure and a lot of communication is the key to hitting that launch button on time and with all of your marbles.
