The Design Breakdown Showdown

Deciphering the communication gap while defining your components for AEM

Throughout various projects, I’ve witnessed designers, developers, and content authors debate over how to break down a design layout for usage in AEM (Adobe Experience Manager). The designer argues the user experience gets sacrificed in order to consolidate the component library, the developer argues the amount of complexity will take too long to build, and the content author argues they want more flexibility without it being too difficult of a process to manage.

In many cases, these arguments stem from each role’s perspective on what elements make up a component. Their interpretations can have a direct effect on both the development workload and content authoring process. Designers and developers may be using the same “component” term, but there needs to be alignment between a UX definition and development implementation definition on what goes into a component.

What is a component?

A component in AEM is defined as a grouping of elements that can be dragged into an editable template with author configurations that format and render your site’s content. How these elements are grouped can be based on the component’s intended purpose or functionality. AEM component development is built upon the idea of separation of aesthetic vs. functional. There are requirements that drive what to display (dynamic or static content) and then there are requirements that drive how to display (visuals and branding).

UX-defined component

From a designer’s perspective, delineations for components are typically based around visual differences and business purpose. For example, a grouping of elements fixed at the top with a logo, navigation and search used on multiple layouts may be a single header component; a grouping of elements that showcase a teaser of text with a large product image at the top of the page may be a hero banner component.

Designers utilize Atomic Design methodology to build out a component library based on re-usable UI elements and the relationships between these elements. This allows for reusability across templates while contributing to a cohesive brand experience. Ideally, the design layout aesthetics and UI behavior specs are documented for hand-off in a component guide.

However, this grouping of elements may differ from the developers’ understanding. Once consideration is made for author inputs and how the content is pulled in, the development effort increases and in turn, could complicate the content authoring process.

Here, what UX may define as a simple Tab Component becomes much more complex once it’s realized the content author will need to configure the number of tabs, the text for each tab, the icon for each tab, the number and size of columns in each tab section, which components go in those columns and then the text/images for those components itself.

Server-side defined component

From a developer’s perspective, delineations for components are typically based on the complexity of functionality, how content will be pulled in, author dialog options and policy configurations. Visuals will either be consolidated based on the similarities in author functionality or broken out based on complexity.

In the case of a header component, it would be broken out for function-specific development such as the utility navigation, search, logo, and navigation. These UI elements may not be edited by content authors, but development effort will be to make the logo image configurable from the DAM, the navigation to be auto-built based on the site architecture, and the search function to pull relevant content throughout the site and possibly provide auto-suggestions.

Core components and OOTB components, such as an image, title, and description, are used as building blocks throughout the site. They provide a starting point to reduce development time, do not have to restrict the designers to limit their work strictly around that list. Essentially, a server-side defined component can be re-used across multiple UX defined components but usually is not brought in as itself (except in perhaps the case of a title or text component used in article pages).

The red outline represents a UX defined component, or what a content author may drag onto a page. The green line represents where the development delineations are made and how the code will be organized in CRXDE.

In the case where there may be the same author input fields, and the visuals are similar enough, a single set of HTML can be used with CSS to trigger the different aesthetics, utilizing the style system capability in AEM. Back-end development can use a single component with the front-end handling the visual variants. The author selects a dropdown to choose between the styles provided, and a single CSS body class is toggled to display each variation.

Here visual variations can be consolidated into a single component because they require the same author input — Image, Title, Text, CTA and CTA Link. The author then selects in a dropdown which style variant to use. Using the style system provides built in UX Governance and simplifies both the authoring process and development effort.

Determining how a full design layout breaks down into specific templates and components for AEM doesn’t have to be a battle in the conference room. While a UX designer is creating their component guide around aesthetic delineations, the developer is looking at complexity around functionality and author inputs.

Making time to facilitate these discussions can drive efforts to reduce development time and simplify the authoring process. By understanding what a component is, how designers perceive a component, and how developers and content authors interact with a component, we can successfully deliver a full experience that can continue to be easily managed by all teams.