Find out what you have
before you build the library.

An interface inventory is a visual audit where you collect every existing instance of a given pattern from the real product and put them together in one place. You take screenshots of every button, every form field, every card, every modal, wherever they appear, and lay them out side by side. The purpose is to make duplication undeniable. Teams reliably believe they have three or four button variants and reliably discover eleven, because the variants were introduced at different times by different people in different files and nobody has ever seen them adjacent. It is unglamorous manual work, and it is the single most valuable thing you can do before building a system.

Not during early access. Storyflow is paid-only right now, with plans starting at $9.99 a month, and a Free plan launches before the end of 2026. Anyone a paid member invites to a board joins free today, so engineering and stakeholders can review the inventory and scope without paying. If you want something free this minute, a shared slide deck of screenshots does the inventory job adequately, though regrouping is slower than on a canvas.

No, and it should not. Storyflow does not build components, does not publish a library, does not generate or sync design tokens, does not read your codebase, and does not connect to Figma. The system itself belongs in Figma for the design side and in code with something like Storybook for the implementation side. What Storyflow covers is the phase before that: the inventory, the scope decision, the naming, and the sequence. That phase is where design systems most often go wrong, and it is also the phase with no dedicated tooling.

Almost always for planning reasons rather than execution reasons. Starting with components instead of an inventory means the system encodes remembered patterns rather than real ones. Over-scoping means six months pass with nothing shipped and the sponsor loses interest. Leaving naming unresolved means every review relitigates it. But the most common failure is the one that looks like success: a complete, beautiful component library that nobody adopts, because it arrived without a migration path and shipping features was always more urgent than refactoring working screens. Adoption has to be planned as deliberately as the components, and it rarely is.

Whatever is causing the most pain right now, which is usually not what is theoretically foundational. There is a strong instinct to start with tokens, then primitives, then simple components, working upward in a satisfying dependency order. The problem is that this delivers no visible relief for months, and momentum matters more than architecture in the early stage of a system. If every team is rebuilding a data table badly, build the data table, even though it is complicated and depends on things you have not formalised yet. Solving a real, felt problem is what earns the mandate to continue.

No. Storyflow does not connect to Figma or read your codebase, so it cannot enumerate your components or find your duplicates. The inventory has to be done by hand, which is genuinely tedious and also genuinely where the value is, because the act of collecting the instances is what produces the understanding. What the AI can do is lay out the planning structure and draft the list of states and variants a given component type typically needs, which you then reconcile against what your product actually uses.

Bring them into scoping rather than presenting scope to them, and do it before anything is drawn. Engineers know which patterns are genuinely painful to maintain, and that list is not the same as the list of patterns that look inconsistent in the interface. A component with three visual variants might be trivial in code, while one that looks consistent might have four separate implementations. Sharing a view-only link means they can review the inventory without needing a design tool seat, which removes the most common practical barrier.

Run the inventory and let it tell you. If the audit turns up three button variants and two card styles, you do not need a design system; you need an afternoon of cleanup and a short style guide. Design systems earn their considerable ongoing cost when there are enough people producing enough interface that inconsistency arises faster than anyone can manually correct it. Doing the inventory first means this question gets answered with evidence rather than with enthusiasm, and occasionally the honest answer is not yet.

Yes. The design system plan can sit beside the style guide that documents the visual language, the handoff boards where components meet engineering, and the research that motivated the patterns. That adjacency helps most when scope questions arise later, because you can see whether a proposed component is genuinely new or a variant of something the inventory already captured under a different name.