When maintaining, improving, or radically changing your website (or the underlying platform), there are lots of stakeholders involved. Also, the stakes are high since it’s really easy to implement things in a way that is not flexible or otherwise doesn’t really serve the organization well. One problem is the temptation to oil the squeeky wheel, giving undue attention to power users when basic CMS users and external site visitors are more important.
But the only reason to have a website is to serve business goals (or, if you aren’t running a business per se, your organizational goals). Obviously here I am not talking about personal websites, that do not have business goals.
Any organization’s website should be viewed (and managed!) as a product. This means that everything on the site should be toward your organization’s (non-web) goals. So when deciding on what to do next on your website, it should always be viewed through the lens of your business goals.
External visitor needs should be prioritized over any CMS (backend) users, and basic CMS user needs should be prioritized over power user needs. But they all need to be anchored by the business goals. So the starting point should be the business goals. Instead of just listening to the clamour of requests coming in and prioritizing by stakeholder group, ideally you define goals and then prioritize your work program to move toward those goals.
Seth Gottlieb wrote an excellent blog post “Flexibility. It’s a matter of perspective.” where he lays out the largely mutually-exclusive meanings of “flexible” to content creators, web designers, print designers, and developers. I would add another key stakeholder: the overall web presence owner who may want branding consistency. Put even more broadly, the website needs to be 1) coherent and 2) able to make site-wide changes.
Inflexibility in two steps, starting with… flexibility
The interesting thing about flexibility is that on the small scale it is trivial. This is one of the biggest problems, since it is tough to argue with stakeholders who are reminding us how easy it is to implement what they are asking for (“I did this on my iPad while we were talking – this is obviously easy!”). So when push comes to shove, especially in the heat of making lots of big changes to a website, we let stakeholders do whatever it takes to implement whatever they think is necessary. For example, we might open up the WYSIWYG editor to allow any HTML, or we might let one group launch a microsite on another platform. In other words, we may start with flexibility. But then later the inflexibility settles in. What happens when we want to change the way all the data tables look across the site? Oops, that’s now hard since it’s implemented in an inconsistent manner. What about when someone wants to change teams in the organization? They now may have to learn different tools. We all know cases where even getting the logo the same across the web presence is difficult.
The flexibility equation
There are two sides to the flexibility equation: 1) immediate flexibility and 2) long-term flexibility. For example, when someone is publishing a page that needs to include a data table with special features, then they want – now – the flexiblity to make that happen. This may fly in the face of long-term flexibility when it comes to standardize how data tables work (perhaps also allowing additional features where all data tables have manipulation or download tools).
Streamlining and product management over time
In many ways immediate flexbility and long-term flexibility aren’t as in conflict as they appear, since almost always everyone wants to work faster. In digging deeper, usually there are known common publishing (or site management) needs that should be streamlined. Lots of people complaining about needing to control their left nav item? Instead of just letting people completely control their section’s left nav, perhaps by talking with the stakeholders you realize that really all that is needed is the ability to add one custom link. Of course, the details of your website are unique, but usually if you go a little deeper in investigating issues you can find a lot more commonality than is immediately obvious. On an ongoing basis, you should be product managing your website for ongoing quality, change, and coherence, including defining your ongoing work program. Looking for opportunities to streamline things for stakeholders, while offering an appropriate level of flexibility is an important piece of product management.
Making big changes? Focus to help frame the flexibility discussion.
As Seth mentions in his blog post, teams need to have mature discussions about the “balance of control.” The above discussion on streamlining should be an ongoing process as part of your website product management. Teams doing early planning in developing master plans, one of the most important aspects is clearly defining the vision of what they are attempting. This probably includes refining the vision: as teams dive into the different aspects of their vision (and at a high level the people, processes, technology, content, etc. required to implement it) to confirm the vision will work, they will probably realize the vision needs to change a bit.
This process of defining the vision while confirming it is possible is important when defining flexibility for the following reasons:
It grounds the discussion of control, both initially and on an going basis (and having these discussions early rather than later means fewer blow-ups later).
Senior management has an opportunity to confirm or change the broad goals, rather than jumping right into details (where different stakeholders may push for flexbility that run counter to broader goals). Note that with one recent client of mine, it became obvious that senior management (as opposed to particular site owners) was very interested in consistency and being able to make web presence-wide changes, so this could be accounted for in the vision and master plan.
Content contributors often hear the word “standards” and run for the hills, and people often think in terms of flexibility in a binary “yes, flexible” or “no, locked down.”
But it’s much more suble than this, and will probably be the topic of another blog post. That said, here are some key things to look at when defining how flexible to make your site:
What sites (if you have a large web presence with lots of sites or sections of sites) will be standardized and which will be completely on their own?
What components of pages / IA will be standardized? For example, a standard template could be nothing more than a shell with a standard header and footer, or it could prescribe many more components on a page.
How deep will the standards be? For a particular component that is being standardized, is it completely locked down to a particular value, a palette of options, open with some filtering, or completely open?
In other words, flexibility is more in grayscale than black and white, and you should attempt to shoot for the middle ground allowing streamlined flexibility.
Although mobile technology and cloud services are in their infancy, there is a major gap that eventually (perhaps years) needs to happen in my opinion: divorcing apps from specific cloud services. Take my recent experience using Grafio (a drawing app on the iPad) for the first time:
The problem is that there is a direct, two-way connection between Dropbox and Grafio (as well as Box, as the first diagram below shows) that is fragile and requires each app to maintain. Instead, if iOS offered an intermediary layer for the file system (either locally on the iOS device or through a cloud service), then the app (in this case Grafio) would not interact directly with Dropbox at all (the second diagram below).
There would be several advantages of the operating system (whether iOS, Android, or otherwise) being the intermediary:
All apps (that used the OS correctly) could interact with all cloud file store services (that the OS supported). This would also mean that as the OS adds a new service, all apps would have access to that service (for example, I rarely use Dropbox, so some tools force me to work differently).
Syncing of files could be managed by the OS, rather than each app having to separately implement it (many apps do not implement the syncing well, even to a small number of services, now).
Policies could be implemented across the whole device, rather than on a per-app basis (although of course the OS would need to support the ability to restrict certain services to certain trusted apps).
The real power would arise when the OS didn't just intermediate file stores in the could. What if the OS also did the same for people (for example, pulling in data from CRMs), tasks, digital assets, projects, etc. Then we would also be able to set our devices to "don't show me any work information today" and the OS just wouldn't show any work information in any app from any source.
Is this pie in the sky? Perhaps (especially since some operating systems would not have much incentive to open up to other cloud services), but I hope that at some point in the future this is how these devices work with cloud services. In the meantime, we will have a fragmented and incomplete mobile experience.
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.