Introducing ExperienceKit: AI-Generated Drupal Pages, Built on a Governed Design System

Your marketing team needs a landing page for next month's campaign. Today that means a brief, a ticket, a spot in the developer queue, and a few weeks of waiting. ExperienceKit turns it into a sentence. Describe the page, and AI generates it in your Drupal site: production-ready, on brand, and built entirely from a governed component library, one built on your brand and delivered as part of the solution. This post introduces what ExperienceKit is, why we built it, and what the rest of this series will cover.

We have spent years building sites for universities, NGOs, and other organizations that run large Drupal websites, and we kept watching the same problem play out. So we built ExperienceKit to solve it. This is the first article in a series where we go deep on the how and the why, one topic at a time, starting here.

The problem we kept seeing

Two problems show up at almost every organization running Drupal at scale, and they pull against each other. The first is speed. A landing page for a campaign, an event, or a program launch often needs something custom, so it becomes a ticket and joins the developer queue. By the time it ships, weeks have passed and the moment it was built for is half over.

The second is consistency, and it reaches far beyond campaigns. Give any editor a rich text field and the freedom to add inline styles or paste in custom markup, and the brand starts to move. It happens on a news post, a department page, a staff bio, anywhere someone reaches for a custom color, a hand-set font size, or a one-off layout to get the look they have in mind. None of it is careless. Editors are creative and they care about their pages. But multiply hundreds of editors by thousands of pages by years of small, well-meant decisions, and a brand nobody set out to change has changed anyway.

These two problems are usually handled separately, and the usual fixes work against each other. To move faster, teams hand editors more freedom, and consistency slips. To protect the brand, they lock the editor down, and work slows or quietly routes around the lock. A good design system holds a lot of the middle ground, but it governs only the components developers build. The moment content is edited in a free-form editor, the system's reach ends and the drift begins.

The core idea in one sentence: ExperienceKit uses AI to generate production-ready Drupal landing pages from a prompt, assembled entirely from a governed component library built on your brand.

What ExperienceKit is

ExperienceKit is a solution to both of these problems, built for Drupal, and it has two halves that always ship together. Different people on your team feel the value of different halves, but neither works without the other.

BrandKit

The governed design system

A governed component library built on native Drupal Single Directory Components (SDC), and part of what we deliver with ExperienceKit. It comes built on your brand, and we keep it updated over time. Because it is native SDC living in your own codebase, that is support without lock-in: the components stay yours. Every component passes engineering and accessibility review before it enters the library, and brand, accessibility, and structure are decided once, at the component level, then inherited by every page.

CampaignKit

The AI page generation engine

Turns a plain-language prompt into a complete Drupal landing page, assembled only from BrandKit components. It never invents anything from scratch. It selects components, fills their content, and arranges them into a draft. Because it is a draft, your editors stay in the loop: they bring the voice, review the page, and decide when it is ready.

BrandKit defines the building blocks. CampaignKit turns them into landing pages. Together, they give you the experience you always wanted. It means a marketer can describe a page and get one that looks like your organization made it, because it is built on your brand.

How it works, briefly

We will devote a whole article to this, but here is the shape of it. The component library comes built on your brand. Your team writes a prompt, the way they would brief an agency. AI generates the page from those components, inside your Drupal, ready to review. A person reads the draft, adjusts the copy, and publishes through the workflow you already use.

Here is what one of those prompts looks like:

"A scholarship campaign page: hero, application deadline banner, three testimonial cards, and a sign-up form."

Minutes later, that brief is a reviewable page. Brand, structure, and accessibility were all settled once, at the component level, so no new page has to solve them again. AI does the assembly. People keep the judgment.

From there, everything stays editable. The generated page is normal Drupal content, so your team can change the copy, swap an image, or reword a section right in the interface, the way they already edit any page. No ticket, no waiting on an agency for a small change. If you want a different mix of sections, you can add, remove, or swap the components the AI chose, and it stays intuitive thanks to Drupal Canvas, the newest visual page builder in Drupal.

Why "governed" is the whole point

Plenty of tools can generate a web page from a prompt. The difference is what they are allowed to build from. A general-purpose AI makes up each page from scratch: its own layout, its own styling, its own guess at your brand. It can look impressive, but custom, one-off pages like that rarely meet accessibility standards, and they drift from the brand the same way hand-built pages do. Our components are built to those standards once, and every page that uses them inherits them.

ExperienceKit generates only from the components in that governed library, so a generated page is on brand and accessible from the start. Most of the time it needs no structural change at all. When something new is genuinely needed, your team can adjust a component or build a new one from the same accessible building blocks, and it becomes available on every page afterward. Generally, though, they will not have to reach for that.

When your brand evolves, updating one component carries the change, its accessibility included, to every page built from it. A change to a component's structure is a bigger call: it deserves careful review, a decision on whether it should be a new component instead, and sometimes it is the start of a proper redesign. Either way, it is the AI adoption your governance team can actually say yes to.

Editors stay in charge

To be clear, this is about structure, not about fencing editors in. We have built enough of these systems to know that editors are the reason a site stays alive, and the aim is to give them more, not less. The base component library we build covers, in our experience, almost anything a team needs to say. When it does not, that is not a wall. We add a new component, built on your brand, and it is available on every page from then on. Your own developers can build them too: it is standard Drupal SDC, easy to work with, and the direction Drupal itself is heading. The library grows with the work, and it grows to what your editors ask for.

We are also not trying to replace editors with fast generation. The opposite is the point. The AI does the part nobody enjoys, the repetitive assembly and the waiting. Editors do the part that matters: reading the draft, adjusting and reshaping it, sharpening the message, deciding it is right, and publishing it. Generation without that human judgment is just speed. The review, the human call on whether this is good enough to ship, is where the real value sits, and it stays firmly with your people.

Who it is for

• Universities with hundreds of departmental pages and one brand to protect. Give every faculty the ability to publish without giving up governance.
• NGOs whose next campaign should not take three weeks. Respond to the moment while it is still the moment, without risking the brand donors trust.
• Drupal teams and agencies who want to build the design system once and stop rebuilding hero blocks forever. It is native SDC, aligned with where Drupal core is heading.

Where this series goes next

Over the coming posts, we will unpack each piece of this in depth. This introduction is the anchor the rest of the series links back to. Here is the map:

• How AI landing page generation actually works in Drupal, from prompt to published page, step by step.
• A complete guide to Drupal Single Directory Components, the foundation the whole approach stands on.
• Why university websites break at scale, and what a governed component library changes.
• A practical framework for AI content governance that stands on its own, with ExperienceKit as the example.
• How NGOs can launch campaign pages in hours, not weeks.
• How this fits where Drupal is heading, including Drupal Canvas, the newest visual page builder in Drupal, and how AI generation layers on the same foundation.
• Web accessibility at scale: audit components once, not pages forever.
• The real cost of a landing page, and what AI generation changes about it.

Whether you found this through the Drupal community, a conference, or TheWeeklyDrop, this is the best place to start. Bookmark it, then follow the thread.

See a prompt become a page

Reading about prompt-to-page takes longer than watching it. Bring a real brief, an actual campaign your team has queued, and watch it become a reviewable Drupal page in minutes, on a governed component library built for your brand, with no developer queue in the way.

Book a demo of ExperienceKit and bring your hardest landing page brief.