A design system for a team of five

A design system for startups, at this size, is a short list the whole team can keep. For five people it holds type, color, space, and a handful of components. Those decisions live in one design file and in the code that ships. The list exists so a new screen can be built from choices you already made.

Five people can share a product, a marketing site, and a brand. They cannot staff an unbounded kit with its own roadmap. When the system needs a dedicated owner who does nothing else, it has outgrown the team that is supposed to use it. Keep it small enough that shipping the product remains the work.

What the small system holds

Start with type. Pick one family for the interface, or a pair when the brand needs a display face and a text face. Set the sizes you already use: a page title, a section title, body copy, and a small label. Write down the weight and the line height for each. A twelve-step scale looks thorough and goes unused. Four sizes that appear on real screens will be used every day.

Color is a short list with names. Background, surface, primary text, muted text, a hairline, and one accent. Add a color for destructive actions if the product can fail in a way the person must notice. Stop until a real screen demands another entry. Each color has to work on the surface it sits on. The W3C organizes the Web Content Accessibility Guidelines under four principles: perceivable, operable, understandable, and robust. A small system should protect the first two from the start. Text should be readable against its background, and a control should show where keyboard focus is. Those are color and component decisions, recorded with the rest of the list, checked before launch week.

Space is the part teams forget to name. Choose a tight gap inside a control, a normal gap between related items, and a large gap between sections. Use one corner radius on buttons, inputs, and cards. When space and radius have names, a new page looks related to the last one without a meeting to discuss the feel.

Components come last, and only the ones you repeat. A button, a text field, a text link, a card, and the navigation you already have. If a control appears on a single screen, leave it in that layout. Promoting it into the shared list creates a component nobody will reuse, and then the list starts to look like a catalog.

What you leave for later

A large system documents every state of every control, plus a documentation site, a contribution guide, and a versioning policy. That work is real when many squads ship in parallel. It is a different project from the one a founder is trying to launch.

Leave illustration sets, motion specs, and a full palette for charts until those things repeat. Leave out tokens that no screen uses. A named value with no consumer is a guess you will have to defend later.

Keep the system out of the sales story. Customers buy a product that feels consistent. They do not buy your token names. The system is how the team produces that consistency. On a Hanabi project the same standard shows up in the public site: clarity over complexity, with the decisions written down so the next edit does not invent a new palette.

Where the decisions live

Keep two copies that say the same thing. In Figma, one page with the type, the colors, the spacing, and the few components. In the repository, the same values as tokens the components read. Hanabi builds interfaces with React, TypeScript, and Tailwind, so the practical version is a small theme and a small set of components that import it. The name a designer uses and the name an engineer imports should be the same word.

When the copies diverge, trust what shipped, and update the design file the same day. A system that lives only in Figma drifts the moment someone implements a screen under time pressure. A system that lives only in code drifts the moment someone designs the next screen from memory.

Prefer plain names. Ink, paper, line, and accent are easier to remember than a scale nobody memorized. If you prefer numbers, keep the scale short and add one line beside each step saying where it is used. A name nobody can say out loud will be bypassed the first time someone is in a hurry.

How five people keep it

Name one owner. The owner is not a full-time systems designer. They are the person who says yes when someone wants a new color or a new component. On a team of five that person is often the founder, or the designer who is also shipping the product. The job is small. Hear the exception. Fold it into the list, or keep it local and say why.

Everyone else starts from the list. A new screen uses the type, the colors, and the components. If something is missing, ask before drawing a one-off. The ask can be a sentence in the project channel. The answer is a sentence too: use this existing piece, or here is the new decision and the file where it was added.

Review the system when you review the work. In a critique, look for type, color, and components that escaped the list. Fixing one stray button is cheaper than rediscovering the palette six screens later. The critique question is whether the screen could have been built from the decisions you already published to the team.

A useful weekly habit is a five-minute pass, not a workshop. Open the latest screen next to the token page. Note anything that introduced a new size, a new hex value, or a new radius. Either adopt it, because the product needed it, or replace it before the next person copies it. Five minutes is enough when the list itself is short. An hour-long systems meeting is a sign the list has become a second product.

When the list should grow

The small system is enough while one product and one site share one visual idea. It gets strained when a second product, or a second designer working in a separate file, starts making parallel choices. Growing the system at that moment is a real project. Inventing it earlier, while one person is still drawing every screen, usually produces a kit that sits beside the work and slowly goes stale.

You can tell the list is still the right size when a new teammate can build a routine screen from it in an afternoon, and when the owner can explain every entry without a slide. You can tell it is too small when people keep a private overlay of exceptions that never make it back into the shared file. That overlay is the next system, whether you name it or not.

If you are still deciding whether a shared system is due, the next piece is the test for that moment: when a startup needs a design system. It separates a disciplined file from the point where a second style would otherwise appear.

When you want the short list designed and built with the product, see Hanabi's services. The studio treats a design system as part of the interface work, sized to the team that will keep using it.