Case Study 4: AEM Enhancements
Company: New York Life | Year: 2020 | Type: Content Strategy
Content Production Speed for Text Styling
+78.00%
What took authors to access, create, and/or modify verbiage and text styles an average of 90 minutes or more now took them approximately 20 minutes.
Content Production Speed for Images
+87.50%
Authors needed a few hours to properly navigate to access and upload images. Today, that time has reduced to 30 minutes.
Content Production Speed for Pages
+95.56%
What took authors and publishers an average of an hour and a half to create, edit, and publish pages now only took a few minutes.
Background
New York Life had traditionally used third party platforms to host its digital sites — AEM 6.4 being the latest to support its digital initiatives — a platform intended to be socialized and leveraged by business lines outside of newyorklife.com proper in future releases. With the new platform now live, users can now utilize the system and its components to build templates and author/publish pages based on the approved look and feel.
Due to an ambitious timeline to launch the site, the on-boarding process to AEM 6.4 did not have a dedicated Adobe resource to train the team. Learning to use the system required creative experimentation and ad hoc support from outside vendors. Additionally, requirements gathered to build out components and their inherent functionalities were based on stakeholder input; they were not inclusive of users’ feedback — individuals who would need to be in the system on a day-to-day basis to execute and deliver on content deliverables.
To bring clarity to the term “users” in the aforementioned, “users” of the system are individuals that fulfill roles/functions typically associated with Content Strategy. Due to a lack of documentation on role clarity and role definition, priorities and expectations became fluid. This resulted in having some users experience a steeper learning curve than others. Subsequently, this created a need to leverage resources outside of the Content team — Product Owners, Project Managers, and Designers were called upon to support and fulfill content/authoring functions.
The role I fulfilled was to manage, collect, and translate author feedback into tangible design artifacts to then convert into front-end requirements and functional annotations.
Pain Points
After conducting heuristic exercises with the team that executed on content delivery, we were able to organize pain points by components.
RTE (Rich Text Editor) Component
• UI Controls did not display on load, making it confusing for new users to identify the edit functions whilst making it a frustrating experience for those already familiar with AEM.
• When UI Controls have been accessed, the order in which they appeared did not align with how frequently Authors have used them.
• Font styles did not render live as authors made changes.
• Font styles changed only when work was saved.
• Certain functionalities such as “Spell Check” and “Underline” did not display or were toggled off.
• Font-styles and colors were combined into the same dropdown, creating a lengthy dropdown list.
Banner Component
• 4 components labeled with “Banner” without having previews led to confusion when authoring pages correctly based on approved designs.
• Color theme selection was difficult to locate as it was not grouped with the rest of the UI Controls.
• Similar to the RTE, UI controls did not display until user clicks into the text field.
Edit Control Component
• Having multiple routes to get to the Edit function was confusing.
• First instance is represented by the Pencil icon or quick Edit Mode, a more succinct list of functions such as alignment, bold, and italics.
• Second instance is represented by the Wrench icon that leads users to a more robust set of edit functionalities including anchor tags, hyperlinking, font-styles, font-sizing, and headings.
• Third instance gets displayed once the user decides to work full screen from the Configure modal or after having clicked the Wrench icon.
Button Component
• Different functions that controlled the padding and verbiage were not part of the same UI modal, leading towards a more cumbersome process in getting work completed.
Image Component
• Users are not able to crop images on the AEM system and as a result, must manually crop the image and upload them onto the platform. Additionally, the modal requires excessive vertical scrolling.
Process
Conducting Heuristic Exercise
Once we’ve collected the list of pain points from individuals that performed content work, we then proceeded to conduct interviews with them to assess how they would prioritize the UI controls that enabled them to complete their tasks. Out-of-the-box functionalities that were displayed on AEM were not entirely in the order in which Authors found helpful. Once we’ve collected on how they would prioritize the UI controls, we averaged the prioritization to finalize on the order in which these features were displayed. We did this across the entire component library. The below is a sample we’ve captured for the RTE component.
Creating Wireframes
Now that we were able to get final confirmation on how best to prioritize the UI controls within AEM, we’ve begun to draft up proposals and wireframes to capture their feedback.
RTE Component Proposal
We removed the modal approach that existed within the AEM system and proposed replacing it with a top drawer, sticky approach.
• Drawer approach was an attempt to apply live, dynamic render changes as the author modified text versus how the system required that one saves his/her work before seeing anything changed or edited.
• UI Controls have been shuffled around based on feedback.
• Color, Heading, and Font Sizing have been split to make it more accessible.
• Color swatches were added to assist users in identifying which color is appropriate to apply based on approved design.
The primary feedback from the content team was that there was no way to tell which “Banner” component they were selecting until they’ve saved their work.
Banner Component Proposal
• We’ve added in previews for each Banner component to showcase their layout so users can make a better informed decision on what they’re selecting.
• Color theme was separate from the rest of the edit controls and here, we’ve consolidated them.
Button Component Proposal
• Padding and verbiage can now be modified under one display, streamlining the process for authors and publishers.
Image Component Proposal
• Removing the vertical scrolling and using a more horizontal layout to display all UI controls.
• Adding in the Crop feature to help authors avoid cropping manually outside of the AEM system.
UX Business Requirements
Once the wireframes were drafted, we then begun to socialize and share the work with the Product team to get support on prioritization. We’ve also categorized the type of work each enhancement will fall under such as “speed to market” and “visual”. Once the prioritization exercise was complete, we then begun to write up the user stories for development work.
