Frames and nodes

Frames separate different kinds of project context so one diagram does not try to communicate everything. Put information in the frame that owns the decision.

Project Brief

Use Project Brief for project-wide intent and rules that influence every page or implementation area.

Note

Use notes for:

• Project summary
• Goals and audiences
• Delivery principles
• Content or operational context
• Important assumptions

Constraint

Use constraints for non-negotiable requirements such as:

• Required framework or platform
• Accessibility target
• Legal or privacy requirement
• Hosting limitation
• Delivery date or scope boundary

Do not put page-specific constraints here unless they affect the whole project.

Structure

Use Structure for the primary page, route, or screen hierarchy.

Page

A Page represents a meaningful route, screen, or template. Its title names the page and its body explains the page's broad role.

Connect only direct structural relationships. For example, Blog is the parent of Blog Post. A page should not be connected to every page it can navigate to.

Every Page automatically appears in Page Hierarchy.

Note

Use a Page Note for supporting information that does not belong to one page body, such as a navigation rule or structural assumption.

Feature

Use a Feature when a capability needs to appear beside the structure but is not itself a route. If it is an implementation module or service, Technical Architecture is usually more appropriate.

API / Integration

Use this sparingly for an external dependency that directly clarifies a page relationship. Put broader integration architecture in Technical Architecture.

Constraint

Use for a structure-specific limitation such as a route that must remain static, authenticated, regional, or excluded from navigation.

User Journeys

Use User Journeys for focused paths tied to a distinct user goal. Journeys supplement Structure; they do not replace it.

Actor

The Actor names the person or role completing the journey, such as Customer, Supplier, Editor, or Administrator. Use one actor-led map per materially different goal.

Step

A Step represents a significant milestone such as Signup, Plan Selection, Hosted Payment, Workspace Setup, or First Publish.

Keep journeys linear and readable. Omit incidental clicks, global navigation, low-value analytics events, and minor interface states.

Example:

New Customer → Signup → Select Plan → Payment → Dashboard

Create separate journeys for signup, checkout, supplier onboarding, and content publishing instead of combining every path.

Decision

Use a Decision for a meaningful branch or choice in the path, such as Eligible / Not Eligible, Payment Approved / Failed, or Continue as Guest / Sign In.

Tracking

Use Tracking to call out analytics and measurement requirements tied to the user path. Name the event or outcome, then describe its trigger, required properties, consent constraints, and success criteria. Keep instrumentation details out of ordinary Step nodes.

Note

Use a Note for an assumption or supporting detail that helps explain the journey without becoming a step in the path.

Page Composition

This combined workspace keeps the reusable Section library beside the pages that use it. Use the library pane to define, order, and organise reusable page structures. A reusable section keeps a stable global name, shared context, composition tags, an abstract preset thumbnail, and its own workflow status.

Add labelled divider rows to group the library without creating page content. Group membership is retained through stable divider IDs. The row grip is the single movement control: drop it within the library to reorder, or onto a page card to append a linked placement.

Use shortcut 1 to open the section preset picker and 2 to add a divider while the pointer is over the library pane.

The Page hierarchy pane is generated from Page nodes in Structure. You do not add standalone frame nodes here. Shortcut 1 opens the page picker while the pointer is over this pane.

Use it to define the ordered sections that compose each page, edit page-specific placement titles, assign content workflow status colors, and place definitions from Sections. Presets, notes, tags, and build context stay in Sections.

See Page hierarchy and sections.

Design Guidance

Use Design Guidance only where visual decisions help implementation.

Direction

Overall visual intent, tone, density, and brand expression.

Colors

Named six-digit hexadecimal variables and notes about palette use, contrast, or accessibility.

Reference

Paths to supplied assets plus guidance about what to borrow from them, such as layout, tone, spacing, or composition.

Typography

Heading font, body font, and practical hierarchy or usage notes.

Layout

Whitespace, density, grid, alignment, responsive composition, and section rhythm.

Imagery

Photography, illustration, product media, user-generated content, cropping, fallback, and asset consistency.

Motion

Animation principles, interaction feedback, transitions, and reduced-motion expectations.

UI Treatment

Buttons, cards, borders, forms, badges, controls, states, and component surface treatment.

Avoid

Explicit anti-patterns or styles that should not appear.

Design System

Reusable components, token conventions, state rules, and system-level guidance.

Note and Constraint

Use a Note for supporting design context and a Constraint for requirements such as contrast, brand compliance, or asset restrictions.

Technical Architecture

Use Technical Architecture for implementation boundaries and direct dependencies.

Stack

Framework, runtime, language, library, or foundational build constraint.

Module

A cohesive application capability owned by a module or feature area.

Service

Backend or internal service responsibility such as forms, search, notifications, or exports.

CMS

Content platform and the content responsibilities it owns.

Data

Important data model or domain entity.

API / Integration

External provider, hosted flow, third-party API, or system boundary.

Store

Database, object storage, search index, cache, or other persistent datastore.

Decision

An architectural choice and the reason it matters.

Note

Supporting implementation context that does not fit another semantic node.

Constraint

Security, performance, hosting, compliance, compatibility, or delivery limitation.

Connections

Connections should communicate direct relationships. Skafold supports relationship meanings including:

• Flow
• Dependency
• Data
• Authentication
• API
• Event
• Constraint

Keep architecture relationships sparse. A readable model with meaningful dependencies is more useful than a fully connected graph.