Deliverable
A branded, accessible CMS suite using AEM’s out-of-box functionality
My role
Lead UX Designer (end-to-end)
Team
UX, dev, creative, BA, offshore developers
Stack
Figma, AEM, Confluence, Jira, BitBucket
When
2023
Locked layouts, poor patterns, and no accessibility
Most of the site used a rigid three-column layout template with components that didn’t work together. Authors had little flexibility and couldn’t create modern layouts—resulting in clunky, outdated pages.
Every page relied on the same template—making it hard to create distinct or contemporary page designs.
Lack of design system and brand alignment
Lacking a design system, devs relied on local CSS—leading to visual inconsistency. As the brand evolved, the site became more fragmented and off-brand.
Inconsistent buttons were just one symptom of a broader design breakdown.
This wasn’t just a design challenge—it was a gap in CMS architecture and implementation expertise.
Missing AEM technical expertise slowed us down
We needed to rely on AEM’s out-of-the-box setup for compatibility, performance, and future upgrades—but no one on the team had deep experience with it.
Authors needed guardrails, not freedom
AEM’s out-of-the-box tools offered flexibility, but most authors lacked the experience to use them effectively—so we has to balance flexibility and governance.
Ambitious brand, unclear authority
An ‘evolved’ visual identity had recently launched—and there was close involvement from the Head of Brand, Creative Director, and Marketing Director. While well-intentioned, this created a complicated approval chain that muddied ownership and slowed progress.
Step 1: Audit the old, investigate the new
I reviewed every major component and template, spoke to authors about their pain points, and analysed AEM documentation to understand out-of-the-box functionality. The goal: identify what could be reused, what needed redesigning, and what patterns were missing.
I audited each component to understand its function, limitations, and potential for reuse.
I studied AEM documentation on core components and editable templates, and worked closely with devs to shape and plan our implementation approach.
Step 2: Define distinct and manageable core templates
Rather than trying to fix everything, we focused on three versatile templates: landing page, content page, and news article. These formed the foundation of the system—flexible enough to power most of the site, without overwhelming the build.
Content page
A template for text-heavy pages – everything from informational pages to guides and FAQs. Designed for clean readability and structured layout options.
Landing page
A promotional template used for campaign-driven pages or category-style ‘wayfinding’ pages—balancing visual engagement with flexible structure.
News article
Purpose-built for Media team to publish stories and announcements. Optimised for clean typography, date stamping, and embedded media.
Step 3: Design, build and learn
We restyled AEM core components using our new design system, and filled design gaps as we went. Building the content page template first gave us space to test, learn, and understand the quirks of layout containers, style policies, and editable templates.
Iterating closely with developers, we tested content edge cases to refine and stabilise the content page template for broad, real-world use.
We released the content page as soon as it was stable—marking the first new template available to authors in years.
Final designs
Once it launched, it took off
Template adoption grew quickly—starting with just a few pages and scaling to over 200 within months as authors embraced the flexibility and improved experience.
Authors gave great feedback
The new suite empowered content authors to create engaging web experiences with more flexibility and control, which also boosted morale.
Project won 2 internal awards for excellence at the University.
Improved accessibility
Accessibility reporting now shows a significant decrease in errors across key pages that are utilising the new suite, contributing to a more inclusive web experience.
Accessibility scan showing 0 critical issues
This wasn’t just a design challenge—it was a gap in CMS architecture and implementation expertise.
Distinguishing real blockers from noise
Visual decisions were treated as hard stops, but many could’ve been solved later with lightweight frontend tweaks. In future, I’d push to build technical foundations earlier, even without full frontend sign-off.
Sometimes authors need less choice,
not more
Flexibility sounds great—until you see how overwhelming it can be in practice. I’ve learned to embrace opinionated defaults and build smart constraints into the CMS.
Prototype technical unknowns early
AEM’s layout model isn’t intuitive. Waiting to build slowed learning. In future, I’d request low-effort proof-of-concepts earlier to clarify what’s feasible.
More case studies
Building a flexible, accessible CMS
View project
From clutter to clarity: a navigation overhaul
View project