Summary
This article series has examined the process of auditing and reviewing the set-up of a Drupal Layout Builder enabled website template. The site uses Layout Builder to place components on a page and can be used to create an infinite number of pages using a library of pre-built and designed components. The article series revolves around the components and at its core looks at building components, creating instances of the components, and then adding them to a page that has Layout Builder enabled.
Why Audit your Development?
We started by looking at why you may want to undertake such a task in developing a website, and for this case, I presented three reasons:
- You may have started in an unknown part of the system or process, in this case the Drupal Layout builder Module, and have now found a better way of doing something. I call this starting in the middle, and it is quite common to do.
- You will possibly be able to unearth things that are important that are missing. This is somewhat tied to the first reason, but can shine a light on missing functionality.
- We looked at how the layout and styling of components are an integral part of the setup and tightly coupled. This is a good chance to document how the component may be used and note how the usage of them may need to be restricted.
What is the Process I Took to Audit the Site?
After looking at why you may want to an audit, I ran through my audit process:
- From documenting how each component is built and whether it is a template component or dynamic.
- How instances of a component can be created, and edited.
- And then how they can be added to the layout.
Discovery and Improving
At this point, I made the discovery that it is better to add paragraphs directly to custom block types and move away from using the node edit form. This is so there are fewer ways to create component instances, which greatly enhances the UX for content creators.
Another point from this, I think, is that it is important to make a clear division between building components and then using components. This is because to build components requires site building and possibly theming know how. As with using components and Layout Builder, that is creating a component instance and adding it to a layout, requires content creating know how. This can be easily documented in a user guide.
I think that this division between building and using will always be a split, and require two distinct groups of people; that is designers and developers, and then content creators and editors. This would be true for any site build, be it built using Drupal as in this case-study or using any other the other open source or proprietary site builder or CMS.
To use Layout Builder or not to use Layout Builder for articles
You may be wondering what I mean by this, especially if you are reading this article before the other articles in the series. In the previous article, ditching the node edit form, I suggest moving away from using the node edit form/page for creating component instances and only allowing component instances to be created on the layout page. But maybe the node edit page still has its use for long form articles.
Layout Builder is good for allowing content creators to add various types of components to a page, to build a unique layout; pages like a reusable blog page or landing pages are great uses for using Layout Builder.
For text-heavy pages like long piece articles, you may want to use the node edit form/page with a body field and a well set-up CKEditor.
You can also use a text component on the Layout Builder page and if you use Layout Builder modal the text area will not be restricted to the off-canvas tray.
That said, you could still use the Layout Builder module for adding unique aside/sidebar, footer, or other region content.There are many possible approaches, but exploring them all would take us too far afield here. However, the usage of Layout Builder will depend on understanding the needs of the users and then using it smartly to enable a great user experience, and with that you'll need to provide a user guide.
Conclusion
Writing this article was a bit of work, but it has helped to get a better picture of the shortfall of my design; that is the user experience design, the components design, the layout design, and of course, the aesthetic design. And how all these parts of a website are interrelated.
This article was written as a way to learn and discover building components for Drupal and Layout Builder, and just as much thinking and re-hashing was needed to make this article work as was needed to make smart components; to make it reflect how much work is truly needed to arrive at what I hope is not only a good-looking website, but a usable site for both the content editor and the site visitor alike. A site engineered not just to look good today, but to evolve as needs change and new possibilities, like Canvas, emerge.
What we have learnt is there are many ways to create a site using Layout Builder and Drupal, and that no way is better than the other, and it will depend on the use-case.
Even though, I have arrived at the conclusion that using Paragraph components on the node edit form isn't the best solution. For this site, it is not to say that using paragraph components on the node edit form is bad. In some cases, it might be the best solution.
Take, for example, a page that the content editor doesn't need to have access to the Layout tab (and therefore does not), but the Layout Builder module is used to lay out the content: in this case, it would make sense to have paragraph components on the node edit form so that if needed the information could be edited by the content editor. Again, this type of solution would need to have a user guide, so the content editor knew how it worked.
Secondly, we have learnt that the theme styling is tightly coupled to the markup created by Drupal. This means you need to add strict usage rules through using Layout Builder Restriction to keep things in check and your site looking as it is meant to.
This brings me to the final point, that building components and using components are different jobs. I know I have already mentioned this in the summary, but I think it is a very important point. It is essential to design and build what will be needed by the end user, the content creator, and make it easier for the content creator to understand and use.
The Future of Layout Builder and Canvas
The Drupal project has just releases Canvas (AKA Experience Builder), which tackles a lot of the Layout Builder oddities in the create and add workflow for components. The nice thing about both Layout Builder and Canvas is that they both use Drupal's powerful structure content. This means that you can start using Layout Builder today and easily move to Canvas as it matures, or since Canvas is now at a stable 1.0 version as of 5 December 2025, you could skip Layout Builder altogether.
However, I do feel Layout Builder will be a good solution well into 2026 and beyond. But let's see.
So where to from here?
This article series has been in the works for almost a year, and even though it may now seem outdated because of Canvas, I think it still raises some valid questions and points in the state of building websites in 2026. The questions and points asked or stated will guide my next year, so I will once again list them out:
- Site building and site using are two distinct roles. Even though this article flows from auditing to building components and then on to creating and adding components, the former two and the latter two should be seen as separate.
- User guides are essential to provide the most friction-less user experience.
- An audit process either before we start or during development is essential to identify issues and new ways of doing things. This ties into my advocacy of a design thinking mindset; where design is a non-linear and iterative, and where starting in the middle is a valid approach.
With these in mind I will start to test Canvas more fully now, I have been dabbling, but I will try to recreate what I have in Layout Builder. I will also try to contribute a bit more where possible and when time allows.
I will also continue to test some new Layout Builder projects (add-ons) to refine the user experience of my single page or landing page builder we have just audited and which I am still using.
This isn't all that I will be working on, but it is what this article surfaces for me. Other things will be to hone my design skills and start to introduce AI or LLMs into my work flows in the context of designing and building modern front-ends using Drupal and other frameworks. These are stories for another day.
Wrapping it Up
I hope this article is helpful in creating your own websites, whether they be Drupal-based or some other technology. I feel that what is discussed here is generally high level, even though it uses Drupal and the Drupal Layout Builder module as the technology. Building a library of usable components is something all front-end designers and engineers do at some level each day.
If either front-end designing or engineering is of interest to you, sign up below for my newsletter.
Finally, if you need help with anything discussed here on Design Kojo, feel free to send me a message. Thanks for reading, and until next time, seize the day.
Simon