Why DFC Bridge matters

The design—desktop and mobile:

Actual Figma page 01: a finished-looking design at two widths, with roots named desktop and mobile-final-2 — Looks finished. What was handed over is still unclear.

The design looks good. Frontend, backend and AI still guess: what to build, where data comes from and where buttons lead.

DFC Bridge does not dictate design. Hand off decisions, not guesses.

Download the design .fig

Open Figma.
On the home screen, click Import.
Choose the downloaded .fig.

1. Looks good. Still unclear

desktop and mobile-final-2. One page or different screens? The names do not say. The team fills the gaps.

Compare both trees. Which heading and button are the same element?

Actual expanded Figma desktop layer tree: Heading and Button — Desktop: `Heading` / `Button`.

Actual expanded Figma mobile layer tree: Title mobile and Button copy — Mobile: `Title mobile` / `Button copy`.

Two more “looks better on mobile” decisions:

«Мастерская понятных макетов» → «Мастерская макетов». Changed content, not line wrapping.
Moved all of hero-actions from hero-copy to hero, after the image. Changed parent, not just order.

Native Figma desktop hero detail: full heading, both controls before the illustration, original root label retained — Desktop: full heading; both controls before the illustration.

Native Figma mobile-final-2 hero detail: shortened heading, both controls after the illustration, original root label retained — Mobile: «понятных» is missing; both controls are below the illustration. Full source capture.

Agree on the copy variant and describe the move. Here neither is declared: frontend and AI guess.

2. Connected the screens

Agreed: one workshop page, /workshop route, default view, widths 1440 and 375. Recorded on the roots:

workshop [page=workshop] [route=/workshop] [bp=1440] [view=default]
workshop [page=workshop] [route=/workshop] [bp=375] [view=default]

Separate continuous Figma recordings. Automated character-by-character input and Cut/Paste; the mouse pointer does not follow actions. Captions and highlights are added.

Details: “View fullscreen” below → “Original size”.

Separately: linked the roots of one page. GIF.

workshop and default are shared by roots with native widths 1440 and 375 — One page/view, two widths.

Frontend knows what to build. AI stops hunting for the “most final” screen. Tags describe the agreement; they do not create layout or code.

3. Found the same elements

Named by role, not device. Frontend and AI can now match elements:

Before at 1440 / 375	After at both widths
`Heading` / `Title mobile`	`hero-title`
`Button` / `Button copy`	`contact-button`

Here we chose shared copy and parent. This is not the only way.

Title mobile → hero-title. Name, not copy. GIF.

Restored «Мастерская понятных макетов». GIF.

All of hero-actions → hero-copy. Not one button. GIF.

Different copy needs an agreed product variant. A different parent needs a declared transformation. Reordering within one parent is allowed.

The same two controls change from a row at 1440 to a column at 375 inside hero-actions — Same buttons, same parent.

Desktop buttons sit side by side; mobile buttons stack. Different layouts are fine: Auto Layout changes; text and parent stay the same here.

Native capture of the prepared page at 1440 px: full heading and buttons side by side, with space around hero — 1440 px: buttons side by side.

Native capture of the prepared page at 375 px: full heading and buttons before the illustration, with actual page margins — 375 px: stacked buttons, before the image.

The heading stays text. workshop-art [decor] [asset] stays one image. Do not flatten the interface into PNG.

4. Built a shared library

button-primary and button-secondary became shared components. Edit the source; instances update. No fixing every copy.

UI-kit shows both styles’ states; Modals holds the shared modal appearance. Frontend and AI see examples, not gaps to fill.

Actual UI-kit: two button styles shown as default, hover, focused, pressed and disabled; Modals with contact-modal beside them — Two styles, five state examples. The modal sits beside them.

Default → hover, then independent focus. GIF.

Appearance in the library. Action on the page instance. The same button elsewhere can do something different.

contact-button [action=modal:contact-modal] → open the modal.
faq-link [href=#faq] → go to FAQ.

href=#faq points to anchor=faq; action=modal:contact-modal points to modal=contact-modal — Declared destinations—not runtime proof.

On the instance: action → target at 375. GIF.

Show target finds the hidden layer; it does not open the modal. Behavior still needs implementation.

How the components work

Examples, not a working prototype.

State=default/hover/pressed/disabled are Figma variants, not DFC tags or page views. Focus is independent: Focus visible=true can coexist with hover and pressed.

The disabled condition and owner belong in the implementation contract. No loading state: modal and anchor, not an asynchronous request.

Each root has its own hidden [modal=contact-modal]. The main component in Modals is the appearance source, not another target. Email details, not a submission form.

Record the source and agreements in the data contract.

5. Checked the result

Separate copy: different hero-title text and hero-actions parent. Auto Layout stays enabled. Repairs are not shown. The clip shows the old report and Repeat.