Launching a website redesign is often a relative success. “We pulled it off,” is the general sentiment, in spite of budget overruns and timeline delays. We celebrate a battlefield victory and, resources spent, forget that the war has just begun: The website we’ve launched now needs to be maintained.
Is this a foregone conclusion? Or are there steps we can take at the crucial starting point of a redesign process to ensure truly successful launches and long-term success? Time and cost overages result from reactive decisions made in isolation further along the timeline or requirements that emerge late in the process. How can we ensure better decisions and eliminate surprises from website redesign projects where minimizing time to launch and maximizing budget are crucial to any organization?
Every successful project starts with a solid plan. In my experience, solid planning can be attributed to two factors: Educating decision-makers and accurately setting expectations.
A well-informed project team will make better decisions over the course of a project, resulting in fewer missteps and less back-tracking. Stakeholders who understand what’s at stake in every aspect of a redesign project—design, coding, content—should be our goal. The web team should make it a priority to educate other players on how things work.
But educating our teammates, whether clients or colleagues from other departments, on how a website project should work implies teacher/student roles and a commitment to learning a new set of skills and responsibilities. Our busy peers would rightly resist enduring a required Website 101 class. That’s what the web team is for.
Instead of teaching our colleagues how the website project should work, we should instead focus on knowledge transfer. What’s the difference? I see teaching as a one-way process where, unavoidably, we’re talking down to our peers from our level of expertise, holding them captive. That’s as unappealing as it sounds. Knowledge transfer, in contrast, should be a natural byproduct of a collaborative session in which goals and benchmarks are established and discussed. In that session, the web team should gain crucial insight into the business functions they’re supporting while imparting crucial insight into how the web, and its opportunities or constraints, will impact those business functions and goals.
How we structure this collaborative session is most important. This is a mandatory kickoff meeting with a clear agenda: work through all of the factors and hidden traps that affect a successful website project while making sure everyone fully understands what’s at play and what’s at stake. We call this an Outcomes First agenda. Its stated goal is to set and understand expectations, as well as declare and validate assumptions. Through this dialogue, knowledge transfer occurs passively, and a well-informed team can emerge.
What are some of the items on our Outcomes First agenda?
We often work with marketing departments looking to launch a new website on a content management system that will enable them to update the website directly without relying on their IT department or knowledge of code. The implication is that enabling such a platform will absolve the team of requiring support from an internal department tasked with other priorities.
In reality, it’s impossible, or incredibly costly, to design page layouts and templates that will anticipate every type of content the team will want to post, and those content management platforms require some degree of ongoing maintenance and support. Promises made based on product feature lists fall flat, assumptions about workflow don’t match up with how people really do their jobs, and soon the website suffers due to lack of committed effort.
The biggest challenge in this scenario? The marketing department secured a budget for the website for the year, and all of it was allocated to the website project, with none left over for post-launch support and enhancements.
Evaluating post-launch and project support should be a top priority in a kickoff meeting. How these will impact budget available to design and development of the website itself needs to be fully vetted so that adequate budget is preserved to make the website an ongoing success.
Scale is a lens to look at project requirements and determine how much of any given component is needed. How much design? How much functionality? How much support? How much content? A discussion of scale should result in multipliers that determine budget and timelines.
Let’s consider design as an example. Two organizations are planning redesigns of their 40-page websites. One may be focused on fundraising and volunteer recruitment. Another might be focused on enabling members to quickly and easily access resource materials. The former may benefit from an immersive experience that draws potential contributors in while telling the organization’s story. It may incur much greater costs in the design effort and, by extension, the effort to code those designs. The latter may satisfy users’ needs through simplicity, clarity, and a smaller number of distinct page layouts. These two projects will operate at a much different cost based on the scale of their respective design efforts.
Mileage is a lens to look at the project and determine, “How much do I need to get out of this project?” or “How long does it need to last?” A landing page project focused on a single event or offering is much less mileage-focused than your organization’s core website.
When looking at mileage, we should focus on long-term viability—the effort required to sustain the website—and seek to avoid trendy features or design techniques that will be stale or unsupported in a year’s time. We should be looking beyond immediate return on investment and focused on long-term value.
Content First has become a popular term in website projects, for good reason. Waiting until the website is fully built to install completed content just before launch typically requires reworking designs and content fields to suit real world requirements.
Determine what needs to be rewritten, what needs to be preserved, and identify as many examples of real content up front to have a meaningful conversation about what the web team is designing and building for. Discuss content strategy and how content needs to adapt to or support different contexts, from large desktop monitors to tablets, smartphones, or social media. The purpose of most websites is to host and provide access to content. Establish content’s impact on your project early on.
We finally have something built and ready to release to the world. Time to celebrate!
Not just yet. The launch of a redesign is where things really break down. The budget’s been spent on the build and surprises are popping up left and right. One group needs to ensure that their repository of PDFs is still accessible. Redirects for old URLs that no longer exist need to be created to route traffic and search engines to new content. A number of individuals, having seen a preview of the website, are now asking how it will impact their department.
And the hosting platform you thought you’d be launching on? IT just decided it doesn’t meet their standards.
Comprehensive content audits, proactive efforts, education and vetting requirements should establish a launch plan before the site is even built, and carve out a budget reserve for that process. Build consensus around launch parameters early on. As with support, your goal in examining launch is to identify all the costs that must be taken into account, to determine what’s left over for the design & build.
Closing the Gap
Gaps in expectations and assumptions, between web teams and stakeholders, are where budget and timeline overages lie. By focusing on effective knowledge transfer through an Outcomes First agenda, understanding and setting stakeholders’ expectations, and proactively planning for pitfalls, we can better ensure that our website redesign project will be a success.