Skip to main content
A design system is the shared language between designers, developers, and content teams. With Metabind, you define that language once — and it renders natively on iOS, Android, and web. No separate implementations. No drift between platforms. This guide will help you build a system that’s consistent, scalable, and a pleasure to use.

​
Foundations

Great design systems start with clear foundations. Before building components, establish these:

Primitives first

Start with building blocks — colors, text styles, buttons, cards, images. Complex components compose these primitives, so changes propagate automatically.

Clear naming

Name components for the people using them. ArticleCard over Card1. CallToAction over CTA. Names should communicate purpose instantly.

Purposeful properties

Every property is a decision content teams make. Expose only what needs to vary. Use sensible defaults. Choose constrained types over free-form strings.

Organized structure

Group components by purpose — Cards, Marketing, Layouts — not by technical similarity. Structure should match how content teams think.

​
Components

Metabind has two component types, each with a distinct role.

​
Layout components

Layouts define the structure of a content type. They specify what properties content teams fill in — title, author, hero image — and where component blocks can be added. Every content type has exactly one layout. A layout answers: What’s the shape of this content?

​
View components

Views are the blocks content teams add when creating content — paragraphs, quotes, images, calls to action. They’re self-contained and reusable across different layouts. A view answers: What can I put inside this content? Keep this separation clean. Layouts structure. Views fill.

​
Content types

Content types are where governance happens. They determine:
  • Which layout structures the content
  • Which components content teams can use
  • Which package version renders it all
Create focused content types for specific purposes. An Article type with components suited for editorial. A ProductPage type with components suited for commerce. A LandingPage type with components suited for marketing. Resist the urge to create one universal type that allows everything. Constraints guide content teams toward good choices and keep your published content consistent.

​
Versioning

Packages freeze your component library at a point in time. Once you publish 1.0.0, it never changes — content using that version renders the same way forever. This immutability is powerful, but it means versioning decisions matter. When to publish:
  • At meaningful milestones, not after every change
  • When you have a coherent set of improvements
  • After testing with live previews on real devices
How to version:
  • 1.0.1 — Bug fixes, no behavior changes
  • 1.1.0 — New components or properties, backwards compatible
  • 2.0.0 — Breaking changes that need coordination
Before a major version, make sure your team is ready to adopt it.

​
Workflow

A healthy design system workflow looks like this:
1

Build with previews

Generate a preview link. Scan it with your phone. See your component on a real device as you build. Share with designers for feedback.
2

Publish a package

When your components are ready, publish a versioned package. This freezes them for production use.
3

Create content types

Define content types that use your package. Choose layouts and allowed components carefully.
4

Empower content teams

Content teams create using your system. Watch how they use it. Their friction points reveal what to improve.
5

Iterate

Refine components, publish new versions, update content types. The system evolves with your team.

​
Principles

As you build, keep these in mind: Ship simple, then expand. A basic component that works beats a complex one that’s never finished. You can always add properties later. Defaults should be beautiful. Components should look good with zero configuration. Properties customize — they don’t complete. Watch how it’s used. Content teams reveal which properties confuse, which components are missing, and which never get used. Let real usage guide your roadmap. Refactor when patterns emerge. Building the same thing twice is fine. Building it three times means it’s time for a new primitive. The best design systems aren’t designed in isolation — they evolve with the teams that use them.

​
What’s next

Components

Start building your first components.

Layout Components

Create layouts that structure content types.

Live Previews

Test components on real devices as you build.

Publishing Packages

Freeze your components for production.