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.
\nThis lesson turns the pieces from Lessons 3.1 to 3.4 into something that passes that test.
\nStart 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:
\n| Component | \nVariant properties | \nOther properties | \n
|---|---|---|
| Button | \nType, State, Size | \nLabel (text), Show icon (boolean), Icon (instance swap) | \n
| Check button | \nState: To do, Done, Missed | \nnone | \n
| Habit icon | \nnone | \nGlyph (instance swap) | \n
| Habit row | \nState: To do, Done, Missed | \nName (text), Show streak (boolean), Icon (instance swap) | \n
| Chip | \nSelected: true, false | \nLabel (text) | \n
| Text field | \nState: Default, Focused, Error, Disabled | \nLabel, Hint (text) | \n
| Tab bar | \nActive: Today, Stats, Settings | \nnone | \n
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.
\nPut the kit in its own file, Steady Kit, with a few pages:
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.
\nBefore a component is called done, it passes the same checks. Writing them down is what turns personal taste into a team standard:
\n[ ] Built with auto layout; no hand-placed children\n[ ] Every color, spacing and radius bound to a semantic variable\n[ ] All states designed: default, pressed, focused, disabled (and error for inputs)\n[ ] Checked in Light and Dark modes, contrast re-measured in both\n[ ] Tested with extreme content: long label, empty value, larger text\n[ ] Resized to its minimum and maximum sensible widths\n[ ] Properties and values named by meaning, matching the code where possible\n[ ] Description written; usage example placed on the Components pageOn 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.
\n\nPublishing 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”.
\nFiles 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.
\n\nSection 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.
\n","toc":[{"id":"sec-1","text":"What goes in Steady’s kit","level":2},{"id":"sec-2","text":"Structuring the file","level":2},{"id":"sec-3","text":"The component checklist","level":2},{"id":"sec-4","text":"Publishing the library","level":2}],"takeaways":["A kit is useful when someone else can find, understand and use a component without asking you, so structure and documentation matter as much as the components.","Build the kit from patterns the screens actually repeat, and add a component only when a real screen needs it.","Every component should pass the same checklist, covering auto layout, variables, states, both modes, extreme content and a description.","Publishing a library lets other files use the kit, and every publish should explain what changed so subscribers can review updates.","Names are an interface; pick one convention for components, properties and values and use it everywhere."],"further":[{"title":"Lesson 3, Build your design system (Figma)","url":"https://help.figma.com/hc/en-us/articles/14548865734679-Lesson-3-Build-your-design-system"},{"title":"Guide to libraries in Figma","url":"https://help.figma.com/hc/en-us/articles/360041051154-Guide-to-libraries-in-Figma"},{"title":"Check designs in Figma","url":"https://help.figma.com/hc/en-us/articles/39592284074263-Check-designs-in-Figma"}],"quiz":[{"q":"A designer proposes building a Carousel, a Data table and a Date range picker for Steady’s kit “so we’re ready”. None of Steady’s screens uses them. What should Sofia say?
","options":[{"text":"Build them now, because adding components later is expensive.","why":"Components built without a real use are usually wrong when the real use arrives, and they still need maintaining in the meantime."},{"text":"Build them but hide them from the library.","why":"Hidden or not, they cost time to make and keep in sync with variables and modes."},{"text":"Wait until a screen needs them, then build them from that real use.","why":"Correct. A kit grows from repeated patterns in real screens, which keeps it small and every component justified."},{"text":"Copy them from a community kit to save time.","why":"Borrowed components bring someone else’s tokens, names and assumptions, so they rarely fit without rework."}],"answer":2},{"q":"You publish an update to the Steady kit that changes the habit row’s padding. What happens in a screens file that uses the library?
","options":[{"text":"Instances in that file change instantly with no notice.","why":"Library updates are offered to subscribing files for review, not applied silently."},{"text":"The file is notified of available updates, and someone reviews and accepts them.","why":"Correct. Subscribers see that updates are available and choose when to accept them, which is why publish notes matter."},{"text":"Nothing, because instances from libraries never update.","why":"They do update once the file accepts the library update. That is the whole point of a library."},{"text":"The screens file is duplicated so the old version is kept.","why":"Figma does not duplicate files on library updates. Version history covers rollback."}],"answer":1},{"q":"Which item belongs on Steady’s component checklist because it catches the most bugs before handoff?
","options":[{"text":"The component looks good at its default size in light mode.","why":"That is where it was designed, so it almost always passes. Bugs live at the edges."},{"text":"The component has a drop shadow.","why":"Shadows are a style choice, not a quality check."},{"text":"The component uses the newest Figma feature available.","why":"Newer features are not automatically better for the people using the kit."},{"text":"The component has been tested with extreme content, both modes and its narrowest and widest sizes.","why":"Correct. Long labels, dark mode and resizing are where components break, so the checklist forces those tests."}],"answer":3}],"exercise":{"kind":"spot-bug","language":"text","code":"Components page\n Section: Buttons\n Button component set Type: Primary | Secondary | Ghost\n State: Default | Pressed | Disabled\n Label: text Show icon: boolean Icon: instance swap\n Button 2 component copy of Button/Primary with an icon\n Section: Controls\n Check button component set State: To do | Done | Missed\n Chip component set Selected: true | false Label: text\n Toggle component set State: Teal | Grey\n Section: Rows\n Habit row component set State: To do | Done | Missed\n Name: text Show streak: boolean\n Row background fill: #FFFFFF\n Text field component set State: Default | Focused | Error | Disabled","bugLines":[6,10,14],"title":"Audit the kit before publishing","prompt":"Before the first publish of the Steady Kit, Sofia asks you to audit the Components page. Here it is written out as text. Check it against the component checklist from the lesson, focusing on duplication, naming and variables (states get their own review in Lesson 4.2), and select every line that should block the publish.
\n","hints":["Look for anything that duplicates an existing component instead of using its properties.","Check that values are named by meaning and that colors come from variables.","Three lines: a near-duplicate main component, appearance-based values, and a hard-coded fill."],"explanation":"Line 6: Button 2 is a second main component that duplicates Button with an icon. The Button already has a Show icon boolean and an Icon instance swap, so delete the copy and use the property; otherwise every fix must be made twice. Line 10: the Toggle’s values Teal | Grey describe appearance; in dark mode or after a rebrand they lie. Use On | Off. Line 14: the row background has a hard-coded #FFFFFF fill, so it will stay white in dark mode. Bind it to color/surface/default.