Justifying an Enterprise Taxonomy→

The creation and management of an enterprise taxonomy can mean a significant investment in resources. It may mean hiring or training people with specialized skillsets, purchasing tools, doing development work to integrate toolsets, establishing and monitoring systems to track use and effectiveness, and more.

The key to selling it in within an organization is justifying the expense by identifying the external and internal uses and benefits. The work begins with an analysis of the business systems that can benefit from a consistent, centrally-managed taxonomy--not just content management systems, but also CRM systems, records management, intranets and more. In addition to internal systems, develop use cases for the user-facing features and benefits--improved navigation, filtered search functionality, search results, customization, and dynamic presentation of content. 

For more about how an enterprise taxonomy is used and how to determine the return on investment, check out our latest article, The Case for Enterprise Taxonomy.

Once an enterprise taxonomy has been created, it needs to be maintained and updated to reflect changing content and changing user needs. To learn more about maintaining a taxonomy, see our articles on taxonomy governance and how to establish a governance team.

Taxonomy Governance, Part 2→

Previously, we've written about why taxonomy governance matters. In a new article, we take on the topic of how to establish a taxonomy governance team.

The article discusses putting into place appropriate measures for governance, including defining strategy, establishing standards and procedures, planning for staffing, implementing technical systems, and ongoing monitoring and refinement of the taxonomy.

The size and makeup of a governance team is highly dependent on the size and complexity of the organization and the taxonomy implementation, but the article provides guidance on an ideal set of roles and responsibilities. Key roles include sponsorship and decision making, technical support, taxonomy management, taxonomy consumers, and subject matter experts.

Leaders are tasked with answering key questions about the strategic uses of the taxonomy, setting business priorities, and allocating resources. The technology team provides the expertise to create the supporting systems and make sure that business goals align with technical reality. Given that many taxonomy implementations require integration of multiple consuming systems, the technical representatives play a critical role. The taxonomy developer and administrators create the taxonomies and related vocabularies and maintain them over time. They execute on the policies established by the governance team and communicate status and resource needs. Subject matter experts provide the necessary feedback and advice on the subject areas described by the organizational taxonomies.

All members of a taxonomy governance team share the responsibility of ensuring that the organization's investment in taxonomy is maximized, whether that means enabling effective end-user-facing systems or internal process and management efficiencies.

Read the full article for more in-depth discussion of the value, roles, and responsibilities of a taxonomy governance team.

Understanding User Needs→

The holy grail of content strategy and user experience design is accurately and elegantly fulfilling the needs of the users who visit a website or interact with an application. But gathering those user needs—and separating them from user wants, which can be very different—is one of the biggest challenges we face.

You Can’t Always Get What You Want

Many of us have had the experience of conducting user forums or stakeholder interviews with the sincere intent of gathering specific needs that we can turn into effective content and experiences. Too often, we come away with a “wishlist” instead of clarity on user needs.

The problem with creating wishlists, rather than actual user needs, is that wishlists can be wishful thinking and not grounded in research or even reality. Expectations get created that those wishes are now project requirements. Jumping straight to a tactic like this bypasses the opportunity to truly evaluate user needs against business goals and project or budget constraints and come up with a sustainable and successful plan.

The real danger is when a wishlist requirement has implications for tool selection (such as a CMS) or ongoing management beyond the budget or capabilities of the team who will ultimately own and maintain the site. “Shiny object” features that require a lot of management and don’t directly deliver for the users waste time and money for the immediate project build and for the longer term, too.  

So, How Can We Get What We Need?

One technique commonly used for capturing user needs is the persona. In theory, personas are created based on actual user research, and therefore can be relied upon to help vet content and user experience plans. Gerry McGovern recently wrote, however, that personas are “Mythical people, fictional people, perfect customers—who didn’t exist except in the minds of the web teams.”

Gerry argues instead for real interaction with real customers: “Developing a culture of the customer is vital to our success. How to do that? First, we must develop a genuine will and desire to regularly interact with our customers. We need to hire people who are highly empathic and curious about people. We need less content people, less design people, less technology people and more people people.”

Certainly, there’s no substitute for direct interaction with users, and the topic of empathy has been the focus of a number of articles and even conferences for the past couple of years. But the reality is that for many businesses, the web site needs to serve multiple audiences, scattered around the globe. It can be difficult to find the resources to interact directly with them on a regular basis.

Testing, 1-2-3

If you are able to do in-person user research, doing observed-behavior studies such as usability testing in a lab or contextual interviews in a user’s own environment are valuable tools. If you aren’t resourced to do direct user research, consider doing a pop-up survey on your site or using a remote-testing tool.

There are a number of free or low-cost easy-to-use tools out there to help test aspects of your site structure and content with real users. For example, Treejack, from Optimal Workshop, allows you to remotely test your information architecture with users. Also from Optimal Workshop, OptimalSort allows online card sorting to test the way your users would expect content or products to be organized. The Nielsen Norman Group has an excellent article on tools and how to select one and set it up for maximum effectiveness.

A new tool to the scene is Intercom, which promises to help you track who your customers are and what they’re doing, in essence creating real-life personas. Other ways to track what your users are actually doing include monitoring your analytics data for entrance, exits, time on page, and traffic flow. Some of the more robust and comprehensive site platforms like Adobe’s Target and Sitecore’s upcoming 8.0 release help provide user segmentation from the actual user behaviors on the site.

Listen and Learn

Your customer feedback is also a valuable source of information—if users are contacting your support team with similar questions, there is a clear opportunity to create content to answer those. Users often take their issues to social media as well as their goals and interests. You can learn a lot about your users by spending time interacting with them in these channels, reading what they post, the questions they ask and reviewing the analytics to understand what topics they find most engaging. Search logs are another way to see what people are looking for and finding—or failing to find—on your site.

