AEM Documentation Journeys

Documentation Journeys provide a narrative structure within AEM documentation by tying together complex and disparate features in order to solve a business goal in a best-practices fashion. Designed with AEM beginners in mind, journeys introduce the concepts and features to achieve a goal from A to Z.

What is a Documentation Journey?

A Documentation Journey ties together many different and complex topics and features by providing a narrative that helps the reader, who can be new to AEM, understand and solve a business problem from beginning to end, while assuming minimal prior topic or AEM knowledge.

Documentation Journeys contrast with AEM’s existing technical docs that primarily focus on a single feature and documentation of tasks, assuming familiarity with AEM. By focusing on the concepts and deferring in-depth details to the existing technical documentation, Documentation Journeys give readers new to AEM a place to begin understanding how the platform can be leveraged by using best practices to address common business needs and workflows. For this reason, Documentation Journeys serve as a complement to and not a replacement for AEM’s existing technical documentation.

Learning By Narrative

AEM has a rich and powerful feature set that can be overwhelming to new (and sometimes experienced) users. By starting each journey with a clear business objective rather than technical requirements, a journey tells a narrative leading the reader through the AEM concepts and features that work together to achieve the business goal.

By telling a story, the reader better understands how different parts of AEM work together to solve the problem at hand and perspective is maintained. Thus the reader can see the business objective forest for the feature trees.

Focus on Concepts not Features

To maintain focus on the narrative, Documentation Journeys emphasize concepts in AEM instead of dwelling on technical features. Recognizing that it is more important that the reader is familiar with how AEM solves a particular problem rather than worrying about which checkboxes to click, the journey keeps the reader moving forward through the narrative, illustrating how to link together multiple important concepts so achieve the overall goal.

Journeys ensures that the reader knows how AEM can solve a problem instead of worrying about each option to click. If the reader wants to take a deeper dive and learn more technical detail or what additional options can do, every part of the journey links to related, exhaustive technical documentation.

Best Practices Orientation

Documentation Journeys are designed around best practices principles, informed by Adobe’s latest research, proven implementation experience from Adobe services, and feedback from customer projects.

If you want to know how Adobe recommends how to solve a business case with AEM, Documentation Journeys are where to start.

How is a Documentation Journey Structured?

A Documentation Journey serves as a best practices-based introduction to how AEM solves common business problems. For this reason, each journey is designed with readers new to AEM in mind, laying out the business problem, describing any necessary theory, and then giving a step-by-step overview of how AEM solves the problem. Because of the comprehensive nature of a journey, it can be useful to readers new to AEM as well as experienced users.

A typical Documentation Journey has the following parts.

  • Overview of the goals of the journey and the intended audience
  • Description of business problem
  • Description of any theory necessary to solve the problem
  • Prerequisites and requirements
  • Description of intended audience
  • Implementation steps

A Documentation Journey’s goal is to familiarize the reader with the basics of how AEM uses different features and tools to solve a single business problem. For this reason, the implementation steps illustrate the most common usage patterns and most important features and options. Detailed configuration options are linked to in the technical documentation for further reading.

Who Should Read Documentation Journeys?

AEM Documentation Journeys’ main goal is to help readers new to AEM understand how many different and powerful features of the system can be used together to solve common business problems by way of a narrative.

So if you are new to AEM and have a specific business case in mind and want an overview of how AEM can solve it, Documentation Journeys are where you want to start.

However there are many different types of AEM users with different needs and expectations. For example:

  • Administrators
  • Developers
  • Content Authors
  • Translation Specialists
  • Content Architects

Each journey begins with a clear statement of the intended audience for the journey. Because no one works in a vacuum, when the reader requires the assistance of input of a system user or persona, this is clearly explained within the journey.

How do Documentation Journeys Fit into AEM Documentation?

Documentation Journeys are intended as a complement to existing AEM technical documentation and tutorials. For example, a journey may introduce you to a concept, and then the technical docs explain the detailed configuration options you may need and a tutorial guides you through specific setups.

Documentation Type Purpose Audience Assumes Omits Content Type Length
Documentation Journey A journey defines how AEM can solve a general business problem through a narrative that guides readers through complex, interrelated processes and features. It illustrates how multiple features work together to solve a business need in a best practices fashion. Readers new to AEM General CMS familiarity Detailed options and configuration Text Ca. 1 hour
Technical Docs Technical docs focus on individual features, detailing the technical workings of the feature and every option available to the user. Experienced AEM users AEM experience Context and background Text Varies
Tutorial A tutorial is an in-depth dive into a topic showing a developer or admin how to achieve a technical goal (generally programming or system configuration) in a step-by-step fashion, providing specific examples and example code, usually leveraging a limited set of features. AEM developers or administrators AEM experience Background and theory Video >1 hour
Getting Started Guide A getting started guide is a lightning-fast walkthrough of a specific new AEM feature. It is a quick overview of an individual feature, leading the user through the important (but not all) steps to configuring and using a simple use case. AEM Admins AEM experience Background, theory, detailed options Text <1 hour

What Journeys Are There?

There are a number of Documentation Journeys already available to you. Since each journey is designed as a narrative, please start with the introduction and read all the way through in order to get a full understanding of the topic in the context of AEM.

Journey Description
Headless Developer Journey Start here to see how AEM supports headless development models and how to get your project started from planning, to implementation, to go-live.
Headless Authoring Journey Start here for a guided journey through the powerful and flexible headless features of AEM, their capabilities, and how to model your content on your first headless project.
Headless Architect Journey Start here for an introduction to the powerful, and flexible, headless features of Adobe Experience Manager as a Cloud Service, and how to model content for your project.
Headless Translation Journey Start here to see how to set up and manage your headless translation projects in AEM.
AEM Onboarding Journey Start here to get up-and-running quickly with your new AEM as a Cloud Service environment!
AEM Quick Site Creation Journey Start here for a guided journey through the simple-to-use AEM Quick Site Creation tool to streamline the front-end development of your AEM Site and quickly customize your site with no AEM backend knowledge.
AEM Commerce Journey Coming Soon!
AEMaaCS Migration Journey Coming Soon!

Check back for more content as new journeys become available.

On this page