Building the Steady Mini Kit

A kit that lives in your head is not a kit. Sofia’s test is simple: hand the file to a designer who has never seen Steady, ask them to build a Settings screen, and watch. If they ask “which button do I use?” or “is this teal the real one?”, the kit has failed, no matter how polished the components are.

This lesson turns the pieces from Lessons 3.1 to 3.4 into something that passes that test.

What goes in Steady’s kit

Start from the screens, not from a list of components other apps have. Walk through Today, Habit detail and New habit, and note every element that appears more than once or has states. That inventory is the kit:

Seven components cover all three screens. Resist adding more until a screen needs one. Every component you add must be kept in sync with variables, modes and naming forever.

Structuring the file

Put the kit in its own file, Steady Kit, with a few pages:

• Cover: the kit’s name, an owner, a status (“In progress” or “Stable”) and the date of the last publish.
• Foundations: swatches for every semantic color in both modes, the type scale, the spacing and radius scales. These are visual documentation of the variables, so people can see the system at a glance.
• Components: one section per component, holding the component set, a few example instances in realistic use, and short usage notes in plain text (“Use Ghost buttons for low-priority actions next to a Primary”).
• Playground: a scratch area where people can try instances without touching the components.

Every component also gets a description in its properties panel: one or two sentences on when to use it, plus a link to fuller documentation if you have any. The description appears when people hover the component in the Assets panel and when developers inspect it in Dev Mode, so it travels with the component.

The component checklist

Before a component is called done, it passes the same checks. Writing them down is what turns personal taste into a team standard:

[ ] Built with auto layout; no hand-placed children
[ ] Every color, spacing and radius bound to a semantic variable
[ ] All states designed: default, pressed, focused, disabled (and error for inputs)
[ ] Checked in Light and Dark modes, contrast re-measured in both
[ ] Tested with extreme content: long label, empty value, larger text
[ ] Resized to its minimum and maximum sensible widths
[ ] Properties and values named by meaning, matching the code where possible
[ ] Description written; usage example placed on the Components page

On Organization and Enterprise plans, at the time of writing, Figma’s Check designs can scan a selection for hard-coded values that should be variables and suggest library replacements. On other plans, select a component and read its fills, gaps and padding in the right sidebar: a raw hex code or an unbound number stands out immediately.

Publishing the library

Publishing makes the kit’s components, styles and variables available to other files in your team or organization. At the time of writing, you publish from the Assets panel’s library options, and libraries require a paid or Education plan. Each publish asks for a description of changes. Write it for the person receiving it: “Habit row padding is now 12/16 to match the 8-point scale; no action needed” beats “updates”.

Files that use the library see that updates are available and accept them when they are ready, so a change to the kit never lands silently in the middle of someone’s work. That is also why breaking changes, such as renaming a property, deserve a clear warning in the publish notes.

Section 3 is complete: Steady has a small, themed, documented kit. Section 4 makes it move with prototyping, makes sure everyone can use it, and gets it into developers’ hands.