Adapting to User Needs

However you gather user information, it’s important to make sure that your content processes are agile enough to adapt. Create a positive feedback loop, where user needs are driving regular review and update of content and user experience to make sure that your users are getting what they really need and taking the actions that your business really needs. Remember, though, that the work is never really done—user needs change over time, businesses goals shift, and you need to be able to evolve with both in real time. 

Content Migration: When (and when not) to Automate →

Let's be clear. Updating and migrating your site’s content can be as big or bigger an undertaking as the redesign of the site. The quality of your site content is also as critical as the new design and functionality. Content is not just critical for your users, either. With the latest changes to search engine algorithms, providing high-quality, unique content that meets your users goals is the most important tactic you can leverage for SEO.

But trying to manage and migrate thousands of pages of an enterprise web site is daunting at best and, at worst, the lengthy and detailed process of content revisions and migration can jeopardize the launch date and budget for the project.

This may explain why content was historically a “forgotten” part of a web site redesign project. Agencies or implementation partners were often willing to just leave the content—and the risks—to the client. Clients have had to manage for themselves the content tasks that would not fit into their project vendor budget—often without the staff or editorial processes in place to do this well.

It’s not a shock that “automated” content migration tools were developed. But, are these tools the easy answer agencies and clients both are looking for? To use the worn-out UX phrase, “It depends.”

 Here’s why.

The GIGO Rule

Back in the dark days of “brochure-ware” web sites, online content was often re-purposed print material. It was loaded with acronyms and corporatese. It was not scannable, searchable, visual or formatted for online. Sometimes, the web site just didn’t have the budget for a real copywriter or information designer, or the budget for video or quality images.

Redesigns often meant putting a nice slipcover over bad content. Garbage In, Garbage Out, in other words.

Thankfully, online content has improved vastly, but not completely. Chances are there is content in your site that is dated, ineffective, not visited, or not compatible with your brand or your users’ goals.

If you don’t take the steps to review, audit and improve your content before a platform migration and redesign, you’re not only perpetuating the GIGO rule, you’re skipping the most important step for creating a better user experience. Better content also means better SEO and higher conversion rates. Both of these outcomes are higher priorities than the internal efficiency you are gaining with a better CMS. Planning for a content-first approach to your site migration may be the most important line item in your budget.

Projects like these are often time-crunched and there’s always the temptation to look for shortcuts at every step of the way. There is a great tool for generating the content inventory that kicks off your analysis and planning, but the audit, developing a content strategy, and optimizing your content are all tasks that require skilled humans and time. And those activities are worth the effort in the long run if you are truly creating a content-first experience.

The content improvement process needs to happen early in your project. Your content strategist needs to be engaged early and work closely with the user experience architect as well as the technical team. The user experience needs to be informed by the content strategy so that the new site is structured to present the content your users need when they need it. You also need time to develop good content. This means not waiting until the site templates are in the CMS before you begin creating the new content.

Tools like GatherContent’s content development platform can help you manage your content creation workflow outside of your CMS and provide your writers with content authoring templates that align to the new site so they can begin writing before development begins. GatherContent and similar tools can even support export of your new content to the redesigned site depending on your CMS platform.

Because your content team is able to work early and independently of the site development, the process of revising or combining content and creating new content is less likely to jeopardize your site launch.

You may consider a content development platform tool if:

• You need to start the content creation process before site development.

• You want to avoid the risk of jeopardizing the launch if the content is not ready.

• You have multiple content authors and need a tool and shared workspace to help with workflow and project management.

• You hate tracking down and organizing separate Word files.

• A significant portion of your site’s content is new or needing significant rework.

• The chosen content development platform is compatible to export to your new CMS.

• The new site’s content templates have a very different structure from the existing site.

• You are creating all new content.

Steps you cannot automate regardless:

• Content audit

• Content strategy

• Content-first UX planning

• New content creation and content updates

All Content is Not Lost

Improving your site content is time-consuming and it takes budget and skill. This is why many clients want to focus their new and updated content efforts on the most valuable site pages like landing pages and those along the sales funnel or conversion paths.

Another way to lighten the weight of a content migration is to delete dated and underperforming content. But “out with the old and in with the new” may not cover all your migration needs. 

A lot of your content will stay the same especially if you have an active newsroom and hundreds of existing press releases to migrate. These content items are usually highly structured in how they are written, and it’s likely that the structure won’t change dramatically in the new site templates.  Automation may be the solution for this type of content.

Again, it depends.

Consider automation if:

• Your site has hundreds of pages of content of one type such as press releases or news articles.

• The current templates for these page types are very similar to the new templates, at least in the content area.

• The cost of an automation tool plus about 15 minutes per page of QA and resource time is less than the cost of 15-40 minutes resource time per page to manually migrate the content. If your automation plan requires writing scripts, evaluate the developer time to create the scripts plus the manual QA and cleanup for each page against the all-manual effort.

• You truly are re-platforming only and all the content is migrating as-is to the new site templates that match the current ones.

• You are comfortable with this content migration taking place after the site is at least 80 percent developed and tested, and aware of any risks to the content migrated during the remaining development.

Even with automation, your team still needs to plan on some manual time for each page migrated. There are a few reasons for this. QA time is required to review each page, check links and formatting that may have not migrated perfectly. The existing content may have had typos or errors you can fix at this stage. And, finally, you may be wisely improving your SEO, or making your site’s taxonomy consistent, which means you’ll need to update the meta data for that existing content, too.

The Best of Both Worlds

Because brand new sites and “as-is only” migrations are less common, there’s a good chance that your project will involve both migration of existing content and the need to update and create new content. Both of the types of tools covered here offer significant advantages to support your migration.

The important thing is that there is no truly automated tool, and there may not be one single tool that does everything you need it to do for your site migration. You need to base your decision on which tool or tools will offer the best support for your specific project. No matter which tool or tools you use, your effort will still require significant manual effort.

 A few points to remember:

