Most people treat WordPress page builders like a design tool. I treat them like a design system delivery tool — and that distinction changes everything about how a project gets built.
When I started building Aesha.Design on a custom Mosaic theme, I had a fully resolved design system in Figma before I touched the builder once. Teal and ochre as the primary palette. A three-tier button system. Defined spacing rhythm. Typography scales. Interaction states for every component a user could touch.
The challenge with any WordPress builder is that it doesn’t natively enforce a design system the way code does. There’s no single source of truth unless you build one deliberately. So I built one through globally defined CSS variables, component classes that carry the full design language, and a naming convention strict enough that any element on any page could be traced back to its system rule.
The three-tier button system was the most involved piece. Primary buttons use a radial fill hover that floods the button with the accent color from the center out. Secondary buttons use a border treatment that shifts on hover. Tertiary buttons are text-only with an underline animation. Each tier communicates a different level of action priority and users feel that hierarchy even when they couldn’t name it.
The water ripple hero was a separate system entirely — canvas-based, Web Worker powered, with IntersectionObserver pausing it off-screen so it never competes with scroll performance.
The lesson from this build is that any builder rewards designers who come in with a system already resolved. If you design inside the builder, you get a builder result. If you design the system first and use the builder to deliver it, you get a product.