Brainforge Knowledge

figma-layout-notes

4 min read

Figma Layout Notes

Date: 2026-04-16
Source: Sales Assets - https://www.figma.com/design/mKTpR46wYleYtLKF0qciSc/Sales-Assets

Why This Doc Exists

The repo already contains the source copy for many sales assets, but the current finished leave-behinds were designed in Figma. This file captures the layout system that the first HTML-to-PDF spike should treat as the visual benchmark.

File Organization

The Sales Assets file is not a loose moodboard. It is organized into reusable asset families and a component area.

Major sections observed

  • Event Data Modeling_6 JAN
  • 1-Pagers V1
  • 1-Pager V1 Components

Within 1-Pagers V1

The board is grouped by status and review state:

  • Archived 📂
  • WIP ✍️
  • Needs Review 🔄
  • Final ✅

Representative asset families

  • General Services - V1 - Mar 2025
  • Service Offerings - V1 - Mar 2026
  • Deep Dive on Data Services - V1 - Mar 2025
  • Deep Dive on AI & Automation - V1 - Mar 2025
  • Pricing Page - V1 - May 2025
  • FAQs (1/2)
  • FAQs (2/2)
  • Event Data Modeling - Page 1
  • Event Data Modeling - Page 2

Page Geometry

The file uses a consistent print-first canvas rather than fluid web composition.

  • Dominant page size: 2550 x 3300
  • Common content frame: x=100, width=2350
  • Common hero/header component: 1-Pager Heading, 2550 x 991
  • Footer component width: 2350
  • Footer block often begins around y=2941
  • Brand strip and page number often sit around y=3181

Implication: the first renderer should target a fixed portrait canvas with deterministic content regions, not a responsive web page that happens to print.

Reusable Components

The file includes a dedicated component section, which is a strong signal that Brainforge is already thinking in reusable print modules.

Explicit component inventory

  • 1-Pager Heading
  • Successes
    • Orientation=Horizontal, Service=Data
    • Orientation=Vertical, Service=Data
    • Orientation=Vertical, Service=AI
  • Footer
    • Type=Maximizing
    • Type=Ready
    • Type=AI

Repeating section types across assets

  • Hero band with large headline, subcopy, and logo bar
  • Trusted-by logo row
  • Success metrics cards
  • Service cards in 3-column rows
  • Deep-dive service tiles with supporting bullet chips
  • Comparison / pricing matrix tables
  • FAQ question and answer rows
  • Roadmap / step-sequence sections with numbered stages
  • Bottom CTA banner + brand strip

Implication: the renderer should be built from reusable archetype components rather than one generic markdown flow template.

Layout Patterns By Asset Type

1. General one-pager

Representative frame: General Services - V1 - Mar 2025

Observed structure:

  1. Fixed hero/header
  2. Trusted-by row
  3. Success metrics
  4. Service cards (Data, AI, Strategy)
  5. Narrative + visual progression section (Your data journey)
  6. CTA footer

2. Service offerings page

Representative frame: Service Offerings - V1 - Mar 2026

Observed structure:

  1. Shared heading component
  2. Shared successes block
  3. 3-column offering grid
  4. Secondary narrative block (Iteration Cycles)
  5. Supporting process diagram
  6. Footer treatment

3. Pricing page

Representative frame: Pricing Page - V1 - May 2025

Observed structure:

  1. Shared hero band
  2. Pricing matrix with offer columns
  3. Subsections by service line (For Data, For AI)
  4. Support/team panel (We're in This Together)
  5. Bottom CTA banner

4. FAQ multi-page layout

Representative frames: FAQs (1/2), FAQs (2/2)

Observed structure:

  1. Shared header
  2. Section title (Frequently Asked Questions)
  3. Group title (General FAQs, Service-Specific, etc.)
  4. Stacked Q/A cards with consistent spacing
  5. Explicit page split across numbered pages

5. Roadmap / deep-dive multi-page layout

Representative frames: Event Data Modeling - Page 1, Event Data Modeling - Page 2

Observed structure:

  1. Page 1: hero, explanatory copy, benefits cards, trusted-by row, comparison table
  2. Page 2: slimmer header, roadmap title, repeated numbered step modules, footer with page numbers

Implication: multi-page assets are intentionally composed page by page, not simply flowed from long text.

Practical Rendering Constraints

The first implementation should assume:

  • fixed portrait page geometry
  • deterministic page regions
  • component-level template reuse
  • explicit page break ownership for multi-page assets
  • strong control over vertical spacing
  • support for logos, icons, and mixed text density

Recommendation For The First Spike

The first HTML-to-PDF spike should adopt this shape:

  1. Normalize repo markdown into a small structured document model.
  2. Map that model into asset-family-specific templates.
  3. Render with fixed print geometry matching the Figma page system.
  4. Compare output against a representative Figma benchmark, not just raw markdown completeness.

The practical baseline is still HTML + server-side Chromium rendering, but the template layer should be componentized and print-rigid from the start.

Last updated: 2026-04-16

Graph View

Backlinks