• You will still have to allow for manual review of content from an automated migration.

• Most sites require both new content and existing content in their migration.

• Consider the timing you need for successful content migration; do you need to start before development or can you migrate late in the process without risks to the launch date?

• Evaluate the ROI of an automated content migration tool versus manual migration carefully.

• Be sure the tools you select can work with the CMS platform for your site.

• There is no automated solution for good content strategy and user experience, but a content-first process sets your project up for success.

Additional Reading and Resources

For more on how to audit content pre-migration (or at any point in a content project), check out Strategic Content founder Paula Land's new book, Content Audits and Inventories: A Handbook. 

Tools mentioned in this post:

• The Content Analysis Tool (CAT), for creating automated content inventories

• GatherContent, for collaborative content authoring 

• Siteport, for automating content migration

New Book on Audits and Inventories Released→

We are very pleased to announce that Strategic Content founder Paula Land's new book, Content Audits and Inventories: A Handbook, has been released. 

The book is a practical, tactical guide to planning and conducting content projects that begin with an inventory and a comprehensive content audit. Paula walks you through how to begin with an automated content inventory and takes you through the audit process. The handbook provides guidance for establishing goals and scope for the audit, planning and assembling the team, getting organizational buy-in, assessing content against business and user needs as well as standards and guidelines, gathering insights, and presenting strategic recommendations to stakeholders.

Myths and Truths About Personalization→

Know what tools can—and can't do

Personalization is often sold as a magic solution to all marketing needs. You just put it in place and it “auto-magically” delivers for your goals, making a completely automated and customized site view for every user type, every time.

It would be great if personalization were that simple and easy to implement—and if the tool really could think for us or create the entire set of content for each user without any extra effort. This is where the reality of personalization comes in.

Don’t get me wrong. Personalization is a powerful tool and there are robust CMS platforms that can do some types of personalization out-of-box. Some tools, such as Adobe’s Target Premium, even have “automated” capabilities.

But these tools, just like every other kind of tool, only work as well as the craftsman using them. A hammer doesn’t work by itself—even if it is a 15 amp, 2000-strike per minute demolition hammer. Automated decisioning and targeting still requires human beings to develop the marketing strategy, to plan the user experience for the strategy, to understand all the variations of content needed to make it work — and to create the content.

Far from “auto-magic,” when you implement personalization, your site management effort will increase in many ways—along with your results if you implement it well.

Good things to consider before you start your personalization plan

Personalization tools often work at a specific, component level

This means your page templates have to be developed in a way that individual elements on the page can be targeted. You need to build your site to be able to support this requirement. For this reason, it’s best to have a plan for how your site will need to use personalization before you begin the site architecture rather than reverse engineering components and the site experience later.

Some personalization requires custom code, especially explicit personalization

Also, site-wide personalization such as limiting the views of product options by the user’s geographic region may require custom code to be implemented. Geo-targeting is not always accurate based on IP address, so you may need to add-on a tool to help accurately target users.

The rules—even if they are applied by machine learning—always change

For example, Google now masks inbound search terms and you can’t personalize a banner based on inbound search. This was a key personalization tactic prior to Google’s changes.

Results are not instant

There are shorter-term personalization tactics and longer-term ones. The right type of personalization to use should be determined by your marketing goal. It can take months for tactics like profile-based personalization to yield results.

You may need to combine personalization with A|B testing, goal monitoring, or engagement scoring to be able to track results and optimize your personalization

In this way, you can validate that your profiles or segments are accurate, your targeting is on track, and your efforts are yielding results.

You still need to plan a site with an effective user experience and a solid content strategy

Making the right content available to the right users at the right time is a fundamental part of how the user experience and content are planned—long before personalization capabilities were accessible or accurate.

Beware the filter bubble

If you personalize the experience too narrowly, you may limit your users from finding content they need. This is called a filter bubble. In this case, personalization negatively impacts your user experience.

Think of personalization as a secondary tool

Your primary tool is creating a well-organized site with the right, discoverable content for your audiences. If you think of a good site experience as a 100-meter dash, personalization is just a turbo boost for the last few meters.

There is no easy, all-at-once personalization of a site

If someone tries to sell you this, be cautious and ask for the full story. Personalization strategy takes time to plan, and implement. It takes optimization and monitoring to see results.

Most of all, personalization takes a smart strategy and great content — neither of which can be automated by a tool

Mind, Map, and Fill the Gap→

An essential step in the content strategist's process of getting from discovery to delivery is an assessment of the gap between current and future state. In concert with the content audit, we create what is called a gap analysis, which informs the need for content revision and creation to ensure that content meets user and business needs. 

Our newest article, Map the Gap: A Simple Grid Approach to Successful Content Gap Analysis, presents a model for a simple grid that you can use to track your buyer and user journeys, business goals, and the content to support each along the path. Filling out the grid allows you to capture the content needs against which to assess current state content--if you don't have content to support a step along the path, you've identified a gap to be filled. 

The gap map is also a helpful tool for planning for content personalization by helping you identify where you may need variations of content to meet user goals. Use the map as a handy way to align stakeholders on the goals as well. 

Read the article, download the sample grid, and give it a try in your next content project.

Why Taxonomy Governance Matters→

Governance. The very word is a little intimidating, isn’t it? Implications of outside authority imposing limits and regulations. The expectation of conformance. The repercussions that follow failure to comply.

So why should we embrace the concept of governance? Because just as, when done thoughtfully and fairly by our political bodies, when we apply it to our content and taxonomy it results in a better world. A more consistent, predictable world, where decisions are made based on documented rationale and best practices and roles and responsibilities are clearly communicated.

