The Problem

Adobe Experience Manager (AEM) has powerful features and has the ability to create multiple webpages on one instance of the platform.  This gives Designers and Content Authors incredible flexibility to create designs and content when needed with minimal support from Development.  However, this is not always easily implemented as designers and authors often run the risk of:

  • Designing pages in isolation
  • Duplicating components and non-shareable code – thus a bloated the AEM system
  • Creating silos of independent designs and webpage messaging

The problem in a nutshell is that one AEM Design System Language did not exist.

The Solution

  • The solution was a design system, based on Atomic Design principles that grouped common elements into one cohesive Design System Language (DSL).   The creation of a consistent and designer-author-friendly AEM component library was critical to the success of this DSL
  • This solution would allow Designers and Content Authors to quickly and effectively build out and edit new websites, apply style and authoring, without touching the AEM core components

THE GOALS

  • Establish a common UI & authoring language, using AEM components as the linchpin
  • Streamline the AEM Component, Experience Fragment and Page Template structure
  • Improve the UI quality and brand consistency of the website

THE CHALLENGES

  • The website UI Design was dated, inconsistent and lacked clear brand guidelines.
  • Component structure was haphazard, duplicative, and lacked design and use case consistency.
  • Lack of Brand Consistency.
  • Need to conduct an audit of AEM components and determine whether to retire, use, refurbish or create new components.

MY ROLES

  • Conduct an AEM Component Audit; Document inconsistent, obsolete, ineffective AEM components and Experience Fragments, as well as identify opportunities for component improvement.
  • Define AEM component needs based on UI designs.
  • Create wireframes and UI design of the elements, templates, components, pages with different screens following functional criteria and guidelines.
  • Work with Development to transform complex ideas into simple visual and working form.

AEM Audit: Components, Experience
Fragments & Page Templates

I reviewed, tested, and documented the library of existing AEM Components, Experience Fragments (XFs) and Page Templates (PTs).

The next exercise was to conduct a component consolidation. The goal was to identify obsolete, ineffective and/or duplicative components, XFs or page templates.

Some of the questions asked were — Are there more than one of the same component(s), is a component restricted to specific content or specific templates, or could a few elements be modified so it could be more flexible? Could the component be stripped of certain elements to avoid redundancies and reduce development time? Related components may be able to have design features tweaked to achieve the same business goal as one component, instead of say three.

And of course, does the AEM component’s experience meet the user’s need?

AEM design system - component audit

Further Define the AEM Component Structure

In order to build a design system that met the needs of AAA and it’s brand, we needed to understand all differences and similarities of each webpage experience, and how it related to developing a comprehensive DSL.

First, I began by applying the rules of Atomic Design by dissecting current and future designs into atoms, molecules, organisms, templates and pages. This allowed us to see a breakdown of what would need to be considered an “AEM” component to allow a designer to design consistently and an author to build out that design.

We ended up creating 7 different component categories; General, Layout, Navigation, Media, Input Display (such as forms), Content Display and Data Display. We needed every component to have a specific purpose. If it did not fit into one of these categories, we questioned if it couldn’t be fit into the functionality inside a pre-existing component.

Developer Iterations & Handoffs

I was part of conversations and the processes to facilitate the updating or development of existing or new AEM components.

My goal was to simplify the UI design and authoring process, by understanding what the component’s function was, how designers perceived the component, and how developers and content authors interacted with the component.  Since I had a hand in both designing page layouts, and authoring those designs into AEM, I felt fortunate to be able to have an insight into the impact AEM components had in both design and development.

In order to maintain a central design system and component library that was maintained at a global level, we needed to develop a global CSS library.  I conducted testing on new or refurbished components to ensure they met both design expectations, as well as that they behaved as expected on all device resolutions, and if any CSS / HTML issues existed, document those for Developer work.

AEM developer handoff

Provide UI Design Power & Flexibility

Side-by-side in the all of the above processes was to build designs that made the best use of core component features and capabilities, as well as convey to developers the need to edit or create AEM components.

The goal was to create a system where it was beneficial for designers to refer to the AEM Core Components available. Designers can then build UX/UI experiences and style variants by referring to the core components display structures and elements.  Making use of core components will be advantageous as the scope of work will be only limited to customizing the look and feel of the component as per design.

The end result was to create a UI Design System, using AEM components as the building blocks, so as to improve productivity, as well as a consistent design language across all webpages.

Development teams can then invest effort and energy in implementing specific custom components and features rather than duplicating the effort by implementing something which AEM already offers.

Use and Edge Cases

Part of my role was to work with UX Researchers and UI designers to identify user-flows that may have been missed, misidentified or expected in the future.

This was another finetuning of the AEM Design System Language, since components, XF and page layouts needed to be further tested to see if new AEM components needed to be created or whether to edited existing components for more flexibility.

Use Cases AEM

Creation of Design System Language

Last, was a system of Sketch files that aligned with the component library and served as the central hub for designers. The idea was for any designer to know and understand the flexibility of each component. Styles would be defined at the top level and maintained in one file, shared across designers. This allowed a designer to quickly prototype any AEM website and understand where the component library stopped and new development began.

At that time, the DSL was created in Sketch, however, the System eventually migrated to Adobe XD.

The Results

With the design and development of a revamped AEM component design system, UI designers and Content Authors were able to create cleaner, more consistent designed web pages on AAA web properties. Some of the highlights include:

  • Reduced components from over ~100 to ~32
  • This reduction was key in consolidating and creating components that in turn help create a consistent UI design.
  • Introduced “Foundation Components” such as – Layout, Hero, List, Promo and Text
  • Created ~20 new Experience Fragments, that leveraged the new component structure, and that worked in conjunction with creation of Live Copy Pages
  • The design system was then implemented for all of AAA sites.
  • Developers now spend less time fixing avoidable issues with AEM.
  • Designers can create on-brand designs more effectively without worries of going off-brand.
  • Content Authors can quickly author pages without fear of running afoul of design guidelines.

Call Now Button