On a high visibility project, the heat from the spotlight might make you sweat, but don’t let that attention bother you. You’ll get used to it. What you really need to be concerned about are those floodlights!

You may have defined a clear understanding with project stakeholders about the exact nature of project scope, deliverables, budget, and timeline; but as far as end users are concerned - well, they are seeing your project in an entirely different light. For them, the scope is often much bigger.

My point is probably best illustrated by example.

I was recently involved in a project focused on migrating an intranet from a variety of older technologies onto content management and collaboration platform. Our key focus was on content migration. Our project was this size:

• Approximately 1500 end users
• Thousands of pages and documents
• Dozens of stakeholders

Along the way, we worked with a team of business analysts to redefine much of the information architecture, remove out of date and duplicated content, and generally clean things up.

Upon launch, we received much praise, along with some criticism. It was this criticism which was most interesting to me. Here’s a sample of some of that criticism:

• Criticism: Within several sections, users and content owners complained about incorrect page content and documents.
• Reality: This mostly occured in areas where we did little to no content cleanup. We simply migrated content as-is. Their complaints were about content that had been incorrect for months, perhaps even years. They felt we had migrated the wrong documents; however, they were really just discovering that their content had been incorrect for a long time.

• Criticism: French content was not given enough focus. It looked like an afterthought.
• Reality: On the old site, French content had been implemented inconsistently. During the migration, we settled on a single standard, to ensure that French content could always be accessed in a consistent way. In addition, we laid the foundation for a completely bilingual site; however, the business processes were not in place to properly manage content translation and ownership, so full implementation was defered. Overall, access to French content was improved.

This situation was frustrating - we’d worked hard to improve the intranet, and here we had users finding ‘phantom’ problems - deficiencies which had nothing to do with the scope of the project. For users we spoke with, the situation was easily explained. But what about the users who saw the ‘problems’ but didn’t bother to contact us. With these users, we had not opportunity to explain, and so they probably continue to think we messed things up.

Lessons learned:

• Depending on the volume, when migrating content, have a content owner review every single page and document. Don’t assume that existing content is correct.
• Communicate clearly with all stakeholders - including end users - about the exact scope of what has changed, and what has not changed. Even if they don’t read your whole email/communication, at least you’ll have something to refer back to.
• See the silver lining - at least your project has exposed some other issues within the business, and now there is an opportunity to correct them.

And so, the spotlights aren’t so bad. And neither are the floodlights, if you’re prepared.

You’ve selected a content management system, customized it to meet your publishing needs, and applied your desired look and feel. Now, you’re ready to load your site content. Here are a few things to think about for this process.

Who’s going to load the content?
Are you expecting your implementor / developer to load the content? Are they expecting you to? You should sort this out before you begin the project. There are pros and cons to each…

Implementor loads the content

• Pros
• They may be able to get the content loaded more quickly, leading to a faster launch of your site, for various reasons:
• Because of their experience with the system, they may have learned to load content quickly.
• They may utilize a more advanced interface for fast content loading.
• They may automate the content loading process.
• They may be able to get content looking ‘just right’ more easily than you.
• One less thing for you to worry about
• Cons
• Your implementor will not understand the context of your content as well as you do, so they may introduce errors in formatting, or may not highlight the correct things.
• If you are adding meta data, such as keywords to facilitate better searching or author information, you’ll need to supply this to your implementor.

You load the content

• Pros
• There’s no better way to learn a system than through experience. This is your chance to get some serious experience. You can learn the shortcuts (and workarounds).
• By using the system, you’ll really know if it meets your needs. Are you prepared to sign off on the project? A couple days or weeks of using the system will help you know that for sure.
• This gives you another chance to review the content before it goes onto the site.
• You will likely save some money. Developers and implementors will charge for their time to load the content.
• Cons
• If your site is large, and you have limited people available, loading the content may take a long time.
• If you get stuck - run into an error, don’t know how to format something - you could get seriously delayed.

