We all should know better, but we want the easy way out. In many ways, we think of our website something like a model ship hermetically sealed in a bottle:
We fixate on beautiful mockups that show exactly what we've always dreamed our site could be. But we don't think about how thse pretty web pages could be maintained. For instance, when thinking a bit deeper about a mockup, we may realize we don't have enough resources to sustain them (for instance, with tons of topic pages).
We focus on the launch of a website, looking at how clean and perfect the site is on launch day, rather than the long term needs.
We are much more likely to launch one-off sites (that can be pristine) rather than looking enterprise-wide at our needs.
Our website isn't hermetically sealed in a bottle at all. It needs to be seaworthy, ready to be steered into the exciting sea. We don't know exactly what is in store, but we know we need a crew and a design that meets the type of sailing we will be doing (it probably needs to be pretty sleek). In early planning, we just plain don't know what's in store, although we are probably very tempted to put together a detailed plan.
I recommend developing a master plan, which is anchored by (and confirms) a clear and focused vision of what you are attempting to accomplish. The master plan isn't written in stone, but one that will steer you going forward. In particular, it considers the long term success in two ways: 1) looking at all disciplines required for site success and 2) phases in changes over time rather than attempting a big bang.
Often we get a bit too hung up on whatever our job description says, thinking that our particular discipline is the most important. But they all need to work together, sometimes one discipline being more important than another to achieve a particular vision, but overall we need to make sure they are all covered. For example, why do we so frequently create sites that can't be maintained over the long term? Many of the disciplines to consider are in the circle chart above, but organizations usually have a bias. For instance, some teams might be heavily technology-focused and others focused on the content strategy. In a master plan, just enough of each discipline needs to be defined in order to confirm the vision. Let's say the vision involves better flowing of content between subsites. Clearly the technology needs to support this, but then there are also immediately taxonomy / integration questions as well (how complex should the taxonomy be?). In addition, there are content strategy concerns about who will be creating this content that will flow between subsites (that now may be managed by silo) and will it be possible to create enough content. What processes and governance will be in place to ensure that the silos don't return? In the master plan, none of these could be completely defined, but in very early planning we need to look at all aspects to see if our vision is possible. For example, we may decide that in the near term the taxonomy will be very simple, without actually defining the taxonomy during the master planning.
Which leads us to phasing. This is also crucial, and helps us avoid reverting to our natural tendencies to concentrate on one aspect of planning or another. There are three types of phasing:
Phasing toward the site vision. We may have a broad vision for our website, but we can only do so much at a time. For example, if your vision is to personalize the content on your site, then a first phase may be to simply create the content that all the audiences want! This is required before fancy rules need to be defined, so concentrating on that first is important.
Constantly phasing functionality over time. At a small scale, our web presence needs to constantly improve. The site needs to be managed as a product.
Phasing the subsites. If you have a lot of subsites, then they should be phased in as well, preferably similar sites coordinating together for higher quality.
The master plan should look broadly at how the phasing will work, with some initial stabs at what will be phased in what order. All disciplines should be considered, in order to confirm the vision (and refine it as needed). Then as phases move forward, define the details for each discipline in more detail.
David Hobbs Consulting develops master plans. Contact us.
Have fantasies of starting your website from scratch? I think we all do. For all the complaints that other people have about our websites, we know about an even larger set of problems. Especially for older sites with distributed content entry, you probably have a lot of low quality content. So what are some reasons we might want to think about just starting afresh with our content?
Focus on what is important
For the content you do need, you can spend time on getting it right
Drop low quality information
Lower maintenance costs
The fantasy goes something like: 1) Nuke the current site and then 2) build a new site from scratch. The problem is that, aside from small sites, this fantasy could never match reality. Don't get me wrong: dropping non-performing content should always be a priority. That said, here are some reasons the fantasy of starting from scratch doesn't work:
Your website probably has at least pockets of high quality information (your site probably isn't complete junk!).
Site visitors often do need to eventually get to details (providing context and focusing the experience is important, but at some point the visitor may need to get those product specs).
You may have source or definitive materials (for example reference data, original research, and technical product information).
Your business may cover a lot of ground, so rewriting key information for all of your business may need to be phased in.
It takes a lot of effort to write high quality content.
That last bullet probably sets off some alarm bells in your head, so let's talk more about that. I firmly believe that organizations should focus on what is important, and not just what is easy. But you can't built a house overnight. If you start from scratch, then you need time. If you have the time, then great. But usually time and resources (and the site complexity) don't allow a total nuke of content.
You can meet the goals listed above (focus, get it right, drop low quality, lower maintenance costs) with a hybrid approach:
Discuss what content is required to attain that vision + conceptually how the site needs to be organized.
Define rules for what existing content has to be completely rewritten, dropped, or other moved as-is (you may also look at other dispositions such as leaving the content where it is) + what brand new content is needed (to meet that vision).
Some of those rules will mean that you don't need to analyze some content for more -- for instance, you may decide to drop entire microsites that were created over time. For the content that does need to be analyzed more, create an inventory that you can then apply the rules above to (consider multiple sources of information).
Write the required new content + other rewrites / moves / modifications as defined.
Apply those rules on an ongoing basis (for instance, define a lifetime for microsites and regularly decommission them on that schedule).
In this way, we address those problems with a completely from-scratch approach, for instance by moving over the high quality information that does exist, with the added benefit of keeping the information high quality over time. Also, we don't wind up with an overly-ambitious plan that we cannot execute on.
With this process you still may drop a dramatic amount of content. But, although we might like to, starting purely from scratch probably doesn't make sense for any but small sites.
Submitted by David Hobbs on 10 June 2013 - 12:12pm
When considering big website changes, you have very powerful control knobs at your disposal. Instead of battening down the hatches and blindly going forward with your website redesign or replatforming project, first consider these major controls you have:
At its simplest, your website has a certain number of pages. How many of those pages contribute value to your site visitor? When making big changes, you have the chance to better focus your website, potentially dramatically reducing the size of your site. Depending on how deeply you will be modifying the content, you also will need to spend some time handling content during a migration. If that is the case, then the more content you have then the more effort you will expend on your website changes. Really the weight of your site is more than page counts, and includes other areas of complexity like the number of backend systems you integrate with. As with content counts, these other aspects are a weight that you may need to transform or recreate when changing your website.
The amount of change needs to be carefully considered when planning big improvements to your site. Remember the point here is the distance from where you are now to where you want to go. In other words, this is not on some absolute scale but relative to your starting point (what you have right now). If you already have a large technical team implementing cutting edge functionality, then going even further may not be a stretch. But if your team is currently having a hard time keeping up with weekly content updates, then adding some even simple collaboration for external users may be unsustainable.
For weight and distance, consider a graph showing your current weight (in this graph called labeled as complexity) and distance:
In this example, you are starting with a heavy (complex) site, and are also trying to make big changes to that already-complicated site. Ideally you want to try to keep your efforts down as far in the lower left of the graph as possible. Sometimes you just can't do that, but in general the goal should be moving to a simpler site and not trying to change everything at once. Use this tool to start seeing where you are on the complexity / distance graph.
Usually organizations end up backing into a certain quality level, and what this often means is that the quality suffers. I often frequently been in conversations where the technical team says something black and white about what is possible from a quality perspective, when in fact the content owners just need to understand the trade-offs in deciding upon quality levels. But there are always tradeoffs in quality. The biggest problem occurs when no one even talks about quality expectations, and only when people see the resulting site do they realize the mismatch in expectations.
How to use the knobs
The first step is to simply consider weight, distance, and quality. The next is to tweak each of these in order to come up with a manageable plan. One effective way to control these knobs is in phasing, where you start by implementing the aspects that most move you toward your vision. For example, you may start by using your current taxonomy, and then over time make it more nuanced. An advantage of phasing to control the distance is that you are then preparing everyone for ongoing quality changes to your site (immediately everyone is thinking in terms of phases). Note that all the knobs are related. For example, reducing the weight means that you have more time to make the remaining quality high quality. Similarly, if you decide on higher quality then that may drive you to attempt to make fewer changes (distance) to the site.
Submitted by David Hobbs on 10 June 2013 - 11:10am
I'm usually involved with organizations quite early in their planning process for large website changes. Often the changes being discussed are clearly not possible to implement, or at least to sustain after they are implemented. Here are some ways to see if your plans are flat out laughable.
Laugh test one: Have you defined your project goals?
Sometimes it seems that teams are trying to define how to get there, but before they know where "there" is. This can be a difficult balance since you can go way too far the other way too by defining where you want to go in exhaustive detail (which also leads to problems with the second laugh test below). But fundamentally you need to determine what the goals are. How will you know you will achieve them? How are you going to approach how deeply you will support your goals now vs. the longer term? See more on defining a vision.
Laugh test two: At a high level do you know how you'll pull this off?
There's often a scapegoat as to why the website isn't working now. Complaining about the CMS is fun for example. But usually the problems are more complex, and just swapping out the CMS may lead you right back to where you are now. Try to dig into why your current site isn't working in order to avoid the same problems from happening again after your website transformation. Consider at least the following aspects: website governance, IA, processes, metadata, standardization levels, how far publishing is distributed, major system capabilities that are required, content strategy, the team, and design.
Another way to look at this is that you have somecontrol knobs at your disposal. The most important knobs are: the weight of what you are moving (such as the amount of content), the distance you are traveling (the gap from where you are now to where you are attempting to go), and the quality you are attempting. Instead of blindly going forward without planning these, tweak those knobs throughout your planning (graph where you are on the weight / distance scale).
Laugh test three: Will you be able to sustain quality and make changes after implementation?
Teams are usually far too focused on the launch date. Not only does this lead to immediate quality issues (by broadcasting a specific launch date, teams are more likely to push forward with the launch even when they know there are problems cropping up at the end), but more importantly it orients the team in an unproductive direction (looking at your web presence as something that should be project managed when it should also be product managed). In early planning, make sure you are clear about the implications of any shortcuts you plan on taking. For example, if you are not attempting to standardize similar sites while you are rolling out big changes, then it will make subsequent site-wide changes more difficult int he future. Also, when setting the stage for the project, make sure to emphasize with all stakeholders that you aren't shooting for one-time changes, but that everyone will be expected to maintain quality. At the most concrete level, will you even have the resources needed to maintain your web presence? If not, then consider a more modest goal.
Example: Slicing and dicing content while distributing content entry
Several times now I have seen organizations who are early in their website replatforming process and there are high expectations for both a) more distributed content entry and b) information automatically flowing to a wide range of topical pages. Both are possible, even together, but very difficult (slicing and dicing content requires good metadata, and that's even harder when more people are tagging). The point here isn't to say not to attempt difficult things, but that the implications of those decisions should be considered. Looking at each of the laugh tests above, in this example the clear vision will be absolutely essential. This is because the vision should to drive the complexity of the taxonomy, and it's extremely easy to create an overly-complex taxonomy (see this case study and more on matching the metadata complexity). Also, if the vision does not clearly require the additional complexity, then this requirement should be dropped. On to the second laugh test, the real question here is how you will implement topical pages with distributed content. Here you may tweak the quality control knob to a level that you can implement. But perhaps the third laugh test is the most critical, and easiest to overlook: how will you continue to train the publishers to maintain the quality levels of the topical pages? How will you track that quality over time?
What to do if your plans don't pass the laugh test
Luckily, it isn't that big a deal if your plans don't pass the laugh test! The main thing is to just STOP, DROP, and ROLL. By delving into the three questions above more, you can tweak the vision and broad approach (so that it does pass the laugh tests) before proceeding. The key is to not blindly go forward once you realize there are problems with your early planning.
The 2002 Adaptive Path blog post Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site) certainly has staying power, and it was excellent when it came out. But times have changed, and I'm amazed how often the blog post is still referenced. In particular, one of the things you are after in your content inventory is to see the variety and patterns of your content, and that isn't necessarily about plodding through every page of your site manually. Here are some key reasons why you should think more innovatively about your inventory:
There are many potential sources of data for an inventory
The first question you should ask yourself is "why am I doing this inventory?" It may be for general exploration of your content, but chances are you have a specific need. Your specific need may require data that you can't get by clicking around your site from the home page. For example, if you are looking to delete content then chances are it would be useful to know how many pageviews the content is getting. Sources of data for an inventory include: the HTML as viewed by the visitor, how content is used by visitors (such as pageviews), the origin system of the content (such as the CMS), and the intent of the site / quality evaluation.
Even if you do decide that you need to have full inventory with each piece of content enumerated as a separate line in your inventory, this doesn't mean that someone has to click through every page to do the inventory. In fact, you can get a lot of value from automating the collection of the inventory. This doesn't necessarily just mean pointing some crawler / spider at you site either, for example it could query directly against your CMS.
Sometimes you want an audit, but sometimes an inventory is sufficient
As I see it, an audit implies some qualitative judgement on the content. In these cases, you certainly need a person to do that evaluation. But sometimes an inventory is sufficient, and these can be done in a more automated manner.
An inventory isn't necessarily a one-time endeavor
Sometimes an inventory really is an ad hoc and one time thing, but you should at least consider if you should create an infrastructure for an ongoing inventory.
Sometimes Excel isn't the best tool
Excel is great, and I frequently find myself using it. Again (and as always with any technology evaluation), it gets to what you want to accomplish.