Before I touch a single prop or layer, I map out every realistic use case for the pattern. Those use cases do not come from intuition alone. They come from real inputs: stakeholder goals, business requirements, developer constraints, accessibility standards, and the needs of designers trying to build new experiences inside the system. A component that does not account for all of those inputs will fail somewhere in production, usually in the least convenient moment.

Once the use cases are mapped I work through a deliberate hierarchy. The appearance panel comes first. Brand palette, theme, density, and breakpoint all live here as variable modes within a single structured collection, so one component can serve multiple visual contexts without duplication. Switching a mode updates everything downstream automatically, colors, spacing, type scale, without touching individual layers.

From there I layer in component properties in a specific order. Anything that is simply on or off becomes a boolean. A heading that might not always appear, a CTA that is optional, a bottom spacer that some layouts need and some do not. Booleans keep the component surface clean by hiding complexity that only appears when it is needed. For choices with multiple valid options, like image position, column count, or content alignment, I use dropdown properties so authors are selecting from a defined set of valid configurations rather than entering free values that could break the layout.

For anything structural that needs to swap between distinct content types I use component slots or instance swaps. But I also think carefully about when to surface a nested instance directly in the properties panel. If a child component, like a button, a badge, or an icon, has its own meaningful configuration that an author will realistically need to control, exposing it as a nested instance property lets them configure it in place without digging into layers. When that relationship is not relevant to the author, I keep it hidden.

Where Figma's composite variable type makes sense, for grouped values like shadows or borders that need to behave as a unit, I use those rather than managing individual properties separately.

The goal is always the same: surface every decision an author genuinely needs to make, and hide everything they should never have to touch. A well-built component should make the right choice feel like the only choice.