Gathering requirements for a successful AEM implementation

Gathering requirements for a successful AEM implementation

I have been writing business requirements for web-based portal applications for years now, but writing my first requirements for an AEM implementation was a learning experience.

The first thing I would suggest is that any Business Analyst who is writing requirements for an AEM implementation should understand how AEM works, including its features out of the box and the role of components, templates, workflows, and the other features that make AEM a powerful tool with great potential.

Learning about AEM helped me provide better guidance to clients and to talk AEM jargon with my dev teams. Beyond understanding the platform, there are several other things you can do while gathering requirements for AEM that will help ensure better final results.

(BYBA) Bring your Business Analyst from Day 1

Bring your Business Analyst in on day 1 of your project. Your Business Analyst will serve as your guide; they should be someone who understands your business and who has a good understanding of the potential of AEM.
I have worked with clients who were implementing AEM for the first time and were not aware of the full potential AEM.

That lack of knowledge about the platform was causing them to recreate their legacy CMS using AEM. Working with a team of AEM Architects and an AEM Business Analyst helps our clients not repeat history, instead of helping them to move toward a better future.

As a Business Analyst, I always ask clients what they want to achieve with a specific functionality; they might have an idea of how they would like it implemented, but the real question is what do they want?

Download Blue Acorn iCi’s “Amplify the Customer Experience with Analytics” whitepaper to learn how you can use analytics to enhance the entire customer journey.

Know your site from a 30,000 foot view

Understanding your high-level requirements before you begin the design process will help you keep your project on time and budget.

For example, you should know:

Get Those Functional Specs as the Design Develops

Writing up functional specs during the wireframe/mockup process saves a lot of time and avoids any confusion as to what is expected out of the site. You’ll want to define any transitions you’ll need, the global elements that will apply throughout the site, and the types of templates you’ll need.

Transitions

Any transitions needed within the site should be part of the final designs. If you are building a responsive site with mobile-first in mind, make sure you have wireframes for all breakpoints and identify functionality for each breakpoint.

Global Elements

Identify your global elements that are consistent across the site. These global elements can be inherited using parsys with a template.

Templates

Identifying what’s different on each page of site will help identify templates needed for your site. Think of a template as a canvas that you can draw on; depending on your needs, a template could be an empty canvas or a template could be like a coloring book, where you have predefined outlines and all you have to do is add color to it.

Don’t Forget Your Content Authors

When writing requirements we spend too much time on end-user experience, identifying minute details of how a site visitor will be interacting with the site on various platforms and devices, that we forget the most important user in AEM—I am talking about the content author.
Content author requirements are as important as the site user experience, so always keep the author in mind when documenting requirements.

One of the main reasons any client switches from a legacy CMS to AEM is the lack of flexibility and frustration when authoring, so ensure you discuss author experience when talking about components, templates, and other areas within AEM.

If you need help optimizing or implementing your AEM solution, we can help. Reach out to our team today.