First Release Scope

## What a first release is for A **design system** is the shared set of foundations, components and guidance that product teams consume instead of building their own. Its **first release** is the first version real teams build with. Its job is not to cover everything; it is to prove that the system saves effort and improves quality, to start a feedback loop with real consumers, and to earn the trust that later releases depend on. Scope decisions follow from that job. ## Foundations first **Foundations** are the shared visual decisions everything else is built from: - **Color** — brand, neutral and status colors, organised as tokens. - **Typography** — the type styles used for headings, body text and labels. - **Spacing and sizing** — the values that control rhythm and density. - **Elevation and shape** — shadows, borders and corner treatment. - **Core icons** — the handful of glyphs almost every screen uses. They come first because every component consumes them, and because a product can adopt them without replacing its structure, which spreads consistency widely at low cost. ## Scoring components For components, a simple scoring pass keeps the choice evidence-based: 1. **List candidates** from the interface inventory, with how many screens and teams use each. 2. **Rate pain**: how inconsistent the current versions are, whether they have accessibility defects, how often teams rebuild them, and how many bugs they generate. 3. **Estimate effort**, including research, documentation and delivery on both web and native mobile. 4. **Add the pilot's roadmap**: components the pilot team needs for its next features get a boost. 5. **Rank and cut**: take the top of the list that fits the release, and write down what was deferred and why. | Candidate on the marketplace | Usage | Pain | Effort | Verdict | |---|---|---|---|---| | Button | Every screen | Six styles, weak focus states | Low | First release | | Text field and select | Search, profile, proposals | Inconsistent error messages | Medium | First release | | Job card | Search, saved jobs, recommendations | Four layouts | Medium | First release | | Proposal list row | Client and freelancer dashboards | Rebuilt per team | Medium | First release, needed by the pilot | | Contract milestone timeline | One screen | Moderate | High | Later | ## Small but complete A component in the first release should be **complete**: documented with usage guidance, meeting the system's accessibility and quality bar, working in every state, and available on the platforms the pilot uses. Five complete components earn more trust than fifteen that each need workarounds, because the first team's experience becomes the story every other team hears. ## What to leave out - **One-off components** used on a single screen, unless the pilot needs them now. - **Highly complex components** — data grids, date-range pickers — that need research before their API can be right. - **Product-specific patterns** that belong in one product rather than in shared code. - **Speculative items** nobody has asked for yet. ## Example: a freelance job marketplace The marketplace's inventory shows buttons on every screen in six styles, a job card in four layouts across search and recommendations, and a proposal list row rebuilt separately by the client and freelancer teams. The pilot team is about to redesign the proposal flow. The first release therefore ships the foundations, buttons, text fields, selects, the job card and the proposal row — each documented, accessible and available on web and mobile — and explicitly defers the milestone timeline and the messaging composer, with the reasons recorded so the next scope discussion starts from evidence.