UI Suite Is Announcing a New Display Builder: Pierre Dureau

Just before DrupalCon Atlanta 2025, I had a conversation with Pierre Dureau, yes, the web design guy with thick French accent. Pierre is the founder of the UI Suite Initiative, maintainer of the UI Patterns module and some modules of its ecosystem, creator & maintainer of the UI Styles module, creator & maintainer of the UI Examples module, co-creator & maintainer of the UI Skins module and co-creator & maintainer of UI Icons module. Somewhere in between juggling those and client work, he dropped an exclusive for The DropTimes: he and his team are building a new Display Builder module—a clean, modern alternative to Layout Builder, Page Layout, and Views (for display). Simple idea, big potential.

Pierre’s been in the Drupal game since 2006 and hasn’t really looked back. He started out building websites for local clients with a couple of friends, stumbled onto Drupal 4.7, and that was it. By 2010, he was active in the community. And by the time Drupal 8 came around, configuration entities and plugins had completely changed how he saw the platform. He’s been all in ever since—contributing to core, guiding SDC, and helping teams untangle messy frontend workflows through proper design system thinking.

In this interview, we get into all of it. His early days with Drupal, the philosophy behind UI Patterns 2.0, why business logic has no place in components, what most teams get wrong about design systems, and how WebAssembly might shake up the backend sooner than people expect. It’s part origin story, part tech deep dive, part love letter to structure and simplicity.

TDT [1]: You've been working with Drupal since 2006, almost two decades now. What initially drew you to Drupal, and what made you stick with it?

Pierre Dureau: Twenty years ago, I was 20 and starting a web agency with friends. We needed to build low-cost websites for our local market. I came across an article about the release of Drupal 4.7 on a French webzine covering Linux and open source. It looked interesting, so we tried it and liked it. It was efficient, and we built our business around it. That’s how it all began.

TDT [2]: What led you to start contributing to the Drupal community?

Pierre Dureau: There's a saying: "You come for the code, you stay for the community." That didn’t apply to me right away. I was in a small town with little community activity, only a Linux user group. I discovered the Drupal community in 2010 after moving to Paris. There were vibrant meetups, and regular events—it was great. I'm still in touch with many of the people I met back then. It was a welcoming and active community.

TDT [3]: You've been involved in many aspects of Drupal: architecture, site building, configuration entities, and more. What excites you most about Drupal's evolution?

Pierre Dureau: My focus is on design systems when I work within Drupal, core, contrib, and client projects.
Although I started in 2006 and joined the community in 2010, my real turning point was around 2014–2015, during the Drupal 8 development phase. The introduction of configuration entities and plugins completely changed how I saw Drupal. I realized that config entities represented business objects  (user roles, content types, image styles, contribution workflows…), something I can talk about with my clients. I could model my clients' businesses in configuration by attaching and configuring the Drupal plugins provided by the dev team and keep the PHP code business-agnostic and shareable. It made collaboration better and development more productive.

Drupal 8 was a game-changer for me. Without it, I might not be working with Drupal today.

TDT [4]: You're now co-maintainer of the Theme API with a focus on SDC. What does that role involve, and how do you see it influencing Drupal’s future?

Pierre Dureau: I didn’t create SDC, Mateu Bosch led it, but I provided some guidance. When Mateu was added as Core maintainer, he brought me with him. I’ve been involved for about nine months now. My role includes reviewing merge requests, triaging issues, and, most importantly, maintaining the philosophy behind SDC. UI components are simple by design, and it's easy to over-engineer them. I try to ensure that SDC stays aligned with design system principles and doesn’t stray into complex, business-specific logic.

TDT [5]: You recently announced UI Patterns 2.0. What’s the biggest improvement, and how does it impact Drupal developers?

Pierre Dureau: This will have a big impact on how users interact with UI patterns.

It’s a wild story, really. UI Patterns started back in 2017, eight years ago. Today, everyone is talking about building displays from reusable UI components. It's modern and popular. Even some core maintainers began embracing this idea after DrupalCon Portland last year. But UI Patterns had already been doing it long before. It was ahead of its time.