Will content by loaded manually or through automation tools?
If content is being converted from an old system, programming and conversion tools outside of your skill set may be used, limiting your ability to do this task on your own. In my experience, content is most often loaded manually, for the following reasons:

• CMS implementations often coincide with site reorganizations, page layout changes, and content rewrites.
• Content from old systems is often unstructured, uncatalogued, and difficult to automatically convert.
• Content from the old system may contain formatting information that is not suitable for the new system. For example, the old content may be contained in tables or may have font styling applied - approaches that are no longer widely utilized by standards compliant content management systems.

Workflow. CMS buyers put it first on their list of mandatory product features. Vendors love to show it off during product demos. Project sponsors evangelize the coming good. Vice Presidents await the payoff.

It seems so simple. Write. Edit. Approve. Publish. And yet, in my experience, and I suspect many others’, many a Vice President are still awaiting the promised payoff.

Workflow rules seem so simple at the start, but a few conversations with users (or a few years of watching users struggle with workflow) reveal that content management is messy. Perhaps your situation is different (I’ve heard that before). I don’t know of any hard and fast rules that make workflow this way, but here are some situations to illustrate my point:

1. Marketing wants to make some product claims on the website. Legal is concerned about… well… the legal ramifications. Now what? In the human realm: a phone call, subtle human negotiations, mutually agreeable content changes, published content (ok - it’s not always this easy, but an avenue for discussion and negotiation is open). In the workflow realm: an email to Legal, stating that content is awaiting approval, gets read with no human context. Next - perhaps assumptions about the ‘damn marketing department that thinks they can say whatever they want to say’ followed by a denial message stating that ‘we can’t say this on our website, we’re exposing ourselves to too much risk.’ Perhaps the message includes recommended changes - from Legal’s point of view only. This is followed by Marketing once again knowing that ‘legal just doesn’t understand the challenges of competing in this market.’ Stalled content. Nobody is happy. (ok - it’s not always this bad, but think of this - have you ever received an email and misinterpreted the mood or tone of the sender?)
2. Your site is bilingual. You need the content on your site ASAP. You’ve outsourced your translation services. Should your workflow allow the English content (or other primary language…) to be published while the translation is done? If so, how long will your site remain out of synch?
3. You are an author. Your boss must approve your content. You are friends with your boss’s boss. You already know that your content is going to get approved, but your boss doesn’t. hmm.

So, how do you make workflow work? My advice:

1. Determine if workflow is essential to launching your project. Really. Could you run your content managed site for a few months without workflow? If so, do it. Here’s why:
1. By deferring workflow to a future phase, your project will launch sooner - you won’t spend days (weeks…) analyzing your workflow needs. And you won’t spend days (weeks…) implementing non-core functionality. Instead, you can begin developing the core components of the solution.
2. A few months of site usage will reveal your true workflow needs. Why spend time trying to dream up what will really be needed? Launch your project, use the system, and you’ll soon learn where workflow is or isn’t needed. In my experience, this need has been the same for almost every project: nil. Analysis and programming would have been wasted money and effort. But even in cases where workflow is beneficial, a few months of system usage will greatly improve the accuracy of your needs analysis.
3. Allow your users time to learn the CMS. In the beginning, workflow will be a barrier (”did it publish?” “Hey John, did you just get a notification from the CMS, because I think I submitted a page…”), even if a future implementation actually smoothes the process. Once your users are competent and unintimidated, then you can think about workflow, as well as other new features.
2. Don’t confuse workflow with authoring permissions. It’s entirely possible to set up roles such that users have full access to author/edit/publish in some sections of a website while having no rights in other sections.
1. I recommend that you implement authoring permissions during your first phase launch. You don’t want your HR staff mistakenly posting a press release when they really just want to edit a job description.
3. Recognize the messiness of workflow and human behaviour. Don’t oversimplify your workflow. If you’re going to build it, build it right - otherwise it will just get turned off. (Or worse, become a reason to call the CMS project a failure.)

I do recognize that workflow is absolutely necessary in some situations. Perhaps you have franchisees writing content for a corporate site. Perhaps your content team is dispersed across multiple time zones. Perhaps your industry is highly regulated and you must be able to prove to an auditor that a specific article of content was undeniably approved by a VP on a particular date and time. If this is you, I wish you good luck. If not, in my experience, I think it pays to wait a few months for workflow.

Your website creates an experience for your users. That experience will vary widely depending on the purpose of your site: it may be the experience of instantly finding high quality research; it may be the experience of booking a dream vacation, with all the emotional underpinnings; or it might be the experience of finding out why one digital camera is more suitable than another. No matter the details, a successful user interaction with your website – finding the right document, completing a booking, understanding a product offering – is highly dependent upon a seamless user experience.

What does seamless mean? Users shouldn’t experience anything on your site that breaks the flow of their experience. What types of mistakes reveal the seams of your website? It depends on the user, and each user is different. Overly complex forms, spelling mistakes, internal terminology, navigation that disappears, broken links, missing images, meaningless error messages. Sometimes the seams are more subtle: inappropriate tone, too many search results, too much fluff.

How do you find the seams? User testing.
Find 5 people (preferably in your target audience) to test your site. Ask them to use your site, watch them, and listen to them. You’ll start to find the seams. But, be aware that this is an ongoing process. As you fix your site, add new features, and rewrite your content, you’ll need to test and retest.

A real world example?

This is a photo of crepe shop that I pass several times per week. I love crepes, but I’ve never bought one here:
=
Every time I walk by their front door, I’m reminded that they use instant mix to make their crepes. What comes to mind? I could do that at home, why should I buy a crepe here? So, I just keep walking.

What’s really interesting – there’s a cheap and simple fix: put the mix in a canister. And you know what, I wouldn’t be surprised if the shop where I do occasionally buy a crepe uses the same mix. The difference? They don’t remind me of that fact when I walk in their front door. In fact, they never remind me.

The lesson: if users are made aware of the mechanics of the experience, the experience is broken, and the effectiveness of your site suffers.

On the many projects I’ve been involved with, I’ve seen the odd deadline go unmet – never through any fault of my own, of course. One aspect of projects that seems most susceptible to missed deadlines is the user interface design. Mockups are created, presented, and then revised. And then revised again. And again. And again. Then a few more people look at them, and they are revised yet again. Repeat until approved. Goodbye deadline.

But, there are also projects that beat their deadline. Mockups that are signed off after first presentation, or just a few minor tweaks. Smiling designers. Smiling clients. Smiling project managers.

What’s the difference between these two situations?

Imagine a taxi ride in your home town. You step in the car and tell the driver your destination. He starts driving, because he knows how to get there. However, after a short period of time, you hit some traffic; or, perhaps you suspect that he’s not taking the best route. What do you do? You tell him. You show him shortcuts you know, you tell him about a different way to get to the destination. You become a backseat driver – and in all likelihood, it gets you to your destination faster, and probably cheaper too. And why is this? Because you know your home town; you know the best routes to your destination.

Now image a taxi ride in a town you’ve never been to. You’re at the airport, heading to a hotel. You step in the car and tell the driver your destination. He starts driving, because he knows how to get there. However, after a short period of time, you hit some traffic. What do you do? Probably not much – you sit back and think about something else. You let the driver find alternative routes; you let the driver use shortcuts that he knows about. You don’t question him.. unless perhaps the ride starts seeming far too long, or there are no visual clues that you are getting closer. So, you sit back and relax, confident in your drivers knowledge – and in all likelihood, it gets you to your destination faster, and probably cheaper too. And why is this? Because you don’t know this town, but your driver does – he knows the best routes to your destination.

What’s the difference between these two situations? What you know (or think you know). In the first, you know the domain. In the second, you admit that you don’t know the domain.

Back to web design. How do you get to your destination faster and cheaper?

1. Hire a knowledgeable , experienced designer. (more on this another day)
2. Ensure that your designer understands your destination: your site goals, your brand, your clients’ characteristics…
3. Determine how much you know about the domain. You know your clients, but do you know how they interact with websites? Do you understand navigation and information architecture? Have you read the latest research about usability? User behaviour? Information scent? Interaction design?
4. Act accordingly. If you know about these things – collaborate with the designer. If not – trust.
5. Are we there yet? This will get you there faster.

While content management systems (CMS) can bring many benefits to an organization, their succesful implementation is difficult - not just meeting short term timelines, but also with regard to long term adoption and user satisfaction.

A few weeks ago, I gave a presentation at Barcamp Vancouver entitled (dis)Content Management (view presentation in PDF format), where I spoke about these challenges. It was cathartic - six years of CMS frustrations freed from my pysche; however, I realized after that I spent very little time talking about solutions. And so, today (and in future articles) I will expand on my talk and offer my views about how to overcome some of these challenges - focusing on one issue at a time…

Challenge

A key problem I’ve seen with the systems I’ve worked with is the authoring environment. If you think about the writing process - how you actually write something - it is probably not the same as the next person. My process is something like this:

First, I’ll assemble some loose notes - probably written down on sticky notes, or anything I can get my hands on. Next, I’ll start an outline, using the outline mode of Microsoft Word, or just on paper. After that, I’ll start writing out the content, building out my ideas. This process can take some time. Then begins the editing process, where I’ll cut - paste - hack - slash and cut again. This too can take awhile. Once I think I’m done, I’ll start the cleanup process - determining a title, applying styles, fitting into a template, adding meta data to the document properties (yes, I do that). Then, I usually continue on again, realizing that the editing wasn’t really done, or that my ideas needed more work, and so begins another round.

If I’m collaborating on a document, it gets much more complicated - phone calls, emails, meetings to brainstorm, meetings to review, meetings to format, more phone calls, more emails…

The CM systems I’ve worked with don’t support this mode of work. Typically, the systems are forms based - a set of fields to input information such as titles, categories, publishing dates, authors, as well as a small window for typing in your actual content. These systems don’t provide the tools that most authors are accustomed to:

• No support or limited support for outlining, brainstorming. When it is supported, your preliminary notes are often on the system for others to see - which you may not want yet.
• Tracking changes and comments not granular enough. Usually at the page level, without the ability to add comments within the page itself.
• Often difficult to collaborate with multiple people - each user will need an account on the system.

In addition, much web content is repurposed and edited from existing sources - not written from scratch.

The result: authors work in the environment in which they are comfortable (and productive). And this is not, unfortunately, their CMS.

What does this mean for our CMS? Copy –> Paste

And this is where things often get ugly. The copying part - not so bad. But the pasting…

Every CMS content editor I’ve seen has problems with pasting. Actually, they suck: loads of additional meta content is pasted, site style sheets get ignored, fonts appear from nowhere… I’ve even seen files get so corrupted that they couldn’t be opened again. The solutions I’ve seen:

• Vendor recommendations not to paste from MS Word, or other word processing software
• Recommendations to paste into an application such as Notepad, to strip the formatting, and then re-paste into the CMS editor
• Special ‘paste as text’ buttons, which strip all formatting

As you can guess, your users will love this. The final touches they just put on the layout of their document just vanished, and they’re left with a stripped down editor and a tiny window to try to clean up the mess.

Solution

I’m not sure I can say that I have a solution, but I do have the following recommendations:

• Include your authors in the buying process of a CMS - after all, they’re the ones that are going to have to use it every day
• Ensure that your users understand that web content is different from their usual non-web writing. Expectations need to me managed. Content written for the web is going to look different from other types of internal documents - different content structure, different formatting, different tone, different style. The constraints of the web are different from those of paper, and it is important that authors understand that.
• Don’t settle for a 30 minute demo from the vendor. Get access to an installed version. Play with it for a few days. Ask your authors to actually start building some pages. If you are working with a developer - and not a packaged tool - ask them to build a prototype.
• Accept that cut-and-paste will be the method of choice for many of your authors.
• Thoroughly evaluate the paste functionality of the CMS (as well as other features). Vendors will typically gloss over this - they want to show you the workflow features!

Who would have thought that the paste feature of a CMS could be so important… I never did.