Landcare Design System

This repository is designed for Landcare Australia and Landcare branded Natural Resource Management groups that need consistent, auditable brand implementation across online, print, and application work.

What Is A Design System?

A design system is a shared set of design decisions, reusable parts, and practical guidance. It helps many people create Landcare material that feels like it belongs to the same family, even when it is made by different groups, volunteers, agencies, designers, developers, or tools.

Think of it as a set of layers. Great design is not usually created by one isolated choice. It comes from using the same brand rules, colour logic, type hierarchy, spacing, grid, components, and patterns together, again and again, with care.

Design system layers

Consistent parts become consistent design

A design system works by stacking decisions in the right order. Start with the protected foundations, use the approved tokens, assemble components, follow patterns, then produce artefacts that look and behave like Landcare.

Foundations

Brand rules, logos, colour, typography, grid, composition, content, and accessibility.

The protected base for every Landcare design decision.

Tokens

Named values for colour, type, spacing, layout, and other repeatable settings.

The source values that flow into CSS, JSON, templates, and group forks.

Components

Reusable parts such as buttons, cards, alerts, tables, forms, and navigation.

The building blocks used to make pages, documents, and interfaces.

Patterns

Repeatable arrangements for common jobs such as events, learning resources, project updates, and calls to action.

The practical structure that helps people combine components well.

Templates and artefacts

Specifications for web, print, social, signage, documents, and application outputs.

The finished material people can adapt for real Landcare work.

Governance

Rules for approved local variables, protected brand decisions, reviews, and audit history.

The system that keeps local flexibility connected to brand consistency.

Local group variables Your Name Landcare event page, poster, form, social tile, or report

Group details can change, while the inherited brand layers keep the work recognisable, accessible, and easier to update.

How To Read This System

Use Foundations when you need to understand the rule behind a design choice. Use Components when you need a reusable building block. Use Artefacts when you need a practical output. Use Developer Outputs when you need CSS variables, JSON tokens, or implementation references.

For group forks, most local expression should happen through approved variables: group name, contact details, region, approved logo references, local introductory text, import paths, and artefact defaults. The protected brand layers should remain inherited from the relevant Landcare, Coastcare, or Junior Landcare preset.

Repository Model

The master repository stores canonical rules, tokens, Markdoc documentation, and generated artefact specs. Brand-specific forks or branches inherit from the master. Group repositories fork their relevant brand and change only group.config.json.

First Testing Groups

Your Name Landcare
Your Name Coastcare
Your Name Junior Landcare

Each fixture demonstrates the same pattern: local variables belong in the group config, and brand rules come from the inherited preset.