engineering-onboarding

Context

Engineering onboarding is genuinely different from designer onboarding. The mental model is different (consuming an API vs composing with a library), the first tasks are different (install and import vs connect Figma library), the tooling is different (package manager, TypeScript types, test harness vs Figma, documentation platform). Most importantly, engineers are where component drift originates — wrapping system components in local styled wrappers, hardcoding token values, reimplementing components locally. Proper onboarding from day one is the highest-leverage adoption intervention.

Key principles

From design-to-code-contract: Engineers and designers operate on opposite sides of the contract. Designers compose with a library (Figma, Storybook). Engineers consume an API (imports, props, types). The contract is the component signature: what props it accepts, what slots it exposes, what variants are possible. Component drift begins when an engineer builds a local wrapper because "the system component is close but not quite right" — escalating to designers too late means the system lost control. Onboarding embeds the contract from day one.

Key principle for engineers: Do not wrap system components. Do not hardcode values. Do not copy source code. Ask first.

Configuration

Before writing the guide, gather these inputs: