What a design system is (and isn't)
A design system is the set of documented, shared design decisions a team uses to build digital products consistently: design tokens (colors, typography, spacing), reusable components, interaction patterns, and usage guidelines.
What it's NOT: a Figma file full of nice-looking components. Without documentation, without usage criteria, and without active maintenance, it's just a gallery.
When it's actually worth having one
It makes sense when: more than one person works on design or development, the project has multiple pages with repeated patterns, the product is going to evolve over time, or visual inconsistencies are causing frequent rework. For a static 5-page site, the overhead isn't worth it.
The components of the most basic design system
Design tokens: the fundamental variables. Colors (primary, secondary, neutrals, semantic), typography (families, sizes, weights), spacing (an 8px scale), and shadows. In code, these are implemented as CSS variables. Change one token and the entire interface updates.
Base components: buttons with all their states (default, hover, active, disabled, loading), inputs and forms, cards, modals, navigation, and empty and error states.
Documentation: the part nobody wants to do
A component without documentation is a component that will get misused. The bare minimum documentation: when to use it and when not to, the variants available, and examples of correct and incorrect usage.
Where to start without getting overwhelmed
Start with the tokens (colors and typography). Then extract the components that already exist in the design instead of building them from scratch. Document as you build. A design system that grows out of a real project is far more useful than one designed in a vacuum.