Figma to Drupal
Drupal separates content from presentation more strictly than most systems. An editor fills in fields. The theme decides how those fields are shown. A Figma design therefore has to be split twice: once into visual components, and once into the content model behind them.
We build Drupal themes from Figma files for current Drupal releases. Components are written once in Twig and then connected to content types, view modes and whichever page-building tool your editors use.
One directory for each Figma component
Single Directory Components are part of Drupal core. They keep everything about a component together.
The definition file
A YAML file names the component and declares its props and slots with a schema. Variant properties in Figma become props with a fixed list of allowed values.
The Twig template
Markup for the component. It receives props and slots and knows nothing about nodes or fields, so it can be reused anywhere.
Styles and script
CSS and JavaScript files in the same directory are attached only on pages where the component appears.
Embedding
Drupal templates for nodes, blocks and fields include or embed the component and pass field values into it.
Layout Builder and Paragraphs
Both let editors compose pages from parts. They suit different teams.
Layout Builder
In core. Editors place blocks into sections on a visual canvas. A default layout can be set per content type and overridden per page where you permit it.
Paragraphs
A contributed module. Editors add typed chunks, such as text with image or a quote, in a form. Less visual, more structured, harder to get wrong.
Custom block types
Each reusable band in the design becomes a block type with its own fields, available to Layout Builder.
View modes
The same article shown as a teaser, a card and a full page uses three view modes. Each maps to a Figma component.
Views
Listings such as news, events or staff directories are built with Views and rendered through the same card components.
What we need to know beyond the visuals
A Drupal build needs the content model as well as the look.
- A list of content types and the fields each one has
- Which components editors may place, and on which pages
- Teaser, card and full versions of each content type
- Rich text styles, including tables and embedded media
- Listing pages with filters, pager and no-results state
- Breakpoints, so responsive image styles can be defined
- Languages in use, including any right-to-left ones
- Status, warning and error message styles
Which page-building approach fits your editors?
Layout Builder tends to suit
- Marketing teams who want to see the page as they arrange it.
- Sites where landing pages differ a lot from one another.
- Teams with a few trained editors.
Paragraphs tends to suit
- Large groups of occasional editors who need guard rails.
- Content that is reused in apps or feeds and must stay structured.
- Sites with heavy translation workflows.
What is handed over
A theme alone is half the work. Configuration carries the rest.
- The theme, with its components and libraries
- Exported configuration for content types, view modes and displays
- Responsive image styles and breakpoint definitions
- A component reference page for developers
- A written guide for editors
- The list of differences from Figma and what was decided on each
Asked about Drupal theming
Do you start from a base theme?
For a custom design we generate a starter theme from core and build on that, so there is no base theme to keep up with. If you already use a base theme, we follow it.
Is the output safe against injected markup?
Twig escapes output automatically. We do not switch that off, and we do not mark user input as safe.
Can the theme serve a decoupled front end later?
The content model can. The Twig theme cannot be reused by a JavaScript front end, although tokens and CSS can.
How close will it be to the design?
Pages are compared with the frames at agreed breakpoints using real content, and differences are listed for your decision.
Tell us about the editors as well as the design
Share the Figma file, your Drupal version and how many people edit the site. We reply within one business day.