Please use for the latest documentation.

This site is for reference purposes only and may not be accurate for the latest ServiceNow version

Content Management Best Practices

From Wiki Archive
Jump to: navigation, search
Note: This article applies to Fuji. For more current information, see Content Management System at

The ServiceNow Wiki is no longer being updated. Please refer to for the latest product documentation.


Best practices and good intranet design go beyond the Content Management System (CMS). Key considerations include limiting team size, placing talent where appropriate, and establishing clear lines of communication. Some of the most successful CMS projects are built on good communication and clearly designated ownership. Best practice should speak from the voice of experience, as the actual act of launching a website is the best teacher. It is important to note that not all design needs may be addressed on the first try, but through revisions you can continually improve your CMS.

Best practice should also place a strong focus on the application data you intend to use within your site. Take a look at the CMS data integration portion of the wiki. The integration page is a good introduction and can provide you with ideas for bringing data into the system.

Read through the case studies as well. Each study breaks down the chronology, business needs, time, and manpower associated with each web project.

This Best Practices page is the first step in defining a methodology for delivering the highest quality CMS site in the shortest period of time. The fundamental prerequisites for design in the CMS are:

  • Researching what good and useful intranets contain and what information they provide.
  • Understanding the ServiceNow system and what areas of system data you plan to use.
  • Setting expectations and deliverables based on the resources you have

Along with the ServiceNow wiki, you may want to do some extended research on usability. For example, the Nielsen Norman Group has spent years focusing on usability and their annual intranet design report may help you with design decisions:

You should not plan on launching a CMS site as part of your ServiceNow Phase 1 deployment. Many considerations need to be addressed before starting to work with the CMS. Initially, the structure of the website is defined within the CMS application, but the majority of the work exists in other applications.

Planning and Required Research

Planning and prototyping is the most important phase of website design. In this phase, start with the data you plan to use. The team should define the following:

  • what services the site will provide
  • the common actions and data needed by site users
  • how the data will be consumed and navigated by users

Knowing the data structure you are designing for is important and will prevent superfluous customizations or the creation of unnecessary database tables.

This phase focuses on the language, concepts, and organizational hierarchies of the website instead of the design. Language and content define look and feel, not vice versa. The team should also evaluate the naming conventions used in the CMS and in the organization. Consolidate and combine names when possible.

Planning Checklist

  • Read the Content Management System pages of the wiki so you understand how the system works.
  • Determine the business needs the website must fulfill and consider the return on investment (ROI).
  • Interview the user base and compile a cohesive list of requirements that may be mandated by sites in current use.
  • Identify the ServiceNow system data that will be brought into the CMS site, as well as data from any other sources.
  • Use the content and data definition to establish a rudimentary site map and entry pages for the site.
  • Establish consistent site language and terminology by using an existing organizational style guide or creating a style guide if necessary.
  • Use categorization and hierarchies to create a consistent navigational model.
  • Address these related questions:
    • Is site translation or localization a requirement?
    • Will there be user or employee-contributed content?
    • Will commenting features be used?
    • Would ratings and feedback be useful?

CMS Content from System Data

A website is only as good as the content it provides and how accessible the information is to users. Before building a website in the CMS, understand the data behind what you are building. While staying organized within the CMS is important for long-term site maintenance, most data will probably live within other applications in the system. For more information, see Content Management Integration Points.

As a CMS site manager, communicate with the people who are administering your knowledge base, service catalog, business service portfolio, and any other system data accessible through the CMS site. It is difficult to design for data that is not in place. Therefore, data within the instance should be at a mature point before the CMS site is designed.

  • Look at the instance and the ITIL processes that will be implemented in the CMS site. Ensure that the data within the system is at a level where it represents a clear vision of the applications to be built (for example, service catalog, knowledge management, and incident management).
  • Ensure that the hierarchies and categories in the system (for example, the topics and categories in the knowledge base or the categories and subcategories in the service catalog) are logical and will be in place for a reasonable amount of time. These categories are very important when designing the entry page into the knowledge base, service catalog, or any table within the system.

One of the biggest challenges is organizing the content so the interface is usable. The organizational process depends on what data is going to be used in the CMS.

Some of the best lessons learned from the launch of the ServiceNow corporate website were about data and where data lived. Knowing the data helped us understand who was bet suited to perform long-term maintenance of the site. The requirement that maintenance should be as easy as possible made it clear that administrator skill sets should be matched to the application where the data they manage lived. Once the initial design was created, very little work was done in the CMS; most work was in the knowledge management application. Organizing the data often occurred where the data lived in the system. Sites, parent pages, pages, and navigational menus in the CMS site should be a direct reflection of how your data is organized. For example, the catalog has "category" and the knowledge base has "topic" and "category." The following section provides examples of system data used in CMS sites and how base system applications can address some of your most basic needs.

More than Just a Knowledge Base

In the corporate website case study, all of the content lives in the knowledge base. There were a number of considerations that led to this decision:

  • Ease of use - the interface had to be easy to use and easy for employees without technical knowledge of HTML and markup to manage articles.
  • Built-in publishing - basic publishing controls mirrored the lifecycle of the content.
  • Interaction - commentary, rating, flag, and "Was this Helpful?" voting are available when needed.

Generating content, such as HR job postings, news articles, event announcements, customer case studies, and training videos, demonstrated clear parallels to successful knowledge bases. Where there is a service being provided, there is a relational knowledge base to manage the content. Someone may point out that this is not ITIL and not being ITIL could have an impact on sites that purely serve IT.

