Requirements — Design system in Figma

None of this is the build itself. It’s what you need to hand so you don’t stop halfway through.

Accounts and tools

A Figma account on a plan that lets you keep a shared library and use it across files. Check Figma’s current plans before you choose; what each one includes changes.
Your store platform, with the theme you’ll build on, and a safe copy or preview of it you can change without touching the live store.
Admin access to the theme’s settings, so you can see how its sections and blocks are actually put together.

Brand assets: logo files, fonts (with licences that cover web use), colour values and photography.
Whatever brand guide exists today, even if it’s out of date. It’s a starting point, not the answer.
Screenshots of every page template the store runs on now, at desktop and mobile widths.
Your analytics, so you know which templates get the most traffic and can build those first.

Solo: protected time in blocks. This work doesn’t happen in the gaps between orders.
Team: one owner for the system. Others can contribute, but one person decides.
Whoever builds and maintains the theme (you, a developer or an agency) agreeing to work from the system once it exists.

Base theme. Keep the theme you have, or move to a more flexible one before you build the system around it.
Scope of the first pass. Every template eventually. The most-visited ones first.
Naming. One naming convention for variables and components, agreed before anything is built. People and AI both rely on it.
Source of truth. When Figma and the live theme disagree, which one wins. For Springspot, it’s Figma, kept in step with the theme.
Modes and variants. Whether you need more than one mode or brand now, such as dark mode, a second store or another market, or whether that can wait.
Ownership. Who approves a change to the system, and how a change gets from Figma to the live theme.

Next: the Checklist, so you know what a 4 looks like before you start.