And it wasn’t because of me. I didn’t create UI Patterns 1.x. Nuvole, a team from Belgium, did. At first, I was just a user. But it quickly became my main tool outside of the core and for most of my projects. Naturally, I got more involved.

So, what’s the big change?

UI Patterns 1.x had a major architectural flaw. In UI components, there is a key difference between a slot and a prop. A slot is like a section in a card where you can inject content. That content might be editorial, another component, or raw markup. Props, on the other hand, are parameters that influence the logic inside the component.

UI Patterns 1.x merged these two concepts, which caused problems. Christian Wiedemann later introduced a way to use props in 2019 through work on UI Suite. It was a good improvement, but it came late and wasn’t part of the original design.

Then came SDC, proposed for Drupal core inclusion, and it was a game-changer for us for two reasons. First, it handles slots and props correctly, which solves our main issue. Second, SDC is a low-level API. It is focused, efficient, and does what UI Patterns 1.x, but better. At the same time, it doesn’t cover everything people needed, which left us room to build the upper layers.

That’s why we rebuilt UI Patterns as UI Patterns 2, using SDC as its foundation.

The result has been a big success. Every Monday, I check the stats, and watching them grow is incredibly rewarding. I’ve received messages on LinkedIn and Slack from people who love the new model. But it’s not about me. It’s about the team. We built something great, and people are happy with it.

TDT [6]: You also founded UI Suite. What was the inspiration, and how did it expand Drupal's handling of design systems?

Pierre Dureau: A common misconception is thinking that a design system is just a set of components. Some people say, “I have a design system,” and then point only to components. While a few design systems are built that way, they’re rare. A real system includes much more, especially when it targets the web. Not all design systems are for the web, but when they are, there's a broader scope involved.

Web-focused design systems often include style utilities, which let you apply visual adjustments in specific places. They also include icon packs, which are very common, as well as theme and mode switching—like changing from a dark to light mode, switching brands, or enabling accessibility features. Other elements like CSS variables are also key, allowing you to override values and support rebranding more easily.

If you're only implementing components, chances are high that you're missing something important.

Originally, UI Patterns focused only on components. So we started asking: What’s the UI patterns for icons? What about styles? These modules didn’t exist, so we created them. Now we have five modules (UI Patterns, UI Icons, UI Styles, UI Skins and UI Examples), one for each part of a design system. 

If you’re using UI Suite, you can pick only the modules you need. For example, if your design system doesn’t include components, you don’t need UI Patterns. If it doesn’t include styles, you don’t need UI Style. You only use what fits your implementation.

Icons are a bit special. The icon module is the newest one, introduced last year with Jean Valverde, my business partner and a member of the UI Suite team. This module was especially meaningful for us. It was developed in response to a request from core maintainers, who asked us to work on an icon API. We agreed right away—it was a missing piece, and we made it a top priority for 2024.

So we built both the icon API for core and the icon module for UI Suite in parallel. Like SDC and UI Patterns, but built together by the same team.

Last year was definitely our best year yet.

TDT [7]:  Organizations often struggle with maintaining design systems. What common mistakes do you see, and how can teams avoid them?

Pierre Dureau:  I work as a consultant, mostly with French clients. More accurately, I usually work with agencies who bring me in to help their larger clients. Sometimes, I work directly with the final client, but that’s less common.

Design systems are trendy right now. That’s a good thing in many ways. There’s a lot of energy, passion, and innovation. New tools, new methods. It's exciting. But trends also bring rushed decisions, and that’s where mistakes happen.

Let me highlight three common mistakes I see.

First, people often think a design system is just a collection of components. As I said before, a proper design system goes beyond that. If you’re only building components, you're missing valuable pieces. And when you do build components, you have to be strict about one rule: do not embed business logic in them. That means no logic in the component definitions, templates, or even in the thinking behind them. Components should stay focused and reusable, not tied to any specific business use case.

This ties into my own definition of a design system, at least for the web.

A web design system is a design that is conceived and implemented independently of any specific project. If you're creating something just for one product or one application, you’re not building a design system. A system is made for a brand, a service, or a platform as a whole. Of course, you’ll always have a first product that uses it, but the design itself must not be driven by that product’s specific needs. Otherwise, you’re boxing yourself in.

