Two Builders, One Drupal: Where UI Suite Really Stands

That long arc matters because UI Suite isn’t presented here as a single module or a short-term trend. Michael frames it as a multi-year “quest” to address a “historical weakness of Drupal” by delivering a “low/no code experience for Display Building,” and then making the case for why design systems were the inevitable answer. He walks through the initiative’s evolution module by module, right up to the present phase in late 2025, where the focus has sharpened: translating Drupal’s emerging design system APIs into the tools site builders actually use every day, from Layout Builder to CKEditor and beyond.

This interview also serves as a natural continuation of The DropTimes’ earlier conversation with Pierre Dureau, Michael’s fellow UI Suite co-founder and co-leader. While Pierre offered a technical and architectural lens, Michael expands the picture, addressing UI Suite’s strategic positioning in a changing Drupalscape. He speaks candidly about Display Builder’s ambition to unify a fragmented site-building experience, and about its relationship with Canvas, answering the question of whether they are “complementary, competing, or deliberately separate” with characteristic clarity: “We are both complementary, competing, or deliberately separate :).” From there, he looks ahead to what success could mean by November 2026, including the ambition to move the display building “from clicking in Drupal UI to prompting in a chatbot,” setting the stage for a forward-looking and reflective conversation. If this might be of interest to you, read further.

TDT [1]: You’ve been active on Drupal CMS for over twelve years. Can you walk us through how you first discovered Drupal, what hooked you in, and how your journey led to becoming co-leader of UI Suite?

Michael Fanini: I first discovered Drupal with a close friend of mine (just_like_good_vibes), who introduced me to Drupal 7, and I quickly “fell in love” with the software. We then became partners and created a Drupal consulting company.

After four years together, I decided to leave the company and join Smile, the European leader in open source.

I held various positions there (project manager, engagement manager), and it was when I moved into the role of pre-sales engineer that I met Florent Torregrosa and Pierre Dureau. At that time, we had created an internal community contributing to Drupal, bringing together a large number of the company's developers. It was in this context that we created the UI Suite Initiative.

TDT [2]: The UI Suite Initiative has matured significantly. Modules such as UI Patterns, UI Styles, and UI Icons now form a coherent ecosystem. In your view, what is the present phase of UI Suite in late 2025, and what defines where you are now compared to a year or two ago?

Michael Fanini: The initial objective of UI Suite was to find an elegant way to provide a low/no-code experience for Display Building, which is a historical weakness of Drupal. Rapidly, it was obvious to us that Design Systems were the path to follow. Indeed, a structured system must be something Drupal can understand and leverage. Today, UI Suite provides a comprehensive, coherent ecosystem widely used by agencies to package Design System implementations and integrate them into the Drupal UI.

That “quest” took several years. Let me give an overall history of our evolution:

• 7 years ago, we were early adopters of UI Patterns…
• 6 years ago, we created UI Styles…
• 4-5 years ago, UI Skins and UI Examples were added…
• 3 years ago, SDC landed in core, leading to UI Patterns v2…
• 2 years ago, Icon API and UI Icons were built…

Drupal core is slowly taking care of the structure and packaging of all Design system parts. Soon, we will get new core APIs for Style utilities, tokens and CSS Variables.

The main scope of UI Suite modules is now to translate all Design Systems core APIs into core Display building plugins (Layout Builder, CKEditor 5, Field Formatter, …), to provide a powerful experience for site builders.

TDT [3]: According to the project page, Display Builder is described as a “design system native” builder that can work as a replacement for Layout Builder, Block Layout, and parts of Views. How close is Display Builder to being genuinely production-ready, and what remaining gaps should a site builder assess today?

Michael Fanini: As I said before, UI Suite Modules plug Drupal core Design system APIs (SDC, Icon and tomorrow Styles, Tokens, CSS Variables) to all Drupal display building tools. We did a great job achieving that, but the site-building experience remains fragmented, as site builders need to use many tools in the Drupal UI to build their displays (Block Layout, Views, Manage Display, Layout Builder, …).

In late 2024, Pierre had the idea of creating a modern tool that unifies all those features in one place. Display Builder was born, and in terms of architecture, two decisions were taken: 

• Build this tool directly on top of all UI Suite modules, which already provide the lower-level features site builders need to map their data to all design artefacts.
• Leverage HTMX to build a modern interface. 

In the meantime, HTMX was integrated into Drupal core, confirming the decision's pertinence. Soon, beta1 will be released and ready for production :)

TDT [4]: The Canvas initiative, previously known as Experience Builder, has been promoted as the official “experience builder” for Drupal with a browser-based low-code interface. In that light, how do you perceive UI Suite’s strategic position relative to Canvas? Are you complementary, competing, or deliberately separate?

Michael Fanini: In terms of business positioning, I would say that…

In terms of scope, there is an issue on Drupal.org that describes our different positioning.

We are both complementary, competing, or deliberately separate :)

• Complementary, indeed, Pierre (our technical leader and architect) :
  • Contribute to Canvas to ensure both tools stay compatible if they are both installed
  • Collaborate with the Canvas team on core issues that are used by both projects.
• Competing because we share part of our scopes, and in the end, we are both building a modern display building tool.
• Separate because, in terms of software development, we took opposite paths:
  • They started with the builder (presentation layer), and now they dig deeper and deeper to plug into Drupal
  • We already have all deep integrations with Drupal, and now we head toward the presentation layer (the builder) as the last piece of our puzzle.

TDT [5]: There’s been some curiosity in the community, and I’ll admit I’ve wondered this myself about why UI Suite wasn’t positioned as the base for Drupal’s official experience builder initiative when it already offered a strong foundation. From your perspective, what do you think influenced that decision?

Michael Fanini: It’s hard to guess…

