Cross-Functional End-to-End Delivery Process

Before diving deeper into AEM authoring itself, it's helpful to understand how content creation fits into the wider delivery process across multiple teams.

From a content authoring perspective, the workflow ensures that content is accurate, correctly structured, aligned with design intent, and optimised for usability before it reaches end users.

Content authoring typically sits between development and QA, translating business requirements and design specifications into real, publishable experiences. At this stage, content teams configure components, populate pages, manage assets, and validate SEO metadata while ensuring everything functions correctly within the platform.

Although authors focus primarily on building and managing content within AEM, that work exists within a broader cross-team delivery lifecycle involving design, development, testing, and stakeholder validation.

A typical end-to-end delivery process for a project looks like this:

1. Design

Purpose: Define how the experience should look and behave.

• UX wireframes
• UI mock-ups / prototypes (e.g. Figma)
• Accessibility considerations
• Stakeholder review & sign-off

2. Development

Purpose: Build what was designed.

• Frontend implementation
• Backend integration (if required)
• Component and template creation
• Environment setup (development and staging)

3. Authoring

Purpose: Add real content into the built system.

Before authoring begins, the Merchandising Manager documents ways of working and ensures required guidance - such as how-to documentation, checklists, and standards - is available in a shared location for the authoring team.

Typical authoring tasks include:

• Uploading images and media
• Configuring components
• Setting up SEO metadata
• Configuring dynamic content

4. Self-QA

Purpose: Authors validate their own work before it moves to formal QA.

• Compare output against design
• Test responsiveness across devices
• Check content accuracy
• Test forms, links, and buttons

5. Formal QA

Purpose: Validate functionality, design, and content before UAT.

Many checks overlap with Self-QA to ensure a second review and additional validation.

• Functional testing
• Cross-browser testing
• Device testing
• Link testing
• Accessibility testing

6. UAT (User Acceptance Testing)

Purpose: Confirm that the feature works for real users and stakeholders.

Testing here often mirrors previous steps to ensure the experience aligns with business expectations.

• Business team testing
• Stakeholder validation
• End-to-end testing
• Real-world scenario validation

7. Live

Purpose: Release the experience to the production environment.

• Deployment to production (completed by the development team)
• Monitor logs and analytics
• Track errors
• Monitor performance
• Validate real-time functionality