Léas Page Design Skill

This skill designs pages for the Léas website by working directly in Figma. It selects and places modules from the Léas Modules library, applies the correct device appearance, and uses semantic design tokens — all without detaching library components.

---

The Léas Design System

Léas uses a multi-library system in Figma made up of three files:

Library	Figma File ID	Role
Foundations	s591K1VKecRoGrlvPNv8La	Core tokens: colour variables, typography, spacing, elevation, border radius, icons, image aspect ratios, container sizes, margins, gaps, paddings
Components	fN89wJBxUyRq5gov4daKov	Independent UI elements (buttons, inputs, cards, etc.) assembled into modules
Modules	St7LjEebkHK6JtCEfsu4oj	Full-width page sections stacked vertically to build complete pages

⚠️ Library File Protection — Non-Negotiable

The three Léas Library files (Foundations, Components, Modules) are read-only for this skill:

File	File ID	Status
Foundations	s591K1VKecRoGrlvPNv8La	🔒 Read-only
Components	fN89wJBxUyRq5gov4daKov	🔒 Read-only
Modules	St7LjEebkHK6JtCEfsu4oj	🔒 Read-only

Never create, modify, or delete any frames, components, variables, styles, or pages inside these library files. They are shared design system assets consumed by all designers and developers. Any unintended change can break every product that depends on them.

If a task appears to require editing a library file (e.g. adding a new component, modifying a token), stop and tell the user — do not proceed. Suggest they raise it with the design system team instead.

All design work (new pages, frames, wireframes, explorations) must go into a separate working file — never into a library file. Always ask the user where to create new designs (see Before Starting below).

---

Token Usage Rules

• Never use Primitive tokens directly. Always use semantic/alias tokens.
• Match token to context: use surface tokens for backgrounds, text-colour tokens for text, elevation tokens for shadows, etc.
• Tokens are powered by Figma Variables in the Device collection, which has four modes: Desktop, Desktop Small, Tablet, Mobile.

---

Device Appearances

All modules and components use Figma Variables that automatically adjust typography, spacing, padding, gaps, margins and container widths when the appearance mode is set. Always set the correct appearance for the canvas width being designed:

Appearance Mode	Screen Width
Desktop	≥ 1536px
Desktop Small	1024px – 1535px
Tablet	768px – 1023px
Mobile	≤ 767px

Default output is Desktop (≥ 1536px) unless the user specifies otherwise (e.g. "make this mobile first" → use Mobile appearance and a mobile-width frame).

Note: A canvas width of 1440px falls in the Desktop Small range (1024px–1535px). When designing at 1440px, always apply the Desktop Small appearance mode — not Desktop.

Module Variants vs. Appearances

Variants are only created when the layout shifts between devices (e.g. side-by-side → stacked). If the layout is consistent across breakpoints, no variant exists — appearance alone handles the visual differences. The skill must:

1. Select the correct variant (Desktop / Tablet / Mobile) if one exists for the target device.
2. Apply the correct appearance mode (Device collection) to the frame.

---

Working from Source Content (Word Docs or Pasted Copy)

When a user provides a Word document, uploaded file, or pasted copy as the content source for a design, follow this content-first workflow before touching Figma.

Content Extraction

1. Read the source file in full before making any design or module decisions.
2. If the document uses a two-column table format, treat the columns as:
   • Left column — editorial/design intent notes for Claude's reference only. Extract intent from these but never render them in the design output.
   • Right column — live content to be used verbatim in the design.
3. Identify and label every piece of content by type (headline, subheading, body copy, CTA, metadata, etc.).
4. List the extracted content back to the user as a structured outline for confirmation before proceeding.

Example extraction outline:

- Hero Headline: "Transform the way your team works"
- Hero Subheading: "A smarter platform built for modern teams..."
- Feature 1: "Real-time collaboration — Work together without the wait"
- CTA: "Get started for free"

Only begin designing after the content outline has been confirmed.

Content Rules (Non-Negotiable)

✅ Always Do

• Use content verbatim — exact wording, punctuation, and casing from the source
• Preserve the order of content as it appears in the document unless restructuring is explicitly requested
• Place every piece of content from the source file somewhere in the design
• Flag any content whose purpose is ambiguous and ask for clarification before placing it
• Flag any content that needs to be omitted and explain why, asking for permission before proceeding

❌ Never Do

• Invent, paraphrase, or rewrite any copy
• Add Lorem Ipsum or placeholder text
• Create new sections, features, or benefits not present in the source
• Rename headings or alter CTAs
• Assume a piece of content is decorative or skip it
• Render editorial/design intent notes (left-column table content) in the design output — these are instructions for Claude only

