Building a Design System for Content Editors

When a UX team has the opportunity to redesign templates and page elements for a large site, the work that matters most is often invisible to the end user. This project defined the editor styles and reusable modules that content and production teams would use to build every page — making the CMS easier to use, reducing build errors, and improving accessibility compliance across the board.

The Problem Generic editor styles had accumulated over time — styles that could be confused for other styles, used for the wrong purposes, or applied inconsistently across the site. One of the clearest examples was a quote style that had a background color giving it visual credence as a generic-use style, but the underlying markup was incorrect. That is bad for accessibility and bad for long-term platform maintenance.

Content teams also needed a simple way to build complex page components without engaging directly with the complexity of the CMS. Modules that could be built through a series of editable fields — and that would render correctly on the page once complete — were the solution.

What I Designed Editor styles were realigned to defined purposes with matching visual treatments. No more generic styles or styles that could be mistaken for something they were not.

Approximately a dozen functionally distinct modules were designed, each built through editable fields and uploads. Once all required fields are filled, the component renders on the page without requiring the editor to navigate CMS complexity. Each module was designed device-agnostically — meaning small screen layouts were designed first, with large screen elaborations built from that foundation.

Outcome Content teams gained a consistent, accessible toolkit for building complex pages. Accessibility compliance improved. The CMS became easier to maintain at scale. The system was designed to grow — new modules could be added using the same framework without disrupting what was already in place.

hopkinslogoHighRes.jpg