Taxonomies are particularly vulnerable to breakdown if not carefully managed. They can be complex to construct and maintain, but are nearly useless if not kept accurate and current. And when we build functionality that uses them, we place valuable user experiences at risk if we aren’t maintaining them on an ongoing basis.

In the first of a two-part series, we’ve just published a new article called Introduction to Taxonomy Governance. The article discusses the why governance matters and what it consists of, from strategy to operations. In part two, we’ll discuss how to set up and manage a taxonomy governance team. 

Think Content→

Think Content-first When Designing for a Component-based Web Site

 by Beth Bader

Components are not a new idea to content strategists. The idea of a component-based authoring system is central to building a “write-once, use many times” content set. These systems are usually XML-based and can author across mediums, both print and web, for example.

This same re-usable approach is the way major CMS platforms like Adobe CQ, Sitecore — or even open-source platforms like Drupal and Wordpress – function, by building sites with reusable “chunks” of functionality. These design components are then assembled to build a “page.” Like a set of Legos, you can combine these different building blocks to create different pages. Your only limitation is the set of building blocks you start with.

The big win here is flexibility to define pages from multiple combinations of components rather than a limited set of fixed page templates. You can also create the functionality once for a set of sites, but then alter the CSS style to allow for multiple brand sites sharing the platform to reuse the same component set.

A component approach to the site development also allows for the team to test and approve smaller chunks of site functionality throughout the project lifecycle. The approach makes sense on a lot of levels.

The challenge is changing the thought process for us as content strategists, content authors, clients, designers, and information architects who are accustomed to thinking in “pages.”  This is where a content-first approach can save your sanity and your project.

Component-based Design Still Begins with Good Strategy

You need a clear road map for the project that defines goals and success. This doesn’t change whether you are using waterfall or agile, page templates or components.

You still need stakeholder interviews, user personas, a review of site and search analytics, and a thorough content inventory and content audit. The content gap analysis and a keep/kill/modify content exercise should also be in the mix before you begin design.

Understand Your Content to Define the Right Set of Components

The information architect still creates a site map for the top levels of the site. This is still based on working with the content strategist who will organize the deeper levels of content.

Where the work changes is that instead of building around 12 to 15 page templates for a large web effort, then fitting all the site’s content into one of these fixed shells, you now have to define about 30-40 components that all have to work together. Smaller projects require fewer components, of course.

How do you know what makes a component? The answer is in your site content and the content strategy. By looking at across all the content that will be migrating in, you can begin to identify types of content elements needed for the site. What is the best way to present each content element on the site and what would a component need to do to present it effectively? Just like enterprise content strategy, you are looking for the elements that can be repurposed and reused.

Define the Components for the Optimized Content, Not Just the Existing Content

The content audit is key here because this document explains how the content set needs to be optimized. This, plus the gap analysis, focuses your work on the ideal future content state rather than just referencing how the existing content is displayed, which may not be optimal.

For example, a current site page you are keeping may be a long page of only body text. Review the content and identify what the purpose and value of this content is. What are the elements that provide value and how can these be optimized? How does the content compare to your content review checklist?

By reviewing the content like this, your long content page may become five components: hero image and page title, text area with columns and images, author bio, supporting content like a video asset or an infographic, related content links, or an associated call-to-action.

Your long text page is now designed to help the user get more value, read the page more easily, quickly engage with more content or respond to a call-to-action. Because you’ve taken the time to identify what components make for a good user experience against your actual content — and because these building blocks are reused throughout the site — you’re creating a more consistent and valuable site experience that delivers better for both your users and your business goals.

The content strategy work may also define unique or new content items needed; brand stories, interactive experiences, how-to or training modules. These have to be identified as part of the component set as well.

Not every page in your content set will use all of the components. The goal is to define the whole set of components that are needed for all of the content types the site has to display. This is thinking content-first. This requires having the content strategist work closely with the UX resource and the project team throughout the design and development phases.

If you fail to base the component set on the actual content the site needs to display, you are setting the project up for failure before it begins. Designing the site first, then considering the content later may make for a nice looking site, but you won’t be able to use it to deliver the right content.

Pages Still Matter

Throughout the process of identifying the components, you will still need to think in “pages” because your end user still views your site as pages. You’ll need to look at how the components work together (or don’t) on a given page.

Imagine designing a house room-by-room without considering how the entire structure should work. If you design component-by-component, your project, like the house, won’t be structurally sound. Cobbling together components without a larger sense of context and interaction between them creates a chaotic experience. You will need to evaluate the design of the components in pages for the same reason.

To quickly test your component set, “assemble” the components you have identified into quick whiteboard sketches to try and produce the different types of pages the site will need. You can also do this in a list format if you don’t need to think visually.

Take for example the page formula header+text+video+related links=article page. You can use just the list of your components to quickly identify if you have the complete set you need. Do this first, before you prioritize and begin designing the components. This is a quick way to check your component set to see if it supports all of the new site’s content needs.

You may even need to create more polished page-type guides or formulas for how to use the components in order to give your content creators a guide on how to best use the component set for the site content. Page guides may also have to be created if the content is going to be produced in parallel with the site development.

These assets are also useful as an ongoing tool for site maintenance and governance, by documenting each component, it’s style rules, and the how/where/when it should be used in the site as you go, you build a useful guide for training and maintenance.

In Summary 

The transition to component-based CMS platforms is an evolution of the current approach that offers a lot of flexibility, functionality re-use, and efficiencies for a web project. The same best practices, an informed discovery, and a solid content strategy are even more critical. Keys to successful projects focus on a content-first approach:

• Component-based sites support the flexibility to define pages from multiple combinations of components rather than a limited set of fixed page templates.

• All web site projects should be content-first, especially component-based projects.

• To do a content-first approach, your project must include content strategy as a foundation.

• Determine your components not just from the current content, but also from the recommendations from the content strategist.

