Chapter 24

Maintain and Improve

Summary

And the real work begins: how to manage the support and maintenance process, circulate and check new content, and keep the site fresh long after launch day.

Does This Apply?

Yes, yes, a million times yes. If you don’t maintain your site after launch, then you might as well have given away all of that money and time you’ve just spent. In fact, next time, just call us up. We’ll take the money.

Narrative

When you buy a new car, its value drops the second you drive it off the lot. This isn’t just a cute saying: it’s reality. That formerly new vehicle is now identified as “pre-owned.” Its potential as a maintainable investment disappears. It’s now just a thing you’ll get rid of when it’s time to upgrade.

This is not true when purchasing a home. Again, in most cases, a home is an investment. Home values have increased beyond inflation every decade since before both of this book’s authors were born, and they show no sign of dipping. You don’t buy a house and watch its value drop. Instead, you begin the work of maintaining and improving the value of that home.

We have a habit of thinking our websites are cars. We drive them to their limit and make cursory repairs when we need to, but even if we diligently maintain them, following the manufacturer’s suggestions to the letter, they lose value and eventually need to be replaced. Some organizations make replacements every two or three years. Some switch every time the license is up. The sites are seen as disposable, which is the very antithesis of what we’ve been talking about throughout this book.

In a perfect situation, our websites are homes. We use this analogy all the time – but the truth is, just like in a home, basic and ongoing maintenance will help preserve its value, and well intentioned improvement should actually increase its value. It becomes a central meeting place for content, and as the organization matures, the site is able to mature along with it. When we do adjust design or move on to a new CMS, we’ve done work at a base level that will carry on into the future.

Of course, websites are not disposable, nor are they thirty-year investments. In reality, most websites land somewhere in between. Even with the best intentions, a website will begin to creak and groan under the weight of new additions and content changes, which means they do ultimately have a shelf life. But if we’re purposely planning and adjusting a site for the long haul, there’s little to think we can’t maintain a site for several years.

Let’s talk about what happens once that site launches and you’re heading into the future. When that site goes from a one-time project to an ongoing product.

Transitioning from Project to Product

Unless you are part of a larger organization with an internal web design and development department, you probably view your website as a project. You have engaged in a project timeline, you have worked with a project team, and once the site has launched you can say the project is complete. You started with no site (or an old, outdated site) and now you have a new one.

This is very excellent news. Congratulations, new site owner.

But you know what comes next. The launch of a new site is indeed the end of that particular project. But it is also the start of your new product.

Products are designed to solve problems. They are given value and attention, and they are given resources. Products are here to last, and they require constant improvement to stay competitive. Where throughout this book we’ve talked about building a site designed to accomplish certain organizational goals, we now adjust our strategy toward upkeep. There are two things about upkeep, though:

1. It does not happen for free. You need to create a budget and assign attention in order to keep things moving.
2. It does not happen on its own. You need to make sure the website is seen as a tool and process connected to overall organizational communication, not just another channel.

This is a drastic change in our mindset. We had a finish line, but that finish line was always temporary. You’ve finished the race, but you need to keep training for the next one.

Your Web Roadmap

When you’ve got a deadline, it’s easy – and often crucial – to create a minimum viable product,11Often referred to as an “MVP,” as in, “What’s the least we can deliver to get to an MVP?”Close or the bare minimum of a site acceptable for launch. The build of the site will go on forever, if allowed – websites, content, and organizational needs shift incrementally over time, no matter how much planning you put in, and there’s a time when your team just needs to say “this is what we’re launching with.”

While minimum viable products are okay for the initial launch, they typically do not address the entire scope of our communication goals – hence, the term “minimum viable.” They are enough, and while they can be celebrated, they cannot be rested upon. From the moment that minimum viable product is launched, you begin the longer road toward ongoing maintenance.

Of course, just as you can’t create everything at once when the site is a new project, you also can’t suddenly get everything done at once when it’s an ongoing product. You need a roadmap to help you plan, prioritize, and budget for ongoing and future adjustments and additions.

Depending on where your site is when it goes live, you may have different levels of future adjustments and additions:

• Backlog Work: The stuff that didn’t get finished before launch. Small bugs, issues with real content, etc.
• Crucial “Phase Two” Work: Often technology-focused, these are crucial features that were saved for post-launch in order to reach a minimum viable product.
• “Future Phase” Enhancements: Also often technology-focused, future phase enhancements are known additions and improvements scheduled for further down the line. They are often, on their own, entire web projects – additions of a digital asset management (DAM) system, or implementation of a customer relationship management (CRM) service.
• Content Maintenance: The purpose, relevancy, and accuracy of your content constantly shifts and changes, and that doesn’t stop at launch.
• Organizational Maintenance and Change: Despite your planning, you’ll never achieve fully efficient governance at launch. People take time to change, and your new site is a major change.
• New Technical Requirements: A new site may also bring new technological needs, some of which you never had to worry about before.

There’s a lot still to figure out after launch, even if you have meticulously planned beforehand. Prioritization is key, lest your team give up before they’ve had a chance to grow.

Prioritizing Post-Launch

Ultimately, you should treat your new site the same way you would a company budget or employee reviews: annually setting goals, and periodically checking in on progress toward those goals.

This is crucial, because your site doesn’t automatically update or notify you of concerns. You have to make decisions from here on out. Every week your site is live, you’ll notice something you want to change. Maybe you’ll want to adjust a section of content, but need to wait for your writer to free up some time. Or you’ll want to adjust some colors. You might find a dormant bug, or something that’s broken now that you’ve upgraded to a new version of your CMS.

Your issues list will vary wildly as these changes sprout up; you will have things as small as updating a line of text in the site editor, to things as large as installing and training your team on a new digital asset management system. In order to prioritize you’ll need to ask about:

• Audience and Outcomes: Will this solve a major problem for top-tier audiences, or is this a periphery issue for tertiary site users?
• Time: Can this be done quickly, or will it take a long time?
• Capacity: Can this be handled now, or is the person/group responsible for it busy for a while?
• Dependencies: Can this be done by a single person, or does a larger team need to work together?
• Complexity: Is this a basic issue that simply needs priority, or is this a complex issue that requires a larger plan?
• Skill: Can this be handled within someone’s existing skillset, or do we need to hire someone to help?

We don’t explicitly talk about budget, because budget is implied when it comes to complexity and skill – the more complex and the higher level of skill required to bring in, the more something will cost.

Your issues list is going to bring a sudden sense of anxiety. Seeing all of your to-dos in one place can be frightening. Knowing that you can’t take on everything at once, you’ll need to begin balancing quick wins with top audience needs.

Annual and Quarterly Planning

What we’ve often suggested is treating the website as you would any other quarterly initiative. Leaning heavily on your web steering committee and scheduling strategic web planning sessions every year, with check-ins every quarter.

From here, split up your tasks into long-term projects and easy wins. If you’re working with an existing vendor or an in-house team, long-term projects are schedulable, require budget or time, and may require several different people from different teams. On the other hand, your easy wins are things that just need to be prioritized and done – an automated update to a plugin, or getting information for a new page, or getting some information from your analytics.

This is your web maintenance roadmap. For this quarter, you have your marching orders, and you can see what goals are needed for the upcoming year. Every quarter, you’re going to revisit what you did, what you couldn’t do, and where those longer-term goals are sitting, until you reach a year and you kind of reset.

This planning helps shape the future of the site. But what does that future look like? Ultimately, when we talk about maintenance and improvement, we are talking about three key areas of your site:

• The Content: Auditing, maintaining, and updating content on the site to help keep things as up to date as possible.
• The People: Ongoing training and continuing education to help maintain and build upon governance of the site.
• The Site Itself: Adjustments to design and development to serve new audiences, new business lines, or new technology.

The Content: Maintaining and Creating Content That Works