Handling Ambiguous Content

If any content does not clearly fit a content type:

• Do not guess — flag it explicitly
• Present the ambiguous content: "I found this line: '[text]' — should this be a section heading, a CTA, or body copy?"
• Wait for confirmation before placing it
• If the user says "just decide" — make a reasonable choice and note what you chose and why

---

Working in Figma

Before Starting

Always ask the user for the following before doing any Figma work. Do not assume or infer these from context — ask explicitly every time:

1. Where to create the new design — Ask: "Which Figma file and page should I create this in?" Never place work inside the Foundations, Components, or Modules library files. If the user points to a library file, explain that library files are protected and ask them to specify a different working file.
2. The Figma frame URL or page where the output should be placed (within the working file confirmed above).
3. The target device — default to Desktop if not specified.
4. The page type and purpose — if not already clear from the prompt.

Placement Rules

• Modules are always stacked vertically inside a single Auto-Layout container with a 0px gap and a fill of fi-surface-color-default. Modules already include their own internal spacing, so no additional gap is needed between them.
• Every page must start with a Navbar and end with a Footer. Content modules go between them. Never omit or reorder these bookends.
• Every page must include a Breadcrumb immediately after the Navbar — this is mandatory, no exceptions. Place the Breadcrumb as the second item in the Auto-Layout, directly below the Navbar and above all content modules. Apply the correct appearance mode to match the rest of the page (same Device collection mode used for the frame). When designing a Mobile screen, always use the Mobile Short variant of the Breadcrumb. For all other device targets (Desktop, Desktop Small, Tablet), select the appropriate variant as defined in the Modules library.
• Use the in-Figma module descriptions (visible in the component properties panel) as the authoritative source for each module's usage rules — they reflect the current state of the library.
• Never detach a module from the library unless the user explicitly requests it for exploratory purposes. Modules are built to mirror code logic; detaching breaks that contract.

Token Application

When configuring fills, strokes, or effects on frames or overrides:

• Background fills → surface tokens
• Text → text-colour tokens
• Shadows → elevation tokens
• Spacing overrides → spacing/padding tokens from Foundations

---

The Léas Module Library

All modules share the same surface background (fi-surface-color/default, the light teal/mint) and are designed to stack vertically. The in-Figma component descriptions are the authoritative usage reference; the table below is a quick-reference guide.

Navigation & Wayfinding

Module	Purpose
Search Featured	Top-of-page search hero. Sits directly below the nav. Has optional prompt chip row (showPrompt). Use on homepages or search-driven landing pages.

Page Headers

Every page has exactly one Page Header as its topmost content module.

Variant	Use when
Minimal	Interior pages — wayfinding only, no visual emphasis or CTA
CTA	Section landing pages with 1–2 key actions and an editorial photo
List	Event / course / webinar detail pages with structured metadata (date, location, price, registration)
Detailed	Case study / project detail pages with outcome stats and narrative
Detailed Image only	Case study detail pages without outcome stats

Goal & Category Navigation

Module	Use when
CTA Detailed	Homepage or top-level landing: user self-selects by goal (Start a business, Grow my workforce…)
CTA Compact	Homepage or category landing: user self-selects by sector (Accommodation, Food & drink…)
CTA Media	Homepage or regional overview: navigate by regional brand area using photography

Promotional & Campaign

Module	Use when
Promo Carousel	2–5 high-priority rotating campaigns or featured items
Promo List	2–4 named programmes/tools, all visible at once, each with its own CTA
Promo Spotlight	Single time-sensitive CTA (e.g. event registration reminder)
Content Spotlight	2 specific services or compliance tasks, each needing its own CTA, with background photo

Content Browsing & Discovery

Module	Use when
Card List	Primary listing/browsing page — events, courses, funds, news. Includes filter, search, sort, pagination.
Content Carousel	Mid-page curated selection of cards (courses, events). Horizontal scroll.
Content Featured	4 research reports or editorial articles, with branded header panel. Text-only cards.
Content Uneven	3 case studies/success stories with image-led visual layout.
Content Split	News + events side by side on the same page (2 content types simultaneously).
Content Links	Simple navigable list of named items (e.g. closed funds). No images or metadata.

Detail Page Content

Module	Use when
Details Page Content	Full body content of a detail page (event, course, programme). Supports tabbed navigation.
Content People	Speaker/facilitator roster on event or course detail pages.
Content Minimal	Brief contextual note or methodology explanation — no visual treatment.

Module Compatibility Notes

