Dell Technologies · Design System · Case Study

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. Solo designer, end-to-end.

Company
Dell Technologies
My role
Design Lead · Solo designer
Scope
System design · Author UX · Docs
Timeline
Jan 2021 – Feb 2023
Component library screenshot
The complete component library. Atomic components at the base, assembled into templates. Every component WCAG 2.1 AA compliant and Storybook-documented for engineering.
6,000
AEM pages migrated across Dell's global marketing org
28%
Improvement in webpart reuse across the platform
100%
WCAG 2.1 AA compliance across all components
The problem

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.
How I approached it

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.

Persona diagram
Four author personas — developer, marketing manager, regional coordinator, content editor
Each with different goals, vocabulary, and comfort with technical complexity.
Page builder screenshot
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.
Documentation screenshot
Persona-specific documentation — different entry points for different readers
Separate documentation paths for each persona. Technical reference for developers; task-based guides for coordinators.

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.

Token diagram
Atomic design hierarchy — tokens to components to templates
Components built from tokens; assembled into patterns. Consistency is structural, not enforced.
Key decisions
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 I took from this
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.