A Web Content Management (WCM) Functional Design (FD), or specification, can improve your implementations by translating graphic design (wireframes and mockups) into WCM functionality while ensuring a content author-friendly setup. This design make projects smoother by confirming project scope, standardizing terminology, and getting stakeholders to sign-off on the project. The design explains the "what" rather than the "how."

Purpose of this Guide

As a Tridion Sites customer or professional, it's important to recognize the elements of a Tridion Functional Design or CMS specification. This guide gives an overview of typical elements for this documentation and briefly explains why the sections are important.

Overview

The Tridion Functional Design (FD) describes your website features and visual design as well as how the implementation team will set up the Tridion Sites building blocks, including:

• Publications, the general main "folders" or organizational items
• Schemas, the content definitions for authoring forms or components
• Regions, the definitions that control how content can get added to pages
• Component Templates, the (now optional) selections authors choose from to change how content appears on pages
• Page Templates, the selections authors choose from to change how pages appear on sites
• Folders, the Tridion folders that store content, including multimedia
• Structure Groups, the special folders for pages
• Taxonomy (Categories and Keywords), for classification and tagging of items in the CMS as well as retrieval in the website(s)
• Bundles, for workflow and managing multiple components or pages

The FD describes what the WCM implementation team will build, but not necessarily the technical details or how to build it.

Sections

A good FD answers the reporter questions of "who," "what," "where," "how," and "why."

Who?

Who has access to the system and how are they authorized to use it? Will the system include automation or processes to make the system easier-to-use for these users or authors?

What?

The Content Model has two parts. The website relationship between Page Types, Regions, and Content Types is based on your design team's wireframes, graphic mock-ups, or other interaction design material. These translate into the Tridion Sites-specific items including Schemas, Component Templates (if applicable), Regions, and Page Templates.

The FD should include website details to help clarify scope, explain website behavior, cover nonfunctional requirements, and define the setup for Experience Manager, the in-context and inline editing GUI.

Where?

There are two parts to this question:

• Where can authors find information in the WCM system?
• How does this translate to navigation on the websites? Where do pages and content live?

These two are related but can differ according to website, content, and page needs.

The FD should also include a description of the Tridion BluePrinting design, which is the relationship between Tridion's top-level repositories or Publications.

When?

Not called out separately in the above diagram, but the question of when is important to requirements related to sequences, time-of-day, and automation. For example, a FD will may include diagrams to explain the steps in workflow or a description of what automatic actions should trigger and when.

Why?

A section in the FD should at least reference content strategy documentation such as your content inventory (also known as a content matrix or content audit), a summary of content, pages, and documents for your sites include.

Why Does an FD Matter?

Two reasons make an FD important to your WCMS projects:

1. Confirming Scope
2. Avoiding Technical Debt

Confirming Scope

Since the FD covers what the implementation will build, it guides several important parts of your SDL Tridion project including:

• How the WCM system will function including how many types of content authors can create, how difficult the forms will be to fill out, and how inline editing (Experience Manager) will work
• What's out of scope
• What the pages should look like

Avoiding Technical Debt

An invisible but significant cost to skipping an Functional requirements is an improper content model. Too often, organizations new to WCM systems or Tridion Sites underestimate the impact schemas, fields, content, and templates have on authors. Having unnecessary schemas and fields can create tangible business costs as seen in the following example.

In the above scenario, near-duplicate schemas create an invisible burden on authors as well as on developers. This would include:

• Development would need very little time to set up more schemas, but templates could include a linear cost (possibly reduced by copying and pasting code)
• Authors may take additional time to select the correct type of content (schema)
• Increased maintenance, training, and testing for more variations of content and how it is used across websites

The above example is simply illustrative, more schemas is not necessarily a bad WCM design choice.

The biggest impact to a poor content model is resistance to the technology or worse, the implementation team, especially when issues can be avoided by taking a collaborative approach to WCM design and development.

More About the FD

This guide explaines the what and why of the Functional Design itself. Let's wrap up by addressing questions you might have of the documentation itself.

• Who writes the FD? The FD is a collaboration between business, subject matter experts, and especially business analysts (BAs). Just like other Functional Documentation, these are written by BAs with input from the business, technical teams, and architect. SDL Tridion Sites-specific FDs are typically created in collaboration with RWS Professional Services, a partner, or independent consultant.
• Where are FDs created? We start with remote or perhaps onsite discovery sessions followed by "offline" time to diagram and write details as well as review and make updates as needed.
• When should we make an FD? For large implementations and when following a more phased (waterfall) approach, start the FD before actually programming your next Tridion project, this typically falls under the "design" part of the project and takes in the BluePrint design as an input. For more agile implementations, confirm critical decisions up front such as the BluePrinting setup and organizational details, while designing and building-end-to-end page types and content types in a more iterative fashion.
• How do we write an FD? The tools and format are up to you, but the process should start with an understanding of your content model as well as Tridion Stes functionality. Training is highly recommended before creating a Functional Design. It's important to understand a system and your requirements before attempting to design for either.

Summary

By explaining the "what" rather than the "how, an Tridion Functional Design (FD) can improve your implementations, ensuring a user-friendly setup based on your website graphic and interaction design. Use the FD to confirm project scope, standardize terminology, and get sign-off on the project.

Update (2023/02/07): I updated the product name, rephrased some parts, and added a note about agile implementations.