• Card List owns the page below the header — don't combine with other content modules in the same vertical section.
• Search Featured connects visually to the nav bar (rounded bottom corners, darker teal) — place directly below nav, never mid-page.
• Details Page Content is a full-page body module. Other modules can appear below it but not within it.
• Content People — Desktop only in current spec. Confirm responsive behaviour before using on Tablet/Mobile.
• Content Minimal — Desktop only in current spec. Confirm responsive spec before using.
• Promo Spotlight — Desktop and Mobile variants only (no Tablet).

---

Page Design Workflow

Step 1 — Establish the brief

Before selecting modules, confirm:

• Page type (Homepage, listing, detail, landing, category, research…)
• Primary user goal — what is the visitor trying to do?
• Primary organisational goal — what outcome does the site want?
• Content available — images, stats, events, articles, campaigns?
• Target device — Desktop (default) or specified otherwise?

If unclear, ask before proceeding.

Step 2 — Select the Page Header

Every page starts with exactly one Page Header variant:

• Metadata (date, location, price, registration) → List
• Outcome stats + narrative (case study) → Detailed or Detailed Image only
• 1–2 CTAs + editorial photo → CTA
• Wayfinding only, no CTA, no image → Minimal

Step 3 — Sequence modules top-down

Homepages:

1. Search Featured (if search is primary UX)
2. CTA Detailed or CTA Compact
3. Promo Carousel
4. Content Carousel or Content Split
5. Content Featured
6. CTA Media

Listing pages:

1. Page Header (Minimal)
2. Card List

Detail pages:

1. Page Header (List or Detailed)
2. Promo Spotlight (optional)
3. Details Page Content
4. Content People (optional)
5. Content Carousel (related items)

Category / sector landing pages:

1. Page Header (CTA or Minimal)
2. CTA Compact or CTA Detailed
3. Promo List
4. Content Carousel
5. Content Links (archived/closed items)

Research / insights pages:

1. Page Header (Minimal)
2. Content Minimal (methodology note)
3. Content Featured
4. Card List

Step 4 — Flag configuration decisions

For each module, surface:

• Variant to use (e.g. Page Header: List vs CTA)
• Props to enable (e.g. showCopy, showController, showButton, showPrompt)
• Content required (editorial photo, outcome stats, CTA label, content type for Card List/Carousel)
• Token choices if a fill or style override is needed
• CTA label length — review every CTA label before placing it. If a label is long enough to make the button visually too wide for its context, either shorten it while preserving the original intent (e.g. "Register for the upcoming webinar series" → "Register for the webinar") or replace it with a concise generic label such as "Find out more", "Read more", "Learn more", or "Register". Flag any label changes to the user so they can confirm or adjust.

Step 5 — Surface tradeoffs

When two modules could both work, be explicit. Example:

• "Use Promo Carousel if campaigns benefit from one-at-a-time focus. Use Promo List if items have equal weight and users should compare them at a glance."
• "Use Content Carousel for browse/discovery. Use Content Featured if editorial tone and research framing matter."

Step 6 — Build in Figma

⚠️ Before touching Figma: Confirm the destination is a working file, not one of the three Léas Library files. If the user hasn't confirmed this yet, ask now.

Phase A — Frame & Module Placement

