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, 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.

Page Hierarchy

Page Hierarchy is generated from Page nodes in Structure. You do not add standalone frame nodes here.

Use it to define the ordered sections that compose each page. 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.