Maintenance of content is, in reality, a full-time job – in fact, it’s often multiple full-time jobs, which is why so many successful organizations have a full team of writers, web operations specialists, and content analytics simply maintaining communication between your organization and your customers.

While a large chunk of this maintenance is simply writing – specifically, creating new content for the website – there are a handful of tools and techniques that have become dedicated standard practice around content creation and maintenance.

Rolling Content Audits

Knowing the status of every page on your site might feel like a bit of an overwhelming project, but the weight of outdated content – how it muddles up search results, provides misinformation, and complicated deeper-level navigation – can be even more harmful.

We already talked about content audits in Chapter 7: Know Your Content, but we’re taking that one step further here; while that chapter focused on what content you have, this chapter is focused on ongoing maintenance. The goals are the same: looking for and rooting out ROT (redundant, outdated, trivial) content, except that “looking and rooting” is a part of a constant process, rather than a one-time task.

Instead of tackling the entire content audit all at once – which requires a level of focus that most people won’t have as a part of their day-to-day responsibilities – the rolling content audit breaks a content audit into small pieces, theoretically rolling it out over time.

Let’s use a university as an example. The typical university marketing team team has serious time restrictions – both in the amount of time they can spend on things and in the time frame they can work. Course catalogs, recruitment season, on-site registrations – these things take up time, and push back the ability to focus deeply on something like a quarterly or annual content audit.

So, instead, we break the job into smaller pieces:

• Prioritize Content: The university communications team can refer to analytics data to determine which pages get the most traffic, and make sure these pages (and the sections they belong to) are a top focus.
• Delegate and Distribute: Content from the course catalog can be checked by the communications team, sure, but it’s already being edited and maintained by admissions, so let’s keep them in charge of auditing site content.
• Break Into Pieces: Instead of slogging through the entire site, the team should tackle one section per month, or even more staggered if the schedule requires If the university team knows there’s a big communications push just before each semester, they can keep those months free from auditing; likewise, in the slower summer months, put a little more attention on a larger chunk of content.

The idea of a “rolling” content audit is just that: you never end the audit. You just continue to roll through content over and over again. And while you may be constantly auditing, you’re still only hitting each page once every several months (or even years for less important content), thus keeping it a more manageable exercise.

Editorial Calendars and Triggers

But what about new content? While some sites rely on content that’s tied to products and services – content created as needed and updated only when those products and services are updated – others base their output on ongoing updates, such as blog posts, white papers, and other sharable and searchable content.

The most effective way to organize content publishing is through some kind of editorial calendar, in which your content is scheduled in advance and tracked for the future. Editorial calendars can be detailed and complex, or they might just be a spreadsheet on your computer with a few months’ worth of ideas. Regardless, they will help you schedule and organize any number of editorial content needs, such as:

• Frequency: How often are you posting content?
• Topic: What are you writing about?
• Purpose: What are we trying to accomplish with this content?
• Format: Is this an article, or a white paper, or a product testimonial?
• Related Assets: Does this new content relate to any existing content?
• Topic Categories and Keywords: What main organizational concepts does this content cover?
• Important Dates: How does this content fit in with industry or organizational events or trends?
• Author: In a multi-author environment, who will be writing this content? 
• Editorial Deadlines: When is this content due? 
• Current Status: If being used as a workflow tracking tool, what status does this content current hold? In process, ready for edit, or ready for publication?
• Call to Action: Is this content directly tied to a specific call to action? 
• Social Media Channels: How will we move this across different channels?

That’s a lot, but your results may vary. What’s important to keep in mind is that an editorial calendar is only useful if it ties to your organization’s workflow and content needs. You can download dozens of different editorial calendar worksheets, but they may not fit with your team’s design or publishing cadence. In fact, not every site can benefit from an editorial calendar, and smaller sites (or sites that deal with constant change fueled by outside sources) fall victim to a kind of “over-planning” syndrome, in which the organization of the content is more restricting and time-consuming than just writing when it’s time to write.

