Ongoing Digital Presence Change: Eight Principles

From launch tunnel vision to constant change

As an industry we focus way too much on big launches and redesigns. I'm certainly not new in saying that, and in fact in some ways it is almost cliché to note this. But I would like to go beyond that to both define some principles of constant change and how to do stay focused during change.

First let's look at why we want to move away from tunnel vision on launches, and other ways of thinking about change on websites. Note: even when we do need to make big changes (like replatforming), we can't just focus on the launch. 

Standard thinking: focus on launches

Look at it sparkle!

Most web teams focus on launches as the major events to be applauded and promoted. After all, often websites get so bad over several years of relative neglect (since the last major change) that teams are desperate to make changes, and when the funding finally arrives it seems like a dream come true. Also, the scope of work is often structured with the launch as the major deliverable. That said, the major advantage of this approach is that it is so concrete: is the new site up with the new look and new features or not?

The most basic problem with tunnel vision on launches is that it overlooks (or at least downplays) maintenance and optimization. 

Better approach: focus on post-launch

Keep polishing!

An improvement in approach is to at least put attention on the the day after launch. Some terms that capture a focus on post-launch include Day 2 (Jeff Cram, Jeff MacIntyre, and Lou Rosenfeld gave a presentation on Day 2 at a J. Boye conference a few years ago) and Now What? (the team at Blend Interactive now host a conference titled "Now What?"). Looking at Day 2 and beyond is a significant improvement (and one that many teams ignore): instead of immediate decay on the site, teams can make sure they are lined up to manage, maintain, and optimize post-launch.

The biggest issue with focusing on the threshold between pre-launch and post-launch is that it remains a fairly static view. For example, we may be tempted to think that launch-like changes (such as new tools, new functionality, new templates, and new content types) happen pre-launch and other changes (like content publishing and tweaks to calls-to-action) are those that are dealt with post-launch. Moreover, it assumes a fairly static planning approach: even if we are agile during development leading up to launch (for instance in implementing the content publishing flow), if we don't continue that process post-launch then we are not being very dynamic (since we may want to frequently tweak that publishing process). In fact, agile may be more useful for ongoing product management than in development. Related, by focusing on the launch we may be thinking in terms of how it looks or functions on the surface, and not whether the underlying structures (allowing future change for example) are right.

Even better approach: constant change

Stay focused over the long term

An even better approach is to fully face the fact that our website should always change, and not just on the surface. Lou Rosenfeld laid out some ways of setting up for ongoing change in Redesign Must Die: prioritize, tune, and be opportunistic. Although I feel strongly that there are a variety of reasons that we cannot completely slay redesigns (but we should try to extend the gap between them), we need to move the focus to the continual improvement of our digital presences. 

So Day 2 is in many ways just another day in the life of a web presence. Remember I'm a migration guy, so I fully appreciate that there are steps to pulling the actual launch off, and I've got checklists for down-to-the-minute coordination on launches. But launching a site is just one type of change. New content was being developed before, during, and after launch. Bug fixes are being prioritized. Even if you are launching the whole presence at once, you should be phasing in functionality over time. So at the initial launch you are already scheming on next steps. But perhaps the most dangerous aspect of Day 2 is the assumption that you'll just need to clean things up after launch, and not that the ongoing operation was a crucial aspect of the launch (so those management capabilities are more important than the bells and whistles at launch).

This is a better approach since it better allows us to respond to many types of change.

Constant change: the eight principles

I propose the following principles of constant change:

#1. We are never done

Launches in particular are fleeting events.

None of us know what is in store for our industry in the future. Or even our company. Furthermore, we don't even know whether our most informed improvements rolling out this week (or massive revamp in a couple months) will satisfy our website visitors. So we need to be prepared to always make changes to our website.

#2. There are many types of change

Launches are just one type of change.

There are many types of change — to name a few: content, functionality, distribution channels and formats, taxonomy, new site sections, navigation changes, branding changes, new types of sites, new backend users, strategy changes, and organizations changes to name a few. And of course site launches. None of these types of changes should surprise us, and by clearly seeing the patterns in these different types of requests you can better respond to change.

#3. Routine change first

Common activities like content publishing should be easy (when minimum standards are met).

One of the reasons to figure out what types of change your site needs is better triage those changes that should happen quickly and those that should be slowed down for more consideration. Too often common activities like content publishing are onerous or not seriously considered from the start (for instance during CMS selection and then implementation). Of course, you need to ensure basic standards (unique for each type of change) are met so that you don't wind up streamlining junky changes.

#4. Amplify

Prioritize highly leveraged changes for highest impact.

The lowest impact change is one that: a) is for a single page, b) for a single point in time, and c) that doesn't even achieve organizational goals for that one page. Attempt to amplify each of these dimensions: a) for lots of pages (for instance, changing the template rather than one-off changes), b) change the underlying machinery (for instance, changing the publishing process to foster high quality so that going forward things are improved), and c) concentrate on the "why" of your changes to ensure they meet organizational goals. 

#5. Dynamic over static view of websites

Wireframes and mockups are important, but underlying structures are even more important.

Our websites aren't pretty little model ships in bottles. But that's the way we often think about them. We obsess over mockups, when it's clear that the organization can't possibly publish the content frequently enough on an ongoing basis to remain high quality. Even more important though is that it isn't about the static view of a website. The point isn't that on launch the page looks a specific way. It's more critical that the site is built in a way that can appropriately change over time.

#6. Dynamic over static planning

Change should be regular, but the details should not be planned far in advance.

Sure, we are in the age of agile everything. But agile in a launch-then-day-2 mentality is still very launch-focused and not one where constant change is at the center. The point is that there should always be planned improvements, say every three months. Although only the next three months are being planned at any one time, everyone knows the schedule of consideration for the following three months (for example, the requests are all due the 15th of the first month in the cycle, so even if in the middle of a cycle where that deadline was missed you know when the next one is coming).

#7. Limit one-offs that make future change difficult

Broad change is more impressive than shiny one-offs.

Can we please stop applauding one-offs? Just because MegaHugeCorp uses YourFavoriteCMS for one blog doesn't mean they are endorsing the product or committing to deeply using it. If you launch a microsite that looks beautiful but then is never updated so it looks horrible a year later then that's not a win.

The main problem of one-offs is they make future change difficult. Of course, if when you launch a one-off with a very specific and limited lifespan then there is little problem. But often what is expedient in the short term makes things difficult in the long term (like custom HTML for a page that then makes it difficult to make all pages across your web presence consistent in the future). Cheer for the changes that are truly broad, for instance those where a large swath of your web presence "wins" by making (for instance, a feature that all pages can use).

#8. Phase over big bangs

Not only are Big Bangs risky, but they limit our ability to respond to changing conditions.

For very large web presences with many websites, changes (for instance to a new platform) should be phased in across the sites (so for example, first perhaps product sites are rolled out, then country sites are rolled out, etc.) That said, phasing should occur on a smaller scale as well. For instance, if you are rolling out new functionality then it's probably better to start off with a small move toward the full functionality you want — then you can respond to how well the initial change works in order to change course as needed. 

Note that not having Big Bangs is not sufficient to meet all the principles above.