Package C · component sheet
A component sheet your designers can build from
Up to thirty components — buttons, inputs, tables, menus and the rest — drawn in every state, measured against one spacing scale, and documented with tokens and usage notes your developers can map straight into code.
Four to five weeks. Hand-over session with your developers included.
Start a packageStarting from what you already have
Most products already contain a component library; it is just scattered. There are four kinds of button, three grey borders that should be one, and a table that behaves differently on every page. The sheet begins with an inventory: we collect every instance of every component in the shipped product and lay them side by side.
From the inventory we propose a merged set — where two parts do the same job, one survives. You approve the list before we draw anything, and the list is what the thirty-component limit counts against. A button in five sizes is one component; a button and an icon button are two.
If your product is new and there is nothing to inventory, we start from the screens you have designed so far, or from the flow in a prototype we have drawn for you.
Typical contents
- Buttons, links, icon buttons and toggles
- Text inputs, selects, checkboxes, radio groups, date fields
- Tables with sorting, empty rows and overflowing cells
- Menus, tabs, dialogs, toasts and inline messages
- Cards, list rows, badges and avatars
Tokens, spacing and states
Everything on the sheet is measured against named tokens rather than loose values. A token is a named decision — a colour, a size, a gap — that designers and developers both refer to by name. If the brand colour changes, it changes once.
- Spacing scale: one geometric scale of gaps, named from the smallest step upward, used for padding, margins and the space between items. Nothing on the sheet sits at an off-scale value.
- Type scale: a short list of text styles, each with size, line height and weight, named by role (body, label, heading) rather than by size.
- Colour tokens: named by purpose — surface, text, border, accent, danger — with each text pairing checked for readable contrast.
- Radius, border and elevation tokens: so corners and shadows stop drifting between screens.
Each component is then drawn in every state it can be in: default, hover, focus, pressed, disabled, loading, and error where it applies. Focus states get particular care because they are the ones most often forgotten, and the ones keyboard users depend on.
Documentation and hand-over to developers
Beside each component sits a short usage note: what it is for, when not to use it, what its label should say, and how it behaves in its error state. The notes are written for the designer who joins your team next year and has nobody to ask.
Hand-over happens in a session with your developers. We go through the tokens first, because once the tokens are in code the components follow quickly, then through the components in the order your team plans to build them. Questions raised in the session are answered in writing and added to the sheet.
We do not write the components in code, set up a code repository or publish a package. The sheet is a design file and a document; turning it into code is your developers' work, and the sheet is drawn to make that work quick and unambiguous.
What arrives
- The component sheet as a design file you own, organised by component, every state drawn.
- A token list your developers can copy names from.
- Usage notes beside every component.
- A recorded walk-through, plus the live hand-over session.
Timeline and price
Four to five weeks from the day the deposit arrives, with the date fixed in the written scope. Two rounds of revisions are included. A product that needs more than thirty components is quoted as a second sheet, never stretched silently.
| Item | What it covers | Price |
|---|---|---|
| Component sheet (up to 30 components) | Inventory, merged set, tokens, every state drawn, usage notes, hand-over session | €3,200 |