What’s more, you don’t always get to plan. For those situations when you are writing reactively, you can turn to editorial triggers, which are a kind of recipe for quickly and efficiently publishing “right now” content on your site. An editorial trigger takes key points from above – author, editorial deadlines, format, etc. – and removes the concept of a date.

Instead, editorial triggers are tied to immediate actionable workflow – knowing who will handle each part and when they will handle it. Rather than saying, “This will publish on March 13th,” we are now saying, “This will publish five days from completion of a new product, and these are the timeframes we will work within.” It outlines the approval process, image needs, and content types – essentially, everything you need to quickly get a piece of content up. An example might look like this:

NEW PRODUCT CONTENT:

In short, if you need to organize a bunch of content for the future, you might use a calendar. If you need to build a process for timely creation of non-scheduled content, such as posting a new product, you might use an editorial trigger. You might need both. You might need neither. But now you know what to do in either case.

Styles and Branding

When we talk about styles and branding, we’re really talking about style guides and brand standards.

• Style Guides: Expectations and guidelines around language, including accepted spellings, industry terms, written voice and tone, and approved brand verbiage.
• Brand Standards: Expectations and guidelines around visual elements, including brand colors, logo treatment, fonts, headings, images, and the context therein.

Some style and branding standards line up with the legal trappings of your digital policy, such as accepted use of trademarks, writing and designing for accessibility, and providing clear notification of data collection from A/B testing or analytics work.

On the other hand, style and branding is more likely to be tied to maintaining voice, tone, brand colors, and logo treatments. In this sense, style and branding define how something should be created, rather than what can and cannot be done.

Style guides and brand standards are, by nature, unique, because they tie directly to an organization’s identity. At their most simple, writing style guides are built upon a more standard style guide – The Yahoo! Style Guide, or the Associated Press Stylebook – with additional organization- and industry-specific terms added on top. Brand and design standards for the web are built upon the organization’s brand and design standards – logo treatment, fonts, colors – and adapted to include digital image guidelines and sizes, CMS recipes22A CMS recipe is a type of documentation that outlines step-by-step the pages, blocks, and fields needed to create a specific template within your content management system.Close for creating on-brand templates, and acceptable use of headings.

Content Measurement, Focus, and Improvement

When we install a content management system, there’s a good chance we’ve also installed some fun tools. We’re equipped to collect complex data, or to A/B test our home page design, or personalize content down to the user. And because we’ve paid for and sometimes used these features to sell the idea of a new CMS to the corporate suite, we’re eager to start using them.

And you should. But within reason, and within the scope of your existing workflow.

In most cases, getting to know and understand the new site – and sometimes the CMS itself – is a significant enough culture change to warrant growing pains. Your editorial team, your writers, your leadership – they’re all figuring out how the new system works within the larger scope of communications. Adding new processes like maintaining analytics data and managing complex personalization will add an extra – and unneeded – level of stress.

You will get there, but let the site ease in a bit before you go all out. Here are some of the things you might start working on once you’ve settled into the site:

• Content Measurement: Referring back to Chapter 8: Gather Insight From Your Metrics, and with a solid understanding of what your organization needs to be successful, you pair business needs with data from your site users to help drive them toward their needs – and your messaging.
• A/B Testing: Once you’ve established a baseline, you can start making tweaks here and there and measuring their success through A/B testing.
• Content and Usability Testing: Testing goes beyond the CMS – it also means reaching out to actual humans and seeing how they interpret, travel through, and connect with your site and its content.
• Personalization: Finally, you’ll get to use all those cool tools that are built into your content management system. Understand that the fussier and more focused your personalization efforts are, the more effort (and larger risk of failure) you build. Start with some general personalization buckets – say, anyone arriving from Monster.com gets a banner leading them directly to the jobs section of the site – and dive deeper only when necessary.

Additionally, reach out for consistent feedback from your customer experience (CX) group, if you have one, especially as it relates to web content and navigation. A quarterly feedback cycle should begin at the very least, with a monthly or bi-weekly one set up for CX-related content projects.