• The content strategist is a mandatory team member throughout the lifecycle of the project.

• Designing the site first, then considering the content later, results in a site that won’t support the content strategy or the business and user goals.

• Test your component set and your site design by “thinking in pages.”

• All the pieces have to work together as your end user still experiences the site in pages.

• Leverage your component definition work as you go to build documentation and training materials.

Beth Bader is a User Experience Director who works closely with content strategists to design and deliver content-first site experiences.

This Old Site→

Anyone who has ever done a home remodeling project knows that you never know what you’re going to find until you start tearing out the walls. This makes it very hard to estimate the actual work involved in a project, since you can’t quantify what you don’t know.

A long-standing website can have many of the same structural challenges as an old house—it’s been managed by different people, with differing levels of skill, over time. Those various owners also had different tastes in décor, so one owner’s beautiful wallpaper is the next owner’s eyesore to be removed or covered up. And change has been made in a reactive rather than proactive way and expedience often wins over doing the right thing. When the roof is leaking, you patch what’s there, putting off the inevitable larger project of replacing the whole thing.  

When we approach a website that has structural, content, and design issues, the expedient thing is to make the easy changes, slap a new coat of paint on, maybe move the furniture around a little, and call it good. But just like our old house, our old website really needs and deserves a thorough renovation. Where do we begin?

What Lurks Inside

Start your redesign project with a content inventory. Just as you don’t know what’s behind those walls until you tear them away, you don’t know what’s on your site unless you do an inventory. Fortunately for us, gathering all that information about a site is something we can do quickly and easily—not to mention more cleanly!—than taking sledgehammer to drywall (or lath and plaster). Run an inventory using the Content Analysis Tool (CAT). In a matter of minutes, you’ll know exactly what you’re dealing with in terms of quantity and type of material on the site. Starting out with that rich set of data--pages, images, media, metadata, word count, analytics information—gives you the bones of what you’ll have to work with in designing the blueprint for your new site.

When you’ve inventoried and started your analysis, layer in your own observations about the content—read it for quality, accuracy, voice, relevance, and all those other characteristics that make good content. (I’ve written elsewhere about conducting content audits, see the Resources page at content-insight.com for a series of articles on the topic.)

Your audit will help you decide what you’re going to keep, what you’re going to remove, and what you need to do with the content to bring it up to your new site standards. Just as in an old house remodel, while you’re in there looking so closely, you’ll want to take the opportunity to clean things up, put in the additional wiring to support current needs and think ahead to expansion—what do you need to build to future-proof your design? Will the structure you’re building support the growth of content and addition of features? It’s cheaper to do the preparatory work now than it will be to go back in later, so take the time to think ahead.

When you’ve done your cleanup and revision, you’re ready to reassemble the site into the new architecture.

The Cost of Poor Communication

Unless you’re a one-person web team, you’re probably working with a group of people who bring other skillsets to the project. Just like on a home project, where you bring in the specialists like plumbers, electricians, framers, drywallers, and painters, you will likely be working with project managers, business analysts, user experience designers, creative directors, and technical folks. Maintaining good, open lines of communication, including documented architectures, content models, and designs is critical to ensuring that the final structure looks and works as it should. If the information architect designs a navigational model that doesn’t map to the actual content or the developer builds templates that don’t support the content model, tearing out and starting over is a much more expensive proposition than making sure up front that everyone understands how the final product is supposed to look and how it will work.

That New Site Smell

Walking into a newly renovated house, admiring the easy flow from room to room, smelling the fresh paint and trying out the new furniture is a great feeling. Launching a beautiful, functional, engaging new website is similar. And just as we need to do regular maintenance on our new home, we need to carefully govern our new site to make sure that it continues to run smoothly and doesn’t accrue ROT— redundant, outdated, and trivial content and features—over time. The ongoing investment to keep things ship-shape will pay off in the long run when the next remodel is just an update rather than a complete teardown.

Migrating Content: Challenges and Opportunities→

I do a lot of content management system migration projects. As the content person on the team, my role is to shepherd the content through the process with the goal of it coming through if not improved, at least not degraded. Often that means arguing against automation. Here’s why.

Migration: It Isn’t Just for Developers

CMS projects are often scoped and staffed as technical projects that can be handled by developers creating automated solutions to move data from one system to another. After all, an enterprise CMS is essentially a database. And so it should be possible to approach it as though it were a database to database migration—map the data fields to one another, do some data normalization, run a script, test and refine the scripts, and you’re done. That’s all well and good if you’re working with highly structured data. Structured data has characteristics that can be programmed against.

But web sites are made up of all kinds of data—some structured, like product data on an e-commerce site; some not, like articles, blog posts, or user-generated content like reviews. Karen McGrane refers to this problem as the war of the “blobs” (unstructured) vs. “chunks” (structured data). 

These incredibly valuable but unstructured blobs of content present a few problems: they’re hard to find in the CMS (think, for example, of an author name that exists only as part of an article), they’re hard to manage, and they’re hard to migrate—particularly in an automated way. These blobs of content are also often the result of years of organic growth of a site, with multiple authors, multiple authoring environments, and no uniformity even within their lack of structure. Theoretically, it should be possible to program against a blob of well-formed HTML, but depending on the all the aforementioned potentialities, that HTML may vary from one article to another even within a similar content set. Perhaps one author is more technically savvy than another and has done a little creative programming to make his or her article look a certain way. Another has used old-style markup or built the entire article as a table. Another has copied and pasted text in from Word and didn't strip out the styles. Writing a script to handle all the possible issues in legacy code and the subsequent cleanup when it doesn't work perfectly can often take as long as it would take to simply recreate the content from scratch, using considerably less expensive resources that your developers.

