window.addEventListener('load',function(){['ktd-logo-sub','ktd-flogo-sub'].forEach(function(c){var el=document.querySelector('.'+c);if(el&&el.textContent.indexOf('Senior')>=0)el.textContent='Lead UX Designer';});});
Dell Landing Page Design System — Kamala Espig
Design System · Author UX Solo Designer Jan 2021 – Feb 2023

Dell Technologies  ·  Design Lead · Solo designer · System design · Author UX · Docs

Dell Landing Page Design System —
enabling 6,000 pages at global scale.

Dell's global marketing teams couldn't publish a landing page without filing an IT request. I built the design system that changed that — giving non-technical authors the tools to create compliant, on-brand pages independently, across multiple Dell brands and global markets.

Dell Landing Page Design System — component library
Component library · Shipped 2021–2023
Atomic components at the base, assembled into templates. Every component WCAG 2.1 AA compliant and Storybook-documented for engineering.
Multiple Dell brands Global markets AEM
6,000AEM pages migrated across Dell's global marketing organization
28%improvement in webpart reuse across the platform
100%WCAG 2.1 AA compliance across all components — by construction, not by audit

Marketing teams were filing IT tickets just to update a headline.

Dell's global marketing organization used AEM for landing pages — a system that required IT involvement for anything beyond basic content edits. Pages were slow to ship, inconsistent between markets, and dependent on engineering bandwidth that was always oversubscribed.

The ask was a design system that gave marketing authors real autonomy — the ability to build and publish pages that were on-brand, accessible, and consistent, without involving IT. The system had to work for a wide range of author types, from regional marketing coordinators to developers building custom implementations.

The scale of this
One system. Multiple Dell brands. Global markets. Four distinct author personas. 6,000 existing pages to migrate. The author experience had to be as carefully designed as the components themselves — maybe more so, because if authors couldn't use it confidently, nothing else mattered.

Start with the author, not the component.

I mapped the four author personas before designing a single component — understanding what each person was trying to accomplish, their technical comfort level, and where the current system was creating friction. The component designs followed from those needs.

Four author personas
Developer, marketing manager, regional coordinator, content editor — each with different goals, vocabulary, and comfort with technical complexity.

Developer, marketing manager, regional coordinator, content editor — each with different goals, vocabulary, and comfort with technical complexity.

Author UX
Page builder interface for the least technical user. Configuration options surface progressively. The least technical author can publish without ever seeing advanced settings.

Page builder interface for the least technical user. Configuration options surface progressively. The least technical author can publish without ever seeing advanced settings.

Components were built on atomic design principles, with Storybook as the developer-facing documentation layer. Accessibility was baked in from the start — authors couldn't accidentally produce inaccessible pages even without knowing what WCAG was.

Persona documentation
Persona-specific documentation

Separate documentation paths for each persona — technical reference for developers, task-based guides for coordinators.

Atomic design hierarchy
Tokens to components to templates

Components built from tokens, assembled into patterns. Consistency is structural, not enforced.

Three architectural choices that made the system scale.

Designed for the least technical author as the primary usability bar
If the system worked for a non-technical marketing coordinator in a regional market, it worked for everyone else. I used this as my consistent benchmark — and it pushed several component decisions in directions a developer-first approach wouldn't have gone.
Accessibility as a structural constraint, not a compliance checklist
WCAG 2.1 AA wasn't audited at the end — it was designed into every component from the start. Authors producing pages through the system couldn't accidentally create accessibility failures, even without knowing what WCAG was. That's the only version of accessibility compliance that actually scales.
Documentation written separately for each author persona
A single technical reference would have served developers and been ignored by everyone else. I wrote persona-specific documentation — each with a different entry point, different vocabulary, and different level of technical depth.

What building for four different users taught me about systems.

The author experience is the product. A design system is only as good as the experience of using it. If authors need help every time, the system hasn't solved the problem it was built to solve.

Accessibility scales when it's structural. Building it in from the start is a one-time investment that compounds across every page the system produces.

Documentation is a design surface. Writing for four different personas taught me as much about the system's actual complexity as designing the components did.