The Site Itself: Adjustments to Your Big Investment

While content is king, the site itself is the vessel the content travels in. Passengers on a ship are clearly “the point,” but the ship itself is “the thing that keeps everyone from drowning,” so you need to keep it in good working order.

Maintaining the Implementation

Let’s say the mechanics of your site never change, meaning the functionality and implementation you launched with should still work in largely the same way ten years later. You intend to change nothing.

It’s still not realistic to think you’ll never have to do anything to ensure this happens. Unless your website is a self-contained technical bubble, with no external dependencies, and it uses the lowest-level technical requirements possible – meaning, it’s statically generated HTML running on the most stripped-down web server – then you’re going to have to look after it.

Content Adaptation

Here are some examples of situations where content might cause your website to change the way it functions, even though no code has changed.

• Content Edge Cases: Your editors might publish a content format you didn’t expect and didn’t account for. What happens when the body of an article is just one image? If the search indexer doesn’t find any text, perhaps it won’t index the article at all. If not, you might not know about it until someone calls you and says, “I can’t find my article in search.”
• Unplanned Content Needs: Sometimes, you don’t have a one-off edge case, but rather a genuine, continuing content need that wasn’t foreseen. What if an editor wants to publish 100 pages in sequence, like chapters in a book? At the bottom of every page, there should be next/prev links so the user can navigate through the content. It would be nice if it would respond to swipe gestures on mobile, too. This is a sincere need, and you can see the value, but you didn’t account for it.
• Rogue Editors: If your editors don’t like how your CMS works, they might “go rogue” and try to force the CMS to fit what they want it to do. An editor who doesn’t like the bullet style in the CSS might decide to upload their own image and use it at the front of every line. This is fine, until the text starts to wrap weirdly on mobile screens and someone notices. “Whitespace hacking” is common too – editors don’t like how some text flows, so they insert a bunch of “hard” line breaks to make it work the way they want. While it’s tempting to just admonish editors and move on, you may want to investigate why the editor felt the need to do that – do they have a genuine need that can be accommodated?

In each of these cases, the container – meaning, the website – has not changed. What changed was content that caused the container to react in ways you didn’t expect. Nothing has “changed,” but things still changed.

Sometimes you evaluate a situation and realize you just didn’t plan for it. It’s not a one off, but a genuine repeatable issue. In these situations, you need to evaluate whether the issue warrants deeper technical work.

CMS Upgrades

If you’re using a packaged CMS – which you are, unless you built your own – then you need to account for the fact that software will change over time. The organization behind the software, be it an open source community or a commercial vendor, will make changes to that software, both to fix functional bugs and security problems and to add new features.

New versions of software are usually packaged into what are called releases. Most vendors will have a published release schedule, which is a defined interval in which they bundle up new changes and release them as a new packaged version of the software.

Most vendors will try to remain on this release schedule, with the exception of hotfixes, which are changes to the software deemed so important that they cannot wait for a scheduled release cycle. These hotfix changes are usually always security related, as an unpatched security issue in the wild can be disastrous, especially when the vendor has a large installed customer base.

These problems have to be resolved before they cause widespread problems across the web33For example, WordPress powers almost one-quarter of the world’s websites. A gaping security hole in WordPress might allow someone to take control of an entire web server, which means a huge portion of the computers that form the fabric of the web itself could be at risk.Close.

Each time a new version of your software is released, you need to review the release notes to determine what changed and whether or not it makes sense for you to upgrade your installation of the software. Sometimes new releases offer critical functionality or fix bugs that are causing you problems, but sometimes you’ve never encountered the bug that was fixed and the new features just aren’t worth the trouble.

Keep in mind that upgrades aren’t free, even if the software vendor doesn’t charge for them. If you have an installed version of the software – regardless of where it’s hosted – it will usually take developer effort to install a new upgrade. A developer will need to download the new code or libraries from the vendor, install them into a development environment, then perform a full scale regression test to ensure that everything that was built during the original implementation still works.

