Are you optimizing your web presence (not just your main web site) for transactions, or relationships? Given the immediacy of the web, especially in how easy it is to do stuff, it’s easy to think short term. For instance, you may do something that increases the percentage of visits that people buy your main product (optimizing the single transaction checkout funnel). This clearly is important, but I would encourage you to think longer term, not just concentrating on the single transaction, but what you are attempting to accomplish with site visitors over the long term.
Are you optimizing your web presence (not just your main web site) for transactions, or relationships?
If you consider a car rental company, they want you to rent cars with them. But it’s clearly not enough to just make it easy to rent from you, since other factors (like price) may mean that people don’t even consider your company for a particular transaction (when a competitor has a cheaper price). So rental car companies have loyalty programs that make it more likely to consider them and use them. The point is that this process isn’t just about optimizing single transactions, but creating an affinity and predisposition to your offerings.
In addition to services companies (like the car rental company), this table gives a flavor of how other types of organizations, for example research and membership organizations, might think about their engagement funnel:
Each organization will have a different engagement funnel (for example research organizations have very different audiences and goals). The above table is an oversimplification, but hopefully it shows the type of variety between even types of sites.
Note that one of the main things you are looking for here is amplification. Let’s take the example research institution funnel of aware → share → collaborate → affect change. Someone may first hear about your organization through a blog post that one of their college mentions (they become aware). If they feel motivated, they will then share that post. If they collaborate with you, then they will be even more likely to spread your organization’s message. Talk is cheap. What you really might want is to affect change, for instance perhaps changing people’s day-to-day behaviors. At each stage, the impact of the engagement is stronger.
Really, you will almost certainly have multiple engagement funnels: one per primary audience. You may want different audiences to take different actions, all anchored by your overall website vision. A professional association may have separate interactions for students, professionals, and potential customers of the professionals. A product company may target consumers and businesses differently. Each particular organization is unique, and there is no plug and play audience list (and associated long term engagement funnels per industry). For example, some think tanks target the general public and others do not, which means that the goals and engagement funnels are very different.
Drive website decisions using your long term engagement funnel
Are there some stages of your funnels (remember you will probably have one per audience) underrepresented on your web presence?
Does every interaction either encourage either 1) deeper engagement or 2) further engagement at the level the visitor is already at (and not bouncing out to some lower level of engagement)? Does every web page do this?
Are there ways of measuring how your engagement level?
Are some levels overrepresented?
What engagement funnel would work for your type of organization?
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.