Even if automated migration was feasible, is it desirable? For one thing, you lose the opportunity to improve the content along the way. You seldom want to migrate a site as-is to as-is, particularly since the reason you’re migrating to begin with is that the old system isn't supporting current needs. And there’s that issue with messy old code to deal with—migrating it without taking advantage of the chance to clean it is like moving into a new house and taking the contents of the old house without doing any organizing or winnowing of your stuff.

Getting Structured

The hot topic in content strategy now is about semantic markup and how to structure content—which has benefits beyond migration, of course. See, for example, Sara Wachter-Boettcher’s book “Content Everywhere” or Cleve Gibbon’s excellent series on content modeling.

As a forward-looking practice, particularly when setting up a new content management system, developing a content model and doing the careful planning of how content needs to be managed for reuse and multi-channel, multi-device publishing, this is unquestionably best practice. But that doesn't address the issue of how we get there from here.

Here, of course, being the legion of legacy websites that are full of unstructured blobs of content desperately in need of review, clean-up, and a strategy for reuse and retention. How do we tackle these metaphorical Augean stables?

Seldom do web teams and content strategists have the resources they need to carefully tend each and every piece of content. And not all of that content may even warrant that type of resource-intensive, high-touch effort. So we need to think about how to be smart and strategic about where to focus. Prior to any migration or cleanup effort, we should be determining the highest value content. Getting to that list may require juggling user needs (determined by metrics and customer feedback) and business needs (content that is critical for conversion or content that has to be retained for legal or regulatory reasons). Some content may be valuable for both user and business reasons but because of its ephemeral nature, such as some types of user-generated content, may not be worth devoting much time to.

Know What You Have to Know What to Do

Any migration project should begin with a content inventory. If you’ve gotten to the point of planning a migration without doing an inventory and audit, stop. Back up and take the time to tackle that all-important step. Before you can make any decisions about what you’re going to migrate and how, you need to know what you have, what format it’s in, how much of it there is. Once you know what you have to work with, the next step is to do a qualitative audit to determine which content, as mentioned above, is worth the effort of migrating to begin with, let alone which should warrants spending time and effort to structure properly.

Once you've determined what you’re migrating and your CMS has been designed to support content modeling (based on your business requirements for management and reuse), what can’t be automated still needs to be migrated. The reality is that that unstructured content will probably have to be done manually. See David Hobbs’ article on what content can be automated and what must be manual. The list for manual migration may be smaller than you think. And even if there is enough structure to enable automation, if the content set is small, it may still be a better investment of time and resources to recreate it manually.

Turning Challenge into Opportunity

If the content audit turned up other issues in your content, such as inconsistent branding or voice or other stylistic issues, take the opportunity to address those in the process of recreating the pages—after all, it’s likely that the most unstructured pages are also the ones most vulnerable to variation, as discussed above. This is why it’s critical that the project was scoped from the beginning to include enough time and resources for the content team. 

Read more on the role of the content strategist in a CMS project.

RTFM→

I recently purchased a new laptop, which came with Windows 8 installed. I’ve been using computers for a long time now. I even consider myself relatively geeky for a non-technical person, given that I spent nearly 10 years working at Microsoft and I do a lot of work with software like content management systems (not to mention being co-founder of a software startup). So I have a tendency to assume I’ll figure it out. I don’t, therefore, ever RTFM (geek-speak for "Read the F-ing Manual").

Even the less geeky among us, though, have been trained to believe that new technology, both hardware and software, should be “plug-and-play,” i.e., we really shouldn’t need to refer to the documentation or search the help file. And if we do, we’re somehow failing as users. Companies have responded by putting less and less effort, it seems to me, into the quality and breadth of their documentation so when we do throw up our hands and go look, it’s seldom rewarded. The expectation is now that the community will provide the support and, indeed, the best and most accurate information is often found in a forum somewhere in the depths of the internet. I have learned more about using Excel, for example, from the various tips and tricks sites out there than I have from the program help.

But back to my Windows 8 experience. Despite the seeming user-friendliness of all the touchable UI bits, I was having trouble figuring out how to do something that seemed as though it should be obvious. After touching/clicking around for a while, I still hadn't figured it out. In all that time spent hunting on my own, I could easily have searched the help. Or could I? Where does one find the Window 8 help? And why doesn’t the search function include Help as an option? To find the help and support file, you have to look at the “All apps” screen, filled with teeny, tiny little icons to find Help and Support.

But I didn’t look for that at that moment. Frustrated, I took the next natural step—I posted a complaint on Facebook. Within moments, someone offered the answer. My problem was solved. Thanks to my community, not Microsoft.

Joshua Fruhlinger wrote an article a few years ago for Engadget called “95 percent of all returned gadgets work, Americans don’t read manuals.” That’s a pretty shocking statistic, but in some ways not surprising. If even those most content-friendly among us (aren’t content strategists supposed to love to read words?) aren’t inclined to read the manual, who will?

The brilliant Joel Spolsky, in "Designing for People Who Have Better Things to Do With Their Lives," writes that “When you design user interfaces, it's a good idea to keep two principles in mind:

1. Users don't have the manual, and if they did, they wouldn't read it.

2. In fact, users can't read anything, and if they could, they wouldn't want to.”

He continues, “The upshot of all this is that you probably have no choice but to design your software so that it does not need a manual in the first place.”