Occasionally, you might find that a new version of your software breaks some critical aspect of your implementation that you cannot live without. You might need to find a new way to accomplish whatever it was you needed. Other times you might find a feature of the software you enjoyed has been removed, and you need to determine whether or not you can live without it. These situations are known as “breaking changes,” and they’re the bane of working with packaged software.

Vendors are normally very communicative about breaking changes. In the release notes for a new version, they’ll specifically call out changes that might cause existing implementations to have problems. Additionally, good vendors will provide long lead times for them – they’ll notify you months in advance that a breaking change is coming, and give you ample time to “vaccinate” your implementation against those changes by removing or changing code that might break.

Unfortunately, software upgrades tend to be cumulative. If you have a problem with a Release X of the software, you can’t just skip that version and install Release Y, because the next one will either assume you installed Release X, or it will go ahead and retroactively install Release X for you.

Sure, you can choose to never upgrade your software, but remember that it’s running on a “stack” of technologies – a web server, database server, and operating system – and it’s into a large paradigm of the web itself. Occasionally, an underlying technology in the stack will change, or perhaps the protocols of the web might change in such a way that the CMS needs to change as well.

In short, the only CMS that never needs to change is one that never interacts with the world around it. This would be a rare and likely useless thing.

Maintaining Integrations

Integrations introduce complications. Whenever you connect your CMS to another system, you bind the systems together so that the functionality provided by that combination will sink or swim as a team.

Back in Chapter 14: Know Your Integrations we discussed the concept of “runtime risk,” which is the risk that the two systems will have problems interacting after their initial development and launch. Besides simple network connectivity issues, the systems communicate via a “protocol” which is agreement on how they intend to share information.

These protocols can change over time. One system or another can change its architecture to require new information, or it may release new functionality, or a limited functionality that exists.

How an integration is architected has an enormous effect on how stable it is over time. The riskiest integrations are ones that require real-time connectivity. In these situations, a human makes a request of your website which then turns around and makes a request to the integrated system. Your website has to wait for the external request to respond, which means the human has to wait for both your website and the external integration to respond.

It’s not uncommon to find situations where your website is perfectly fine, but the external system has a problem, or the external system is fine but the communication between the two systems has a problem. As we said before, whenever you connect your CMS to another system you open up an entirely new category of problems.

Besides upgrade issues, persistent downtime or support issues will cause you to rework some integrations over time. And, unfortunately, sometimes you’ll find that an integration with a particular external system is consistently unstable, and you’ll need to back up and rethink whether it’s worth the risk at all.

The People: Training and Improvement Planning

If there’s been any recurring theme throughout this book, it’s that the web process isn’t run by design trends or search engines or content management systems – it’s run by people. Which means the best thing you can do to maintain your new web product is to back it with good people empowered to learn great things.

We talked about some of this in Chapter 23: Plan for Post-Launch Operations – to maintain a healthy site, someone needs to be in charge of the things that matter, and accountable for the things that don’t. This means keeping ahead of trends, understanding the tools we’re given, and having the power to make change when change is needed – and to know when staying put is good enough.

Understanding Our New Tools

Understanding our site – whether it’s the content management system, the integrations we rely on for external data, or the tools we use to maintain editorial process – seems a bit too obvious. But think back to other situations in which you purchase an expensive tool. When you bought your last refrigerator, did someone grill you on whether you know how to adjust the temperature? When you bought a car, did someone painstakingly teach you how to adjust the mirrors and set the cruise control?

Yet, in the case of a website, there’s a difference between being trained on a tool and understanding the tool, and this is the line in which a successful site can often be drawn. Understanding your content management system doesn’t just mean knowing the five steps to create a blog post – it means understanding why those steps matter.

This takes training – real training, not just a show-and-tell of CMS functions – and it takes real documentation. Because when it comes time to train someone else two years down the line, you want to still know the why behind certain settings and fields … otherwise, they’re quickly overlooked and deemed unnecessary.

Understanding the Industry

