How to create a design system for mockups

Decide what a design system means inside a mockup

In a mockup tool, a design system is not a library of components you can publish. It is a set of decisions you have already made, written down, and then applied to every screen, so that two screens built a week apart still look like the same product. The value is consistency rather than abstraction.

That makes the system smaller than people expect. Four decisions cover most of it: the spacing scale, the type scale, the color roles and the recurring blocks. A mockup does not need a component editor. It needs a rule you can follow at five in the afternoon when six more frames are still to be built.

Write the rules before you build the frames, because the first screen you build sets the pattern whether you chose it or not. Six screens later you either thank that first screen or rebuild all of them.

• Consistency, not a publishable library
• Four decisions cover most mockups: spacing, type, color and recurring blocks
• Written down before the first frame is built

Note: A mockup design system is for the people building the mockup, and sometimes for the person who picks it up later. It is not a handoff artifact for a development team, because a static mockup carries far less than a real token file does.

Fix one spacing scale and use it everywhere

Spacing is the decision with the biggest effect and the least glamour. Pick a scale on the 8 point grid, such as 8, 16, 24, 32 and 48, and use those numbers for every gap, every padding and every inset. In App Builder the auto-layout gap and padding are set in the inspector, and both run from 0 to 96, so a scale built on 8-pixel steps fits inside them comfortably.

Put the numbers into the layout rather than into a preference. A card with 16 pixels of padding inside and 24 outside looks deliberate because the numbers are related. The same card with 14 and 26 looks accidental, and nobody can tell you why without opening the inspector.

The scale also makes changes cheap. If the card padding turns out to be too tight in one place, changing the number in one inspector field moves every card in the mockup, rather than leaving an old card behind at the old value.

• A scale of 8, 16, 24, 32 and 48 for gaps and padding
• Auto-layout gap and padding carry the scale, from 0 to 96
• Change one number rather than one component

Note: The spacing and 8 point grid guide works through the reasoning behind the numbers if the scale is not obvious to you yet.

Reuse the component library instead of redrawing

App Builder has seven insertable reusable components: Stat card, List row, Form field, Call to action, Empty state, Nav header and Tab footer. Insert them instead of building each one by hand, because every insertion is already consistent and every hand-built version is a new chance to be slightly different.

The value shows up when you duplicate. Duplicate a Stat card and both copies have the same padding, the same label size and the same number of lines. Build it by hand twice and you have two slightly different cards that will be compared in review. The empty state guide shows the same pattern applied to one screen.

The honest limit matters here. You cannot define your own reusable components, so a pattern that is not in the list of seven has to be handled another way: keep one copy as a reference, duplicate it, and keep the spacing and type values identical every time. The design system components guide covers the same idea for teams working in larger tools.

• Seven insertable components: Stat card, List row, Form field, Call to action, Empty state, Nav header and Tab footer
• Duplicate rather than rebuild
• A hand-built pattern needs a reference copy kept in a fixed place

Note: There are 58 component kinds in the App Builder palette, and separately 7 insertable reusable components. The palette kinds are parts you place directly on a frame, and the seven are the ones you can insert again later.

Use the light and dark themes as two token sets

Canvasola has light and dark theme token sets, and a toolbar toggle moves between them. That toggle also changes the HTML export, so the same frames read differently in a light browser window and a dark one. Treat the two as separate token sets rather than as a color swap, because the surfaces and the text colors have to hold up separately in each.

The practical rule is to check every screen in both themes, and to avoid picking anything that only works in one. A border that reads as a clear edge in the light theme can disappear in the dark one, and a muted label can lose all of its contrast.

Write down the roles rather than the hex values, because that is what survives. Background, surface, border, primary text, secondary text, accent, success, warning. Then check each role in both themes and note where it needs adjusting.

• Light and dark are separate token sets, not one set with a filter
• The toolbar toggle also changes the HTML export
• Name the roles, not the hex values

Note: The themes are a fixed pair in App Builder. You are not authoring a new token set, you are checking that the content still works in both, and the color palette guide covers how to choose the accents inside them.

Keep a written list of what the system contains

Write the system down. One page with the spacing scale, the type sizes, the color roles, the seven components and a screenshot of the reference screen is enough. The list is what stops each new frame becoming a negotiation, and it is what you send to someone who asks why the padding differs between two screens.

Include the decisions that are not visual. What a heading is called, what a button does, what a screen shows when it is empty. Those are the parts of a system that are invisible in a screenshot and missing every time someone reads the mockup for the first time.

Keep the list next to the file. A system described in a document that nobody opens is the same as no system at all. The complete Canvasola guide covers where to keep working material in the app itself.

• One page: spacing scale, type sizes, color roles and the seven components
• A screenshot of the reference screen
• The invisible rules, such as naming and empty-screen behavior

Name what the mockup tool will not let you define

Say plainly what you cannot have, because pretending otherwise wastes an afternoon. App Builder has no component editor, so you cannot create a reusable component of your own or publish a library to a team. It has no way to define a token set from scratch, only the light and dark themes it ships with, and there is no live browser preview, so a layout is checked by resizing frames.

None of that stops a mockup from being consistent. It changes what consistency means. Instead of a library, you have a reference frame, a spacing scale, seven components and a written list. That is a smaller system, and it is a real one you can keep to.

A system that matches what the tool can do is easier to maintain than one that fights it. Write the limits into the list, so the next person knows the rules before they start rather than after they hit them.

• No component editor, so no components of your own
• No custom token set beyond the light and dark themes
• The limits belong in the written list

A checklist you can reuse

• The spacing scale, type sizes, color roles and recurring blocks are written down
• Every gap and padding in the mockup is a value from the scale
• The seven insertable components are used wherever they fit
• Hand-built patterns are duplicated from one reference copy
• Every screen has been checked in both the light and the dark theme
• Color is described by role, not only by hex value
• The list of what the tool cannot define is included in the system document

Common mistakes to avoid

• Treating the system as a component library. App Builder has no component editor, so the system is a reference frame, a scale and a list. Planning around a library that does not exist wastes the day.
• Rebuilding components that already exist. Stat card, List row, Form field, Call to action, Empty state, Nav header and Tab footer can all be inserted. Hand-building them means seven chances to be inconsistent.
• Using a different padding on every card. Numbers that are close but not equal read as carelessness, and every one of them has to be fixed by hand. Pick the scale and hold to it.
• Checking only one theme. A border that reads clearly in the light theme can vanish in the dark one. Switch the toolbar toggle and look at every screen again.
• Keeping the system in a document nobody opens. A system that lives in a separate file decays the first time someone adds a screen. Keep the list next to the project so it is read while it is needed.

Frequently asked questions

Can I create my own reusable components in Canvasola?

No. App Builder ships seven insertable reusable components: Stat card, List row, Form field, Call to action, Empty state, Nav header and Tab footer. You cannot define your own. The workaround is a reference copy you duplicate, with the same spacing and type values kept each time.

How big should a mockup design system be?

Small. Four decisions cover most mockups: a spacing scale, a type scale, a set of color roles and the recurring blocks. A one-page list of those four plus a screenshot of the reference screen is usually enough to keep a set of screens consistent.

What do the light and dark themes actually change?

They are two token sets in App Builder, switched with a toolbar toggle, and the same toggle changes the HTML export so the exported page follows the theme you were working in. You are choosing between two prepared sets rather than authoring your own.

Is a design system in a mockup worth the time?

It is worth it when the mockup will grow past a handful of screens or when more than one person will work on it. For a single screen, a written spacing scale and a reference frame are enough, and a full system document would be overhead.

This guide is part of the app builder guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.