2026-10-03 · 7 min · By Alcott Dube
How to start a small team design system with two designers
I start with one active workflow, a few shared foundations and clear ownership, leaving broad component coverage until the product gives me evidence.
To start a small team design system with two designers, I'd standardise one active product workflow, build only its recurring foundations and components, and test them in implementation. I'd split ownership between building and review, reserve a fixed amount of time, and postpone broad libraries, elaborate documentation and automation until repeated use justifies them.
How much time to spend on a first design system
I'd give the first version a two-week window and a budget of eight designer-days in total, four per designer. That's a planning constraint, not an industry benchmark. It leaves room for product work and forces decisions about scope. If the work can't fit, I'd reduce coverage rather than quietly turn two weeks into two months.
I'd choose one workflow already scheduled for delivery: inviting a colleague, updating billing details or creating a project. It should contain repeated controls and at least one failure state. A polished landing page is a weak starting point if most of the product consists of forms and tables.
Before building anything, I'd ask an engineer to review the scope and identify existing coded components. Two designers can maintain the design library, but they can't establish a shared product standard without implementation input. If engineering time isn't available, I'd label the output a design library and keep its promises narrow.
How to audit existing screens without auditing everything
I'd inspect roughly ten screens around the chosen workflow, including loading, empty and error states. For each repeated element, I'd record its purpose, visual differences and implementation status. The useful question is whether two things behave differently, not whether their corner radii happen to differ.
For a settings workflow, I might find six button treatments that represent only three decisions: the main action, an alternative action and a destructive action. I'd consolidate the accidental differences while preserving distinctions that help someone understand a consequence. A deletion confirmation shouldn't become interchangeable with a routine save.
I'd keep the audit in a simple table with a screenshot, proposed decision and owner. I'd stop when I can name the patterns needed for the first release. I wouldn't inventory every historic screen or redesign unrelated features. That produces a larger spreadsheet, but it doesn't make the next implementation decision any easier.
Which design tokens to create first
I'd start with shared colour roles, typography and spacing, adding borders or radii only where the selected workflow needs them. For colour, I'd name intent rather than appearance: text/primary, surface/default and border/error. That gives a future visual change somewhere sensible to happen without renaming every reference.
I'd keep the first token structure shallow. A small set of base values and semantic roles is enough for this scope; component-specific aliases can wait until they solve an actual conflict. Carbon's distinction between underlying values and role-based tokens is useful here. I'd borrow that principle, not reproduce the size of its token catalogue.
I'd agree names and units with the engineer before spreading them through components. A spacing value called one thing in Figma and another in code creates translation work on every handoff. I'd also test real content: a long account name, a validation message and enlarged text. Tidy token names don't guarantee usable layouts.
Which components a two-designer team should build first
I'd build the smallest set that completes the chosen workflow. For an invitation flow, that might mean a button, text field, selection control, inline message and dialog, assuming the dialog is genuinely needed. Five components used together reveal more about the system than twenty isolated examples.
Figma's guidance on components and instances provides the basic reuse model: maintain a shared definition and use instances where that definition should apply. I'd use properties for meaningful differences, such as a label or optional icon. I'd avoid creating variants for every possible combination before those combinations have appeared in the product.
For each component, I'd define its behaviour before polishing its internal construction. What happens with a long label? Can its width change? Does a busy action prevent repeat submission? I'd build one real screen with the components before publishing them. If assembling that screen requires repeated detaching or awkward overrides, I'd fix the component rather than document the workaround.
Which accessibility checks belong in the first release
I'd treat accessibility as part of the component contract, not a later clean-up task. Carbon's accessibility guidance covers responsibilities across design and development. For a small team, that means recording the intended interaction in the design file and checking the actual behaviour in the browser.
For the first form, I'd check visible labels, understandable errors, contrast, keyboard operation and focus visibility. I'd make sure errors aren't communicated by colour alone. For a dialog, I'd agree how focus enters it, stays within it while open and returns after closing. A drawing can't establish that those behaviours work.
I'd check these details in the assembled workflow as well as the isolated component. Individually reasonable controls can still create an awkward focus sequence or confusing error recovery. If time gets tight, I'd cut another component from scope. I'd rather ship three usable controls than six whose disabled, loading and error states remain guesses.
How two designers should share ownership and documentation
I'd make one designer responsible for the current library changes and the other responsible for testing them in product work. Those roles can rotate after a release. I wouldn't have both people independently restructure the same component set; the resulting reconciliation is work the team doesn't need.
I'd publish a component with a short usage note, its supported states, one misuse example and a link to its coded equivalent when available. Carbon's component guidance is a useful model for separating usage decisions from visual specifications. I'd adopt that distinction without trying to match its documentation volume.
I'd keep a visible request list with three outcomes: fix now, test in a feature or leave local. A component doesn't become shared merely because someone drew it twice. I'd look for repeated purpose and compatible behaviour. I'd skip a separate documentation website, a formal committee and automated token export until maintaining the simpler arrangement creates a specific, recurring cost.
How to measure whether a small design system is working
I'd set a narrow release condition: the chosen workflow uses the agreed components, the corresponding code has been reviewed, and known exceptions are recorded. Publishing a Figma library isn't the finish line. The first useful result is a working feature whose common decisions don't need to be made again.
For the next two features, I'd track how many shared patterns were reused, how many required exceptions and which inconsistencies reached implementation. I'd also note time spent maintaining the library. These are local observations, not proof of a general productivity gain, and I'd avoid converting them into a percentage without a credible baseline.
I'd let those observations set the next batch of work. Repeated table problems justify table patterns; a hypothetical future dashboard doesn't. If maintenance starts taking more time than the repeated decisions it removes, I'd simplify the library. A local component can stay local until sharing it costs less than keeping it separate.
Questions people ask
Can two designers build a design system?
Yes. I'd keep the initial scope to one workflow and involve an engineer early, because the design library alone doesn't establish how shared components behave in the product.
How many components should a small design system start with?
I'd start with roughly three to six components if that covers the selected workflow. That's a scope suggestion, not a target worth filling with unnecessary controls.
Do I need design tokens before building components?
I'd establish a few shared colour, type and spacing decisions while building the first components. I wouldn't delay useful component work to finish a token structure for needs that haven't appeared.
Should a small team build or use an existing component library?
I'd inspect the existing coded library first and test its fit against the workflow. I'd prefer adopting it when its behaviour, accessibility and styling constraints fit, rather than taking on avoidable maintenance.