5 ways to optimize your implementation

1. See what you have and how it performs 

This is bigger than content inventories—let your next big move or implementation be an opportunity to purge old or outdated content and clear out redirects. It’s not easy when certain stakeholders don’t want to let content or pages go, but this is where you can let data help make tough decisions.   

We started in two different content management system (CMS) instances prior to our latest web consolidation. Before we could even begin to envision our new site, we needed to truly understand what we had. First, our former Optimizely content was cleaned up in another CMS, and our former Episerver content was replicated in a new instance that would become our new site.   

Before migrating former Optimizely content into our new CMS, both had to be assessed for continuity including anything from reports and whitepapers to gated assets and external links. Our Optimizely content was evaluated and prioritized in terms of relevancy, traffic and structure to determine what would be migrated “as is”, what would be moved with adjustments and what would not move over at all.  

We knew before we began the content audit process that it was crucial to maintain an upwards growth trajectory. We needed to have a clear and concise plan of how we were going to not only migrate but improve content performance. For example, our Optimization Glossary “Optipedia” saw consistent organic growth year-over-year since it was created. Leaning into and revising this content enabled us to rank well for optimization terms like “A/B testing”. 

Once consolidated, our new instance was already well-structured and enabled our digital team to easily reuse and restyle content, map old properties to new ones and prioritize tasks. Design teams were able to form a rebranding list to prioritize and work from, determine teaser image needs and identify in what places logos or product names needed to be made consistent.    

It was a major advantage for us to have our content mapped and cloned in our new instance. Cloning our former Episerver site, and taking the time to clean up the content on the former Optimizely instance allowed us to assure stakeholders that none of our content was completely wiped.   

Before, during and after content was reviewed by stakeholders, it was looked at in terms of performance. Traffic continuously helped to determine what could be cut, moved, archived or revised. It also helped bolster decisions if questioned.   

 2. Visualize your new instance 

Creating a great user experience is not easy—despite meticulous planning and the best intentions, sites can become complicated and hard to navigate.   

Envisioning our customer journey started early with a brand assessment. We knew we wanted to maintain a grid system across our pages, wanted slick spacing and had a solid vision of our new brand identity. This helped us move into annotated wireframes of what our site would look like, and most importantly, why.   

To get a true view of every customer touchpoint, the digital team created a master list of redirects and URLs. We didn’t want live pages to look broken or users to end up getting 404 errors right out of the gate. It was important for us to clear out any remaining old redirects and avoid overlap in our new instance.   

Our URL rewriter workbook was formed with crawl scripts and tools to map our website in its entirety. We tried to keep documents like this one live and flexible to avoid reworks.   

In addition to the look, feel and overall experience of our consolidated website, we knew we needed to envision how it would all work. Building in the new CMS instance and testing new elements such as workflows for creation, QA, user testing, language versions and market personalization was critical.   

3. Maximize your inputs 

No matter the scale, interdependencies across team and department lines can make or break an implementation. It can be hard to know when to stop running fast, who to pull in when and how to track progress.   

It may feel like executive buy-in is the first step of a project, but a lot needs to come together to get to that point and approval is something that needs to be maintained throughout implementation. Customer interviews and a high-level competitive analysis gave us a great starting point in crafting proposal documents that contained our intentions and the “why” behind them. Although stakeholder interviews were another huge part of our proposal process, meeting with them periodically helped us to continuously balance wants and needs as well as assess impact over effort.   

Even with project approval and executive buy-in, the digital team knew our biggest risk. The broader organization did not fully understand the prioritization and importance of the project, and therefore the urgency of their inputs. We also knew that a new website would not solve all business problems—it could create more without proper preparation and diligent organization.   

Meeting within the digital team daily, with partner and supplier teams weekly and keeping in touch with cross-functional teams constantly—we developed regular status checks and a clear roadmap with transparent intentions. No matter how often things changed (sometimes by the hour), we kept a pulse on our project status and reiterated process updates and improvements.   

Our digital team needed to be flexible. We needed to be able to switch responsibilities quickly and wear many hats across fields and parts of the CMS. To facilitate this agile mode of working, the whole digital team attended content reviews. This way, everyone knew what was being worked on and could jump in for more tedious tasks from image and copy updates to content gathering.   

4. Make feedback loops momentary  

To avoid the communication issues and overlaps that come from working with so many departments, we sought to make feedback structures strict and timely. To do this, we set clear expectations on what we were asking for and when.   

To start, we had content owners do a first sweep of pre-existing pages and newly consolidated information to get a pulse on what would need to be recreated, thoroughly revised or completely reimagined for launch. With our core content in sight, we were able to set expectations on what content we would need going forward, and roughly how it might look.    

In one to four-week sprints, we showed stakeholders wireframes of what their pages might look like and gathered new or edited content from them. Though we would have loved to do this all in-system, our frontend was completed in stages that sent us back to more static modes and templates of page types that were not finalized. Our instructions were simple: write like you would talk, be as brief as possible and supply any additional information that might help content writers and editors.   

Although tedious at times, this constant collaboration gave cross-functional teams a single view of content and an easy way to determine what was still needed. Setting clear expectations on when we needed input and content by helped drive stakeholder engagement, most of the time. When deadlines were being pushed by everlasting workloads across the organization, we had to get pragmatic about the impact latencies would have.   

Telling a stakeholder “If you don’t meet this newly extended deadline, we will not be able to have your page at launch” was never fun, but it was our reality. Between random issues we didn’t expect on the development side and last-minute requests from across the organization, the digital team had to be realistic about prioritization and deadlines.   

 5. Make post-launch a part of planning  

There is never enough time to implement everything. Things come up, and it is important to expect the unexpected. You can get so wrapped up in planning for launch that it is easy to forget about life after go-live.   

In the case of our web consolidation, we quickly realized how much we would need to save for after launch. There would not be enough time to do it all, so the closer to deadlines we got, the more refined project scopes became. We started accelerating our prioritization in a staged approach that we knew we would come back to. Knowing key deadlines as well as what we specifically wanted to achieve at all times provided us a realistic view on tasks and enabled us to become very pragmatic with critical areas.   

We learned that pre-production sites should be as close as possible to launch so you can test effectively, you need to understand all applications that you need to integrate with, and it is crucial to thoroughly test integrations. This helps you address and prioritize pain points early on, and in our case, decide what we wanted to experiment with and personalize, first.   

One of the biggest steps we wish we had taken was having developers do a first sweep of our backend much like content owners did on our frontend. Because we didn’t, post-launch development tasks became massive rework efforts that ate into other tasks we had saved for after launch.   

Regardless of what we ended up learning along the way, we knew early on what we wanted to measure. Using our Measurement plan document, we measured performance on our site before and after launch to gauge any differences or improvements.