Do You Know What's in an SDL Tridion Functional Design?

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

Purpose of this Guide

As an SDL Tridion customer or professional, it's important to recognize the elements of an SDL Tridion Functional Design or "FD." This guide gives an overview of a typical FD and briefly explains why the sections are important.


An SDL Tridion Functional Design (FD) is document that describes your website features and visual design as well as how the implementation team will set up the SDL Tridion building blocks, including:

  • Publications, the general main "folders" or organizational items
  • Schemas, the content definitions for authoring forms or components
  • Component Templates, the 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 for content
  • Structure Groups, the special folders for pages
  • Categories and Keywords, for classification and tagging
  • Bundles, for workflow with 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.


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


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?


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 SDL Tridion-specific items including Schemas, Component Templates, and Page Templates.
Be wary of an FD that skips the website details as these are important to confirm scope, explain website behavior, and help set up Experience Manager, or SDL Tridion's in-context and inline editing GUI.


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 SDL Tridion BluePrint design, which is the relationship between Tridion's top-level folders or Publications.


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 will trigger when.


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 SDL Tridion 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 SDL Tridion Functional design is an improper content model. Too often, organizations new to WCM systems or SDL Tridion 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 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 component-to-template variations

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 overviewed 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. SDL Tridion-specific FDs are typically created in collaboration with SDL Professional Services, a partner, or independent consultant.
  • Where are FDs created? This typically this starts with onsite discussions followed by offsite time to diagram and write details as well as review and make updates as needed.
  • When should we make an FD? 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.
  • 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 SDL Tridion functionality. The SDL Tridion Business Analyst track is highly recommended before creating a Functional Design. It's important to understand a system and your requirements before attempting to design for either.


By explaining the "what" rather than the "how, an SDL 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.