Second, when you include business logic in your components or system, you end up locking yourself to the first product that uses it. That goes against the purpose of a reusable, scalable system.

Third, a design system isn’t only about design, code, or tooling. It’s about collaboration. Think of it like DevOps. DevOps is not just about tools and automation pipelines. It is a new way for developers and operations teams to work together. It improves how they communicate, share responsibilities, and plan for the future. It helps teams that used to operate in silos work as one.

A design system does the same thing. For over 20 years, I’ve seen constant friction between designers, front-end developers, and back-end developers. Projects often failed because these groups couldn’t work together effectively. A good design system bridges those gaps. It creates a common language, a shared workflow, and better collaboration. Since my team and I started working on design systems, our relationships with designers have improved dramatically.

But none of this works without ownership. A successful design system needs strong, clear leadership from both the design and development sides. The ideal setup is co-ownership, with shared responsibility and leaders who communicate and align on the vision.

If co-ownership isn’t possible, in my experience, it’s better to let developers lead the design system. I’ve seen many systems fail when led only by designers. That’s not a criticism of designers. I have a lot of respect for them, and they are essential to the process. Designers bring the quality in, and without that, nothing good comes out. However, long-term leadership often works better when developers are the ones guiding the system, with designers playing a core, respected role in the team.

Still, the best outcome comes from strong co-ownership and a team that works together with a shared goal and vision.

TDT [8]: How does UI Suite balance structure and flexibility? Can teams using Bootstrap or Material Design customize freely?

Pierre Dureau: We don’t see structure and flexibility as opposites. Structure gives us flexibility.  We have a strict commitment to decoupling. Not decoupling in the headless sense of separating browser from server, but decoupling business logic from the user interface. This is the kind of separation that truly matters. It allows business logic and UI to be handled independently, with each having its own clean implementation that works smoothly with the other.

We do not embed design implementation in PHP code or configuration. The configuration represents the business model. Code and config, such as Drupal plugins and config entities, simply use the design but do not implement it. The design is implemented entirely using front-end technologies like CSS, JavaScript, YAML, and Twig. No business logic is mixed in. As a result, the system is both structured and flexible.

Think about how Drupal modules work. There are thousands available. You pick one from contrib, plug it in, and it just works. That ease comes from modules being business-agnostic at the code level. The business logic only comes into play when you use parts of a module through configuration. For example, a module might provide a new image effect. That effect itself is just computation, without business meaning. But when you use it to create an image style, you're applying it within a business context. That separation is what powers Drupal's strong module ecosystem.

Now look at themes in Drupal. There are far fewer of them. When you install a theme and start adding content types, new fields, or views from contributed modules, things often look broken. That's because you need to manually add templates for each new content type, path, or field. This slows everything down.

By clearly separating UI logic and making all UI implementations available as Drupal plugins, we’ve created something more structured. I believe our setup is the most organized approach out there. At the same time, it remains flexible.

You can download one of our themes like UI Suite Bootstrap, Daisy UI, or USWDS, and use it right away. You don’t need to add any extra templates. Everything you need is included. Just like a module, you use the theme as-is. You don’t need to write your own PHP classes to make it work.

You get both structure and flexibility without compromise.

TDT [9]: How do you see site-building workflows changing with UI Suite and SDC?

Pierre Dureau: First, no preprocess hooks. Preprocesses were the glue between UI and business logic for years. We’ve reversed the theming workflow entirely. In a UI Suite project, the front-end developers aren't waiting on the backend to theme what Drupal is generating. They are moving upstream, becoming plugin providers, and what they deliver is a complete design implementation as a Drupal theme.

We ask front-end developers to include YAML files to describe components, style utilities, variables… as public APIs. It’s more upfront work for them—but in return, they don’t have to deal with Drupal internals. They gain full ownership and empowerment.

TDT [10]:  How does UI Suite handle long-term sustainability, updates, and deprecations?

Pierre Dureau:  It's worth mentioning that UI Suite is not just a theme. It includes several modules as well.

Let me briefly talk about the five modules. This wasn’t your question, but it ties into an important point about breaking changes. With UI Patterns 2, we introduced our first breaking change in eight years. That shows how seriously we take long-term stability and future-proofing.

