Frames

Frames and nodes

Understand what each Structure Studio frame represents and when to use its available node types.

Structure Studio gives each kind of project context its own focused canvas so one diagram does not try to communicate everything. Use the side navigation to switch workspaces, or open All Frames for a read-only overview of the complete project. Put information in the workspace that owns the decision.

Project

Use Project for project-wide intent, documentation, resources, 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.

Project Resources

Use Project Resources for important briefs, brand guidelines, research, specifications, and other project memory held in an external service. Each item has a title, public HTTP(S) share link, and optional description explaining why it matters.

Skafold stores the curated link and context, not the file. Test Google Drive, Dropbox, Pinterest, or other provider links in a private browser window before relying on them; provider permissions can change independently of Skafold.

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

Page composition uses two connected workspaces, Sections and Pages, each available directly from the navigation rail.

Use the Sections workspace to create and refine reusable definitions. Its freeform canvas gives compact section cards and labelled dividers room to be arranged into useful visual groups. A reusable section keeps a stable global name, shared context, composition tags, an abstract preset thumbnail, and its own workflow status. Open its title or preview to edit Content, Layout, and Settings in the side panel, including drag handles for ordering content fields and groups. Move cards using their handles or blank space, or drag several selected cards together. Shortcut 1 opens the section preset picker and 2 adds a divider.

Use the Pages workspace to compose routes from those definitions. Page cards receive the full canvas, while the Section library stays available in a collapsible panel on the right. Search the panel, filter by status or unused definitions, drag a Section onto a page, or use its quick-add action after selecting a page. The quick-bar search and status filter apply to pages independently of the library. A matching page keeps its whole section composition visible. Shortcut 1 opens the page picker.

Page cards are generated from Page nodes in Structure; you do not add unrelated standalone nodes here. Use the Pages workspace to define ordered page sections, edit page-specific placement titles, assign content workflow status colors, and create a new reusable Section directly from a page when needed. Presets, notes, tags, and shared build context remain on the canonical definition in Sections mode.

Use a section card's status control to update that definition or the selected visible definitions together. In Pages, use a page header's completion counter to update every section on that page, or every section in the selected visible pages. Each bulk change can be undone in one action; library and page-placement statuses remain independent.

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. Enter HEX first; the color picker stays synchronized as a supporting control.

Reference

Add repeatable titled public HTTP(S) links to visual references. Use the title to state what the reference contributes, such as hero direction, layout, tone, spacing, typography, or composition. Links are directly followable from the node.

Typography

Add repeatable role-and-font pairs such as Display, Heading, Body, Italic, Accent, UI, or Monospace. Use Custom for a project-specific role and retain practical hierarchy or usage notes at node level.

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.

Pre-flight

Use Pre-flight for delivery, QA, SEO, accessibility, privacy, and launch-readiness checks. A project can contain multiple checklist nodes when separate audits are clearer.

Each checklist has a title, optional overall notes, and ordered items. Items retain checked or unchecked state and can include notes for findings, qualifications, or remaining work. Drag individual checks to reorder them, or drag whole checklists to organise the Pre-flight frame around your delivery workflow. Add custom items as project requirements emerge; reusable templates are not part of the initial workflow.

Pre-flight is exported to AI Context, so you can ask an AI to audit selected items against a repository and return findings without reconstructing the launch requirements from memory.

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.