Best practices factored in because there was a functional fit for the content. Purists would probably create a new database table for every type of content, but this approach would needlessly complicate the data being used. Every piece of data in the site could be managed in the knowledge base. Thoughtfully created topics and categories met the business needs of the corporate website.

The key point was considering where data lived within the ServiceNow application set. This takes significant knowledge of the ServiceNow platform and application set, which is the foundation of best practices. If you have system data that does not obviously fit, think about the relational aspects of the data and how you intend the data to be consumed. Plan on having the majority of the CMS website content managed outside of the CMS application.

Thoughts on organizing content

While creating our corporate website in the CMS, the team worked together, evaluating many of the naming conventions used in the knowledge base. Misunderstandings and assumptions at this stage need to be eliminated by proper investigation into the data layers you plan to use.

Define what application data will be behind the CMS site, down to the database table and field. Do not over-complicate the work; instead, leverage existing parts of the system. Organize the content so the interface is usable. The organizational process depends on what data is going to be used, both in the CMS (sites, parent pages, pages, and navigational menus) and throughout the rest of the system. Start with knowledge, service catalog, and the business services portfolio.

A high volume of content can heavily influence the look and feel of the site and the site hierarchy. When deciding what content to show, keep in mind the realities of long-term maintenance. Design for ease of maintenance and the people who will be taking care of the system. This level of planning can be time-consuming, but is important. Here are some other basic tips on site planning:

  • Start with listing all the content you want to host on the CMS site.
  • Think about current solutions to implement right away and ideas for the future.

Paper Prototypes

The use of wireframes, mindmaps, and PowerPoint presentations to create prototypes is essential. Prototypes are a powerful tool to expedite the design process. Many user interface designers use prototypes because they create a clear line of communication between the designer and the project manager. The task is to create a text-based blueprint of your website with prototypes. If you bypass this step, the project can experience scope creep because of design revisions.

  • Define the sitemap of the entire site, either on paper or digitally, to visualize the site.
  • Define detailed paper prototypes of every intended page, including elements such as links, link destinations, content, page names, and page descriptions.
  • Print out and annotate the prototypes, noting what needs to be done on the different pages within the site.

Resource Planning

Since you determined the data you will be using, you also have an understanding of the content owners. The best insights from the launch of the ServiceNow corporate website were about data, but they translated directly to the people involved with long-term maintenance of the site.

When it comes to resources, quantity does not always equal quality. The number of people added to a project involving site design may not matter. Sheer numbers do not increase productivity and may even stifle progress. The following actions are essential:

  • Limit team size.
  • Place talent where appropriate.
  • Establish clear lines of communication.

These actions can prevent team members from interrupting or duplicating each other's work. The actions can also establish security definitions and role-based views for everyone working on data within the system.

Start with a small, focused team

Before starting work on a website, two groups should be identified:

  • One group gathers corporate style design guidelines, defines all of the copy (written terminology and text that will exist in the site), and defines the site flow. This is a content management group with skills that include:
    • Knowledge of organizational and industry-specific language
    • Ability to write clearly and concisely
    • Information architecture for planning site layout and navigation menus
    • Connections with subject matter experts (SMEs) from Marketing, Sales, Training, and other departments, to keep content updated
  • The second group executes the designs and creates the website. They also create templates, icons, and graphical elements. This is a webmaster group with skills to maintain a working website, including:
    • Basic ServiceNow administration skills
    • HTML
    • CSS
    • Graphic design and web design
Reach out to your corporate design team

Leverage the corporate designers that own the style design guidelines. In many cases, the look and feel of your site is dictated by a style guide. Style guides are often lengthy, detailed, and pertain to any corporate interface.

  • Many organizations have an art team that designed the organization's website. Contact this team and involve designers early. They can help and give the interface their approval. Without approval, you risk having to redesign the entire site because it does not adhere to organizational guidelines.
  • Corporate style guides take the guesswork out of design. The example style guide shown is defined down to the pixel. Creating a site without following the style guide takes a great deal of time. With the style guide it is easy to create clean CSS and HTML for the site.
  • Forms may require some modifications to style guidelines. The content area of any CMS design should be no smaller than 860px or service catalog forms will be clipped. (The sample style guide shown calls for the content area to be 576px, which would clip those forms.)


The base system site template, the ESS portal, illustrates how the platform can be themed to match corporate branding guidelines.

Base System Resources

The ESS portal is a simplified working example for customers to use. Rather than editing the base system examples within content management, we suggest that you make copies of the sites, pages, themes, and blocks. Then, modify your copies. This ensures that you can leverage the base system updates that will be rolled into future releases of the content management plugin.

If the ESS portal meets the business needs of your project, copy the portal and use it as a reference guide to your new site. If you need to do a great deal of customization, helpful pages include Creating a Content Page, Using Content Blocks, and Styling in Content Management. Light customization would be changing the logo, adding a few links to the menu, and changing the colors of the tables and menus. Heavy customization would be altering the layout, changing the menu system, or editing anything within the content area.

Icon-based menu interface similar to shopping sites and modern operating systems. Uses a menu and imagery based experience that guides user navigation within the system hierarchies.
Icon-based menu interface similar to shopping sites and modern operating systems. Uses a menu and imagery based experience that guides user travel within the hierarchies defined within the system.

Visit Other Websites

Has anyone else already created your portal? Sometimes you can get good ideas by looking at the work of others. Our ESS portal was based on common designs throughout the ServiceNow community. There are many ways to organize and present data so it is easily accessed.

For customer examples, view this ServiceNow community blog.