In order to understand those tools, we often need to have a better idea of the industry itself. Which means we need to actively train ourselves and our team to be fully aware of the areas in which we work. The person in charge of editing content should know, at minimum:

• Why it matters to include proper META information.
• How to create content in a way that is easily readable and accessible.
• How often to review content and why it’s important.
• What metrics matter and how they tie to business goals.

It’s okay if they (or you) don’t know this when they (or you) start. Please repeat after me: It’s okay to still have things to learn.

There’s a wide and varied set of books, conferences, webinars, and even local groups and resources that will help you and your team keep up to date on what’s happening in the world of the World Wide Web, and while sometimes it might seem overwhelming and it will often feel as though you’re way behind the curve, know that, no matter what, you must keep learning.

Training should focus in two directions:

1. Enhancing current skills
2. Exposing new trends and content needs

Because your team might be small, remember that promoting a generalist agenda can be beneficial. Most teams can’t hire a dedicated content analyst or information architect, let alone a hyper-specialized expert. All members of your team will need to fold in new trends, create redundancies, and simply be ready to learn more.

Understanding Momentum

Finally, know that people are driven by example. They will follow momentum. They will work hard on things that they know are worth the time; things that are actively promoted, given attention, and encouraged to be improved. Momentum means more than just keeping a full backlog of potential fixes. As we’ve mentioned before, the business value of a website is directly tied to what you do with it and how you improve it over time.

• Constantly communicate the value of the site itself and why it’s important. Explain the goals and help people get invested.
• Ask people to help out where they can. This does not mean providing every frontline employee with a login. It does mean making sure the right people are consulted on the part of the site they care about.
• Keep people up to date on new items on the website. You don’t have to promote every item, but be clear about when new sections or major changes come through. Show that the site is important and active.
• Make sure outdated content is relatively undiscoverable or archived. Nothing says “Oh, we don’t really care about this anymore!” than stumbling across some piece of content that’s been outdated for three years.

More than anything, make sure the site isn’t just a thing you use to post new promotional banners.

You’ve gotten so far. You’ve built this site as an extension of your mission; your vision for how your organization will communicate into the future. You’ve sweated the details in meetings, with committees, through deadlines; you’ve gotten into fights, you’ve maybe come to tears, you’ve stayed up late wondering if each decision is the right one. You’ve scoured vendor requirements. You’ve argued over which title to keep, which page to keep, which function to keep. You’ve written and rewritten and deleted thousands of words, and you’ve tweaked and re-tweaked and then returned to some design element. You have spent weeks (months!) waiting and working and negotiating and bringing everyone together to make one final push for this site to become a reality. For this site to become real.

You’ve taken a break for a few days. You’ve celebrated a launch. You’ve doled out some tasks. And now it’s time to get back to work.

Now’s not the time to stop that momentum. Instead, it’s time to use that momentum to keep going. Strong. Always changing. Into the future with your new web product.

Inputs and Outputs

This seems obvious, but the input is everything you’ve learned and handled in the previous twenty-three chapters. It’s the mission and purpose of the site. It’s the team you’ve brought together to handle content updates, development changes, and design improvements. It’s the content itself, as well as the cadence of that content. It’s people and machines and words and literally everything we’ve talked about.

And the output? A site that continues providing business value for a long time.

The Big Picture

By definition, maintenance of the site happens after the site has launched.

Staffing

We talk about the team you might hire in the governance chapter – you’ll want someone who can manage both the content and the people who write and edit the content, you’re going to want those writers and editors, and you’ll probably need someone to help track and analyze how users travel around the site and accomplish their needs. You’ll want a design and development team, too – internal or external, depending on your organizational makeup.

Resources

Books

• The Content Strategy Toolkit by Meghan Casey
• The Web Content Strategist’s Bible by Richard Sheffeld
• Content Strategy At Work by Margot Bloomstein
• Content Strategy for the Web by Kristina Halvorson and Melissa Rach
• The Digital Crown by Ahava Liebtag