If someone chooses to use the UI Suite module, yes, we might make a mistake someday. But if it happens, it will be an error we acknowledge and fix. We won't break your setup on purpose. What happened with UI Patterns 2 was a rare exception after many stable years, and now that it’s released, it will remain stable for years to come. You won’t get unexpected surprises.

Back to design systems. We also provide contributed themes like UI Suite Bootstrap, Daisy UI, USWDS, and DSFR. These themes are only a small part of the broader UI Suite ecosystem. Most people using UI Suite do so in private client projects, which means they don’t show up in the contrib space. Still, the public themes are popular and widely appreciated.

To manage breaking changes, we follow a versioning strategy where our major version matches the upstream design system version. For example, our Bootstrap 5 theme is aligned with Bootstrap 5. When Bootstrap 6 is released, our theme will move to version 6. Same with Daisy UI—when it moved from version 4 to 5, we updated accordingly.

This means we only introduce breaking changes when the upstream design system does. If the upstream makes a poor decision, that impact will carry through to us. But it will not be something we introduce on our own.

In short, our commitment is clear: we won’t break your theme unless the design system we’re implementing changes in a way that forces it. Our stability depends on theirs. As long as they stay stable, so do we.

TDT [11]: You’re juggling a lot: work, open source, initiatives, and travel. What keeps you going?

Pierre Dureau:  Love. I fell in love with this solution 10 years ago, and that passion keeps me going. 

Also, it's a business. Making a living from open source is a dream come true.  I’m redefining my role. I now see myself more as a software editor. My business partner and I spend most of our time doing open-source work, unpaid. But it makes us experts. When clients need us, we can deliver high-value expertise quickly. That balance allows us to contribute deeply while staying sustainable.

TDT [12]:  Drupal is evolving rapidly with projects like SDC and Project Browser. What other trends or changes do you think Drupal needs?

Pierre Dureau:  Drupal needs new display builders. I don’t see Drupal as a CMS or DXP anymore. To me, it’s a business modeling platform. 

Content modeling is great, you can do so much through config entities and the admin UI. Business rules (permissions, events, workflows, views queries…) can be modeled well too. But when it comes to the display building layer, we’re limited.

We currently have three main display builders in Core: Layout Builder, Page Layout, and Views. We need one unified tool, and it needs to be “design system native”. There are ongoing projects targeting this goal. With the release of UI Patterns 2, we realized we too almost had such a display-building tool. We’ve already built the “engine”, 80% of what’s needed—context, dependency and cache management, data retrieval and normalization—through UI Suite.

What’s missing is a UI layer and state management. So, we’ve started building a new module, simply named Display Builder. It will be a modern visual editor, replacing Layout Builder, Page Layout, and Views (for display). It uses a light and pragmatic stack, with HTMX and Web Components, integrates deeply with Drupal, and is fully “design system native”. 

We are a small team of Drupalers passionate about display building. We started a few weeks ago, everything is going smoothly, and we have a lot of fun. We'll release the code soon, and we’re looking for sponsors to support the project.

TDT [13]: That’s a major announcement—and an exclusive. Thank you for sharing that here. Beyond Drupal, what else excites you?

Pierre Dureau: In IT, I work with two main technologies. Drupal is my primary one because it’s a mature platform. It gives you access to real, practical projects and has a strong foundation.

My second focus is WebAssembly.

Whenever I mention WebAssembly, people often react with skepticism. They say, “Wasn’t that trendy eight years ago? Didn’t it have another moment five years ago?” Every few years, it seems like someone is trying to revive interest in it. But I believe now is actually a good time for WebAssembly. Something significant changed last year.

WebAssembly today is not the same as it was two, five, or seven years ago. It has gone through a major transformation—similar to what Drupal experienced moving from version 7 to version 8. That shift brought excitement, activity, and a lot of potential.

But just like the Drupal transition, it’s also created some confusion. Entering the WebAssembly ecosystem right now feels chaotic. However, once this transition period is over, it could be a real game changer.

It might even impact Drupal development, though not in the way people usually imagine. Most people think of WebAssembly in terms of browser use, but its impact on the server side could be much more significant. It has the potential to transform deep, backend processes—even in Drupal.

That’s what makes it so interesting right now.