Fusion Design

Fusion Design

When to use

Any time you are writing or reviewing frontend code in the Fusion ecosystem and need to know how it should look, behave, or be structured.

Instructions

This skill is a lookup. Read all reference files before writing any code — they define mandatory requirements, not optional styling.

1. Read the references

2. Check for a local DESIGN.md

If the app has a DESIGN.md at its root, read it first. It is the authoritative source for that app's design decisions and overrides or supplements the reference rules.

3. Apply

Implement the UI to match the rules. If no DESIGN.md exists and the task requires a layout decision, document it there.

Changelog

0.1.1 - 2026-06-16

patch

• #180 `e7ca6c1` - Add EDS typography reference

• Add references/eds-typography.md with EDS typography rules
• Update SKILL.md to list the reference and clarify all references are mandatory

• #182 `6c262c3` - Add sidemenu navigation reference

• Add references/navigation-sidemenu.md with sidemenu structure, hierarchy, and breadcrumb rules
• Update SKILL.md reference table to include the new navigation reference

0.1.0 - 2026-06-10

minor

• #178 `e6e7e1f` - Add experimental fusion-design skill

New skill that looks up Fusion Design Guidelines and applies them to frontend code in the Fusion ecosystem. Covers layout, spacing, component usage, and interaction patterns. Supports app-local DESIGN.md overrides.

Refs: equinor/fusion-core-tasks#860

EDS Typography

Source: https://eds.equinor.com/

Rules

• Always use <Typography> from @equinor/eds-core-react for all text — headings, body, captions.
• Never use bare HTML elements (<h1>–<h6>, <p>, <span>) — always use <Typography> regardless of styling.
• Never hardcode font sizes, weights, or line heights in CSS or style props.

Import

import { Typography } from '@equinor/eds-core-react';

Heading variants

Example

// ✅ Correct
<Typography variant="h1">My Page</Typography>

// ❌ Wrong — plain HTML
<h1>My Page</h1>

// ❌ Wrong — hardcoded styles
<h1 style={{ fontSize: '32px' }}>My Page</h1>

Navigation — Sidemenu

Rules

• Use a sidemenu when the app has 3 or more distinct sections — for fewer than 3 sections, use tabs instead.
• Never combine sidemenu and tabs at the same hierarchy level — the sidemenu handles all top-level navigation on its own.
• Maximum navigation depth is 4 levels — if the app requires more, reconsider the information architecture.
• Expand the sidemenu by default on first arrival — never hide or collapse it on load.
• Never put state-driven actions in the sidemenu (Save, Delete, Confirm) — place actions in the content area.
• Never create single-child groups — if a parent has only one child, flatten it to a top-level item.

Structure levels

Breadcrumbs

• Show breadcrumbs when the app has 2 or more levels of navigation depth.
• Never show breadcrumbs on the top-level entry point — there is nowhere to navigate back to.
• The current page is the last breadcrumb segment and is not a clickable link.
• Each breadcrumb item links to the index/overview of that level.
• Use the actual entity name for dynamic segments — not a generic label.
• Never style breadcrumbs as tabs — they are different patterns with different meanings.
• Never truncate breadcrumb items unless screen space is critically limited.

Example structure

App (A)
├── Overview (B)
├── Applications (B)
│   ├── App list (C)
│   └── App details (C)
├── Settings (B)
│   ├── Users (C)
│   ├── Roles (C)
│   └── Integrations (C)
└── Help (B)

Breadcrumb when on Settings › Roles: App › Settings › Roles