1. Navigate to the user's confirmed working file and page.
2. Create a new frame at the correct width for the target device.
3. Inside that frame, create an Auto-Layout vertical container (Figma's "Add Auto Layout") that wraps all modules. Set the gap to 0px and the fill to fi-surface-color-default — modules already include their own internal spacing.
4. Always begin with the Navbar module as the first item in the Auto-Layout, and always end with the Footer module as the last item. Content modules go between them.
5. Immediately after the Navbar, place the Breadcrumb module as the second item — mandatory on every page, no exceptions. For a Mobile target use the Mobile Short variant; for all other devices select the variant appropriate to the target. The Breadcrumb must receive the same Device collection appearance mode as the rest of the frame.
6. Place content modules from the Modules library (St7LjEebkHK6JtCEfsu4oj) in order between the Breadcrumb and Footer.
7. Apply the correct Device collection appearance mode to the parent frame (e.g. Desktop Small for a 1440px canvas).
8. Select correct variants (Desktop/Tablet/Mobile) per module where they exist.
9. Configure exposed properties (do not detach).
10. Apply semantic tokens for any fills, text overrides, or effects — never primitives.
11. Name the frame descriptively (e.g. Homepage – Desktop Small, Events Listing – Desktop).

⚠️ Do not touch any text layers during Phase A. Complete the full module placement pass before proceeding to Phase B. Never place modules loose on the canvas outside a parent frame.

Phase B — Text Replacement (requires confirmation when working from source content)

When designing from a source content file (Word doc, pasted copy), complete Phase A fully, then:

1. Compile a replacement summary — list every text layer to be updated across every module, showing: module name, layer name, current placeholder text → proposed replacement from the source.
2. Show the summary to the user and ask: "Here are all the text replacements I'll make. Shall I go ahead?"
3. Wait for explicit confirmation before making any changes.
4. Once confirmed, replace text layer by layer, module by module, in placement order.

Text replacement rules:

• Replace the exact text layer inside the module just placed — never search for or edit a different page or frame
• No pre-existing text may remain — every placeholder, template, or previous copy in every layer must be replaced
• Match copy to layer role — headlines with headline copy, body layers with body copy, CTAs with CTA copy
• If a layer has no corresponding copy — flag it to the user rather than leaving pre-existing text or inventing copy
• Apply to every module including Navbar and Footer — no module is exempt

Font & text style preservation — non-negotiable:

Léas modules and components use Cera Pro, which is installed locally on the user's machine. The Figma plugin/API environment may not have direct access to that font when editing text layers. To prevent broken text styles, always follow this priority order when updating copy:

1. Use exposed text properties first. Most Léas modules and components expose their text content as component properties (visible in the properties panel without entering the component). Always check for and use these properties before attempting to edit text layers directly. This is the preferred method — it updates copy without touching the underlying text style or font.
2. Edit text layers directly only when no text property exists and only when the Figma environment confirms the font is available. Before typing into any text layer, verify that Cera Pro is accessible. If it is, proceed with direct editing.
3. Never retype text in a layer if it causes a font substitution or style override. If editing a layer directly would break the Cera Pro style (e.g. the environment substitutes a fallback font), stop immediately — do not save the broken state.
4. Use a Figma annotation as the fallback of last resort. If a text layer cannot be updated via a component property, and direct editing would break the font style, add a Figma annotation on the relevant layer with the intended copy. Label it clearly: "Intended copy: [text]". Flag every annotation to the user in the post-build summary so they can apply the copy manually without risking style breakage.

⚠️ Breaking a text style is never acceptable. A design with annotations is always preferable to a design with corrupted typography. Never sacrifice Cera Pro to get copy in place.

Step 7 — Storytelling Review (automatic, after every initial design)

After delivering the initial design, review the content structure for narrative flow and present suggestions. Do this automatically after every design — do not wait to be asked. Look for:

• Weak opening — does the hero establish a clear problem, promise, or hook?
• Missing narrative arc — does the page move logically from problem → solution → proof → action?
• Orphaned content — facts or claims that float without context or setup
• Buried lead — is the most compelling idea near the top, or hidden mid-page?
• Weak close — does the page end with clear momentum toward a CTA, or trail off?

Present findings as specific, actionable suggestions — not changes. Example:

"The features section appears before any explanation of the problem being solved — moving the pain-point copy above it would improve narrative flow."

Always end the review with: "Should I produce a revised design incorporating these improvements?"

Step 8 — Revised Design (Version 2)

If the user approves storytelling improvements, produce a second standalone design incorporating them. Rules:

• All content must still come verbatim from the original source — no new copy invented
• Place Version 2 on the same Figma page as Version 1, positioned clearly alongside it — do not ask for the page again
• Apply Phase B text replacement rules in full to Version 2 (compile summary, confirm, then replace)
• Label both versions clearly:
  • Version 1 — faithful to original content structure
  • Version 2 — storytelling-optimised

---

Output Format (when not building in Figma)

If the user asks for a plan or recommendation rather than a live Figma build:

1. Page summary — one sentence on the page's job
2. Module sequence — ordered list with: module name + variant, one-sentence rationale, key configuration decisions
3. Open questions — anything the designer must resolve before building

Keep output scannable. Use a numbered list. Avoid lengthy prose.

---

Example: Homepage for a Tourism Support Platform

Page summary: Help tourism businesses find the right support and understand what's available to them.

Module sequence:

1. Search Featured — Primary entry point; search is the fastest path to relevant support. Enable showPrompt.
2. CTA Detailed — Goal-based navigation so users self-select intent (Start a business, Grow my workforce…)
3. Promo Carousel — 2–3 priority campaigns (open funding, new programme launch)
4. Content Split — Latest news and upcoming events side by side
5. Content Featured — Latest research and insights with branded section treatment
6. CTA Media — Regional brand navigation for users exploring by geography