I imagine there’s a lot at stake with all the investments Acquia has made in XB/Canvas, so it must have been risky to rely on a “small” community initiative… Or maybe they were not aware of our work.

TDT [6]: UI Suite emphasizes design system thinking and makes heavy use of Single Directory Components and component-based theming. How have you seen adoption of SDCs evolve in the Drupal ecosystem, and what real-world challenges do teams still face when applying that paradigm?

Michael Fanini: For us, SDC was a great achievement because it initiated the Design System adoption dynamic inside Drupal core. It allowed us to build version 2 of UI Patterns, rely on a new, clean API, and focus on our main topic: display building.

In the meantime, the adoption of SDC is not at the level we would expect: Many frontend developers continue to use the old-fashioned way of glueing Twig to config

The SDC theme's ecosystem is not particularly large. Hardly more than 10 themes are implementing SDC today, with varying success in terms of state-of-the-art implementation.

TDT [7]: Automation is another area you mentioned, particularly in relation to the ECA module. Can you outline the current state of automation within UI Suite or adjacent modules, and how you see it integrating with Display Builder or the wider Drupal ecosystem?

Michael Fanini: There is no specific integration with ECA, as ECA is a module that leverages the Events, Conditions, and Actions APIs. In comparison, UI Suite is a set of modules for pure frontend implementation, decoupled from Drupal backend modelling and usage. The only thing I know is that there have been some discussions between Pierre and Jurgen regarding HTMX usage.

Regarding automation, there are some UI Suite/SDC experimentations in the field of AI, for now, without specific governance:

• LLM-compliant documentation for components
• Design System assets generation (components, style utilities, tokens, …)
• Figma to SDC conversions

Regarding Display Builder, we would love to have a specific agent to assist with display building (as there is one for Canvas) through a chatbot. But no one has taken those subjects seriously for now.

For now, we have a Slack channel (#ui-suite-ai) initiated by Rajab Natshah from Vardot to gather initiatives and experiment on that topic.

TDT [8]: Module ecosystems and long-term stability matter greatly. UI Suite version 2.0 was released earlier this year. How do you handle breaking changes, backwards compatibility, and version alignment, especially since many sites adopt UI Suite in private projects? What safeguards are in place?

Michael Fanini: Indeed, long-term stability matters greatly :) That’s why we focus heavily on it through migration paths, change records, and documentation. Our main breaking change was the update from UI Patterns 1 to UI Patterns 2. We worked hard to deliver simple solutions to complex migrations. For that, we provide two main features:

• A simple drush command that generates a UI Patterns 2 / SDC components folder from a UI Patterns 1 implementation.
• The migration of a large part of UI Patterns 1 configurations to UI Patterns 2, via hook_update()!

TDT [9]: With Display Builder now in beta and several UI Suite-driven APIs (like Style API and Icon Form Element) being proposed for Drupal 11.3, how do you see UI Suite shaping the future of Drupal’s front-end architecture?

Michael Fanini: UI Suite, in a way, has already shaped Drupal frontend architecture, as it:

• Inspired SDC
• Provided Icon API
• Proposed future APIs for Styles, CSS Variables and Tokens.

As half of our contrib team is now part of Drupal core (Pierre is the core lead and SDC maintainer, Jean is maintainer of the Icon API, and Florent is maintainer of the Assets subsystem), our motivation is stronger than ever: help Drupal become the first Design System-native CMS on the market.

The UI Suite and Display Builder will focus on providing the best possible display-building experience for end users (Display builders and content editors).

TDT [11]: You’ve led contribution efforts across agencies like Smile and Dropteam and mentored numerous contributors. From your perspective, what leadership style, community structure, or practices have proven most effective in keeping a distributed volunteer and sponsored team aligned and productive?

Michael Fanini: Smile was a great laboratory where Florent and I built an internal community that unified many developers in the company.

What made this internal community successful was:

• Having “leaders” with motivation and passion
• Organising a France tour where we visited all Smile agencies to spread the word and organise small code sprints (to explain how to contribute to Drupal, targeting novice issues)
• Defining topics to work on that were aligned with the company marketing, R&D and implementations in projects.
• Targeting goals that we were following closely (at that time, it was our ranking on the marketplace)
• Organising online monthly meetings open to everyone where we presented our progress, contributions, new targeted projects, etc …
• Mentoring specific people who were motivated enough to become maintainers

For UI Suite, we drew a lot of inspiration from Smile-time to build that great contrib community. Here is a list of actions or key points we focus on :

• having leaders with great passion (we now are 6 in our core team)
• sharing the same objectives and vision
• staying open and kind to everyone who needs support or quick answers to questions
• communicating and being available on our Slack channels (where there are close to 500 people total)
• organising monthly meetings opened to anyone in the community, which helps raise awareness of everything related to UI Suite
• developing marketing assets (blog, Drupal Planet and YouTube channel
• being present at a lot of events for 4 years (Drupalcon, Dev Days, Camps, meetups) in Europe and the US, where you’ll always find a UI Suite table in the contrib room :)
• doing a lot of talks since Drupal Dev Days 2022 (Ghent)
• organising yearly code sprints in Southeast France, where all the core team gather + special guests

TDT [12]: Looking ahead to November 2026, if you were to look back on the next 12 months, what key milestones would you want to have achieved for UI Suite? And what would success look like for you personally?

Michael Fanini: In November 2026, I would love to see three things achieved:

• Full Design System APIs in Drupal core (components, icons, styles, CSS variables and tokens)
• Display Builder adoption from top agencies is bringing installations over 1k
• AI integration to bring Display Building from clicking inthe  Drupal UI to prompting in a chatbot

For me personally:

• Selling Display Builder to my agency clients (it won’t be so hard as they already adopted UI Suite :)
• See our UI Suite core team of contributors go from 6 to 10 people