The reality is, though, that not all software (and by software I'm including online apps) can be designed to not need a manual. Sure, maybe we can figure out "Angry Birds," without help, but what about  a complex business app or a site with sophisticated transactional elements? How do we as content strategists help users who no longer (did they ever?) start out by reading the manual? One of the tools at our disposal is easily accessed, ubiquitous in-context help (never mind the designers who don’t want their beautiful pages littered with all those little question mark icons!). Another obvious one is making use of the fact that we’re all conditioned to JFGI (more geek speak, meaning "Just F-ing Google It"). Make search easy to find, and consider when it might be appropriate to use scoped search (i.e., limited to a particular section of the site to keep the results focused). And instead of overwhelming users with long, tedious documentation files, create a series of shorter, focused, easy-to-read tips articles that are quickly scanned and understood.

What are your best tips for helping users understand your app or your site?

Feeling Their Pain→

A meme floating around in the content strategy universe right now is about empathy—how we, as consultants, need to feel the pain and understand the needs not only of the end users of the sites and experiences we create, but also that of the clients who hire us.

I’ve written about this previously—how we are often in the position of being the sounding board for internal frustrations and grievances and the liaisons who help bridge organizational divides. The importance of that ability to listen, reframe, and resolve was the subject of a session at Content Strategy Forum 2012 given by Corey Vilhauer, called “Empathy: Content Strategy’s Hidden Deliverable.” We are accustomed to thinking about the strangers we’ll never meet—the users—and have a defined set of tactics for designing for their needs (personas, customer journey maps, user research, and so on). The clients, on the other hand, are the ones we meet face-to-face and we can serve them (and, ultimately, their customers) best by asking questions, getting to a shared understanding of terms, being clear about goals, giving all stakeholders input, using internal politics as leverage when necessary, and giving them the tools to maintain what we’re leaving them with, whether that’s training, helping them prioritize and delegate, even talking with their management about getting them more resources.

Being Agents of Change

The theme of working within an organization to bring about change was also addressed in Jonathan Kahn’s session “Embracing Your Role as a Change Agent.” Change is hard, there’s no question about that—if it weren’t, there wouldn’t be a need for consultants to help organizations navigate through it. But as Kahn says, “You can’t solve problems without changing organizations” and content strategy work involves systemic change. To bring about change, we need to combat denial, organization-centric thinking (those silos that separate the organization), and make ourselves open and vulnerable. By doing so, we can help create empowered individuals and organizations.

Again quoting Corey Vilhauer, “Empowerment doesn’t happen overnight, but it doesn’t happen at all without some kind of catalyst. That catalyst is often found in the passive act of listening.”

Being Open to Failure

That vulnerability includes being open to the idea that we may fail and honest about it when we do. But as Corey Vilhauer says, “If we go into a project afraid to fail, the project will never begin. Admitting that failure is necessary and unavoidable means that we, too, could fail, and that is a pretty difficult thing to admit to someone who is cutting checks for our work.”

There are many reasons we may fail at achieving the perfect solution on the first try. But we can mitigate that by using the soft skills of empathy and active listening to really understand users’ needs. In a recent newsletter, titled "Empathy, the Web Professional's Greatest Skill," Gerry McGovern wrote “The trend towards greater and greater customer empowerment requires a deeper and deeper understanding of customer needs.” He cited the tactic used by Tomer Sharon, Senior UX researcher at Google, who started “Field Fridays,” regular events designed to get developers out of their comfortable chairs and out into the field to talk to and learn from customers. McGovern quotes Sharon as saying “Some people are just scared of what they'll hear…. They are afraid of failing and of invalidating their assumptions…. It is our jobs (UX practitioners) to help people recognize their assumptions.”

And although we may fail, we learn, we pick ourselves up, and we try again. If we've been open with our clients and established a trusting, empathic relationship, failure can be survived and even help show us the path to success.

Putting the C in CMS→

Previously I’ve written about how a content strategist can play many roles in a project. This is never more true than in a content management system (CMS) implementation project.

Although I once worked on a project in which we combined two corporate sites into one and moved the site onto a new content management system in eight  weeks, that was a rare exception (and a small content set).  In my experience, a content management system implementation project—end to end—can take well over a year and even up to two. And in my experience, the content strategist is present and involved from the first day to the final launch. Or should be, anyway.

A lot happens in that span of time and much of what the content strategist does falls outside what you may think of as typical CS tasks. To illustrate my point, here are just some of the activities that I led or participated in on a recent CMS project: stakeholder interviews, organizational change management, communications planning, content standards development, training, documentation, typical content strategy activities such as content inventory and audit, template and component inventory, tool inventory and audit, content source inventory, content flow diagrams (current and future state), template design, workflow design and implementation, governance strategies for content (including digital asset management), user roles and permissions in the CMS, auto-migration analysis, manual page build, content tagging, URL rewrite strategy, QA, UAT.

If you are part of or are planning a CMS implementation project, advocate for the inclusion of a content strategist to ensure that the content requirements and user needs—both internal stakeholders and external users—are reflected in the project scoping, design, and implementation decisions.

Read more about the content strategy role in a CMS project.

The Long Happy Life of a Content Inventory→

The other day, I spent several hours working on a content inventory. No, not a new one. This is an inventory I initially created almost a year ago. Why revisit it now? Because the project I'm consulting on involves replatforming an existing site onto a new content management system. And like many of these projects, it is a sizable and long project, meaning that the content inventory has a similarly long lifecycle. And the inventory progresses through stages, just as the project does.

I run a content inventory at the start of a project like this to get an initial lay of the land—what are we looking at? How much content is on this site? How is it organized now? Where are the problem spots—orphaned pages, duplicate content, confusing navigational model?

As the project progresses and we start to review the content with the business owners and plan for migration, I add more information. Content owner, review status, migration destination, new URL, and so on. But web sites aren't static, particularly over a period of many months. Content has been added, changed, removed. So as we approach the migration of each section, I review the inventory—comparing it to the current site again, making sure I haven't missed anything, since we'll use that same spreadsheet as our map to the new site. The inventory, now generally referred to as an index, will also be used by the production team, developers, QA team, and user acceptance testers to check that everything that was meant to be migrated made it to the new site and that new structure is correct.

Deliverables by the Pound→

I did some freelance work once, as a sub-contractor to an agency, and joked that what I was hired to do was produce deliverables by the pound.

I never met the clients, had only the most rudimentary information about the larger context of the project, but had specific documents (content inventories and taxonomies, mostly) to create. The agency was happy with my work, presumably the documents I created were acceptable to the clients, and I got paid, but the experience was less than satisfying professionally.

Early on in my content strategy career, I created a set of questions when asked to create any project deliverables: 

1. Who is the audience?

2. What is the context into which this fits? and

3. What decisions are going to be made based on this?

Essentially, these address the users and context pieces of the content/context/users triangle. If I couldn't answer all three of those questions, I didn't start work until I knew.

Too often, we embark on a project with our set list of deliverables (particularly true in consulting environments), often put into a project plan by a project manager who may or may not know what purpose they serve, we create them, hand them off, and hope that they are useful to someone.

I am a firm believer in the value of the kinds of deliverables we create as content strategists—content inventories, audits, content matrices—but not every project requires every one of them and I know I'd rather spend my time adding extra value to the ones that will truly inform the recipients and help answer the critical questions involved in the creation of a great user experience. Definitely beats creating deliverables by the pound.

Lead, Follow, Or...→

So your company has decided to hire a consultant. Somewhere in your organization, the people with the power to make these decisions have recognized that you need help. You're probably taking on a big project--a redesign, a site replatforming, the implementation of a big new enterprise software package--and you either don't have the skill set in-house or need additional resources to make it happen. 

So now what? Now, you need to let the experts do what you hired them to do. Too often, between the time when the decision was made to bring in outside help and the actual arrival of the outside help, a feeling arises in the organization. A feeling that's maybe a little bit resentment ("Look at how much we're paying these people!") or a little bit defensiveness ("It may be a mess, but it's our mess"), but in any case, a feeling that can subtly pervade the project and over time undermine the working relationships between the in-house project team members and the consultants. 

It may be hard to accept that the consultants work a different way than you do ("But as an organization, we've embraced the X methodology") and maybe the deliverables are in a different format ("We always put that kind of document in Excel"), but stepping outside your comfort zone, taking a little leap of faith (after all, you did carefully vet this company before you hired them, right?), and opening up to shared learning will go a long way to helping ensure a successful project.

Who Owns Your Project's Vision?→

Think about a current large-scale project going on in your organization. Who owns the vision? Is it the project manager? The program manager? The executive sponsor? The stakeholders? All of the above? Or none of the above?

Years ago, a few forward-thinking people in an agency I worked in created the concept of a "vision lead" for projects. The concept was that this person might play any role on the project, from creative to user experience to delivery management to development, but would be charged with carrying the torch for the vision—not the strategy, not the tactics, not the goals—the vision. That person would essentially be a proxy for the end customer of the website, feature, or application. That vision lead would be constantly asking, on behalf of that customer, "Are you giving me what I need? Or are you giving me what you think I need? Or what you think you can build?"

There are inescapable realities in every project—time, budget, resources—that make it necessary to limit scope or compromise on features. But when ownership of the vision is decentralized and no one person is responsible for seeing the forest rather than the trees, it's easy to lose the way and end up delivering something that may meet the budget and the schedule but loses the spirit.

Consultant, Diplomat, Therapist→

Of all the skills a consultant brings to the table, sometimes the actual discipline for which you've been hired is the least important.

I have been a consultant, first in an agency, then on my own, for five years. In that time, I've worked in a number of companies, from non-profits to Fortune 100s. When a company brings in an agency or consultant, it's usually because they don't have the available resources or the skills in-house. What may surprise though, is how often that skill gap is not in technical skills or design skills or project management and delivery—or is not only in those, anyway—but in communication. Often I have been in the position of introducing one member of a company to another member of a company—literally being the liaison who makes the connections between organizationally separated (and sometimes even geographically separated) teams with common interests and need for shared outcomes but no organizational structure or incentives for collaboration.

Sometimes those distances are enforced by the virtual walls that silo different areas of an organization—IT from marketing is a typical example. Take a legacy of non-communication, add a failed project or two (refer back to that non-communication), and an ever-widening gap of mistrust opens up within the organization and the consultant ends up being the diplomat who helps the factions reach a successful resolution.

When one area of an organization feels under-represented at the table and is stuck working with outdated tools and processes, another important role a consultant can play is to simply listen. I have spent many hours with employees who are just grateful to have someone to describe their situation to and finally feel as though they've found a sympathetic ear. My job, of course, is not just to listen, but to document and plan and work with the other side as well as my consulting colleagues to create solutions that address not just the technical or procedural issues but the communication issues within their companies. When a client cries to see you leave at the end of a project, you know that consulting is as much about organizational psychology as it is about implementing new features, tools, or websites.

Psst! Wanna Hear a Secret?→

Over the past few years, seemingly out of nowhere, there has arisen a new discipline devoted to the concept of having a strategy around th content on your site or in your publication. There are conference devoted to content strategy, books being published, blog posts bein written, and careers being built around it.

But here's a little secret for you. Ready? Content strategy is nothing new.

Shocking, isn't it?

The fact is that the very same goals—putting the right content in front of the right audience at the right time—were just as valid in an analog as a digital world. In fact, when you think about it, storytellers in the oral tradition spinning yarns around the campfire had to be just as conscious of who their audience was, what the audience wanted to hear, and how it could be presented in the most engaging and memorable way.

Think of your favorite book or magazine. For that publication to exist, someone had to

• Identify an audience

• Select a topic/theme/point of view/personality

• Source or develop content

• Work with designers to make it the presentation attractive and readable

• Determine length, format, presentation of the stories

• Make content easy to find (add a TOC or an index)

• Oversee production

• Publish it

Sound familiar? Change magazine to website and you have the breeding ground for a whole new crop of people who now have a spiffy new title. But some of us have been doing it all along.