Flowstep early access is open. If you got the email or saw the announcement, this post is for you. It covers what the product actually does, why we built it the specific way we did, and what we learned from a private cohort we ran through it in the week before today.
What the product actually does
Flowstep takes a written brief and produces editable interface screens that already use your team's own design tokens. Not generic placeholder colors. Not stock components you'll need to re-theme. Your tokens, mapped from the start.
The mechanism: you connect your design system (via a JSON token file, a Figma tokens plugin, or Tokens Studio JSON), write a brief describing the screen you need, and Flowstep resolves your token set against that brief before generating any output. The result is an editable frame you can open directly in Figma or Sketch, with every color, spacing value, and component variant already mapped to your system's own token paths.
The part we care about most is the token mapping step, not the screen generation step. Generating a plausible-looking screen is not the hard problem. Generating one where --color-interactive-500 shows up on the primary button instead of whatever hex value the generator felt like using is where the actual work lives.
The disconnect we were trying to solve
The problem has a specific shape. A designer writes a brief that uses their design system's vocabulary: "primary action button", "destructive variant", "secondary surface". A mockup tool generates something that looks approximately right but uses whatever colors it defaults to. The visual output can be presentable while the token mapping is completely wrong.
That matters because of what happens downstream. A developer receives the mockup, cannot read the token context from a flat image, and has to either ask the designer or guess. That conversation happens once per component, across every sprint, for every team that relies on flat images as a handoff medium. It compounds. Most teams have absorbed this cost as a fixed overhead rather than a solvable problem.
We're not claiming Flowstep eliminates all handoff friction. What we're claiming is narrower: a brief that names your design system's vocabulary should produce a frame that already speaks that vocabulary. The goal is that the file you open after Flowstep generates it is a real starting point, not a re-theming job.
What the first week showed us
We ran a private cohort through Flowstep for about a week before today's announcement. A few patterns emerged clearly.
The teams who got the most immediate value were ones with a mature semantic token layer. If your design system has alias chains set up, where semantic names point at primitive values, Flowstep has something concrete to resolve against. If your system is mostly primitive values with no semantic layer, the output is less precise. There is simply less for the resolution engine to anchor to.
One team that had component-level tokens set up, things like --button-bg-primary, --input-border-focus, --modal-surface, saw Flowstep map correctly to those paths on the first attempt. That was exactly the case we had designed for. Another team whose design system existed primarily as a Figma library without exported token JSON had a rougher experience, which is expected given how the engine works.
The second pattern: brief specificity correlates strongly with output quality. A brief that says "a dashboard screen" produces something generic. A brief that says "a data export settings screen with three permission levels and a cancel/confirm button pair at the bottom" gives the system enough context to produce something precise. Brief quality is not a Flowstep-specific issue, but it is pronounced when the output is supposed to be token-aligned.
A few things we are not claiming
Flowstep works best with design systems that have a defined semantic token layer and a usable token export. Systems that exist only inside Figma without any token export have less for the resolution engine to work with. That is a real constraint and we want to name it plainly.
The generated screens are not production-ready without review. The intended use is: Flowstep generates a token-aligned starting file, the designer opens it and works from there. The value is skipping the re-theming step and starting with correct tokens, not shipping Flowstep's output directly.
We're in early access because we want to learn from teams working in real workflows. If the token coverage on your design system is partial, or if your brief-to-output results look off in a specific way, that feedback is exactly what this phase is for. The onboarding flow walks you through connecting your design system first. That step matters most.
