Dev Mode - What is the workflow supposed to be for designers?

Okay so, I’ve played around with Dev Mode a bit, and watched/read what was put out over the last couple of days; and I have a question.

What is the workflow supposed to be for a designer making changes?

Let’s walk through an example.

I have an application with a login page. The client has signed this off, we’ve just marked this for “Ready for development” and saved it as a new version inside of Figma. Awesome, now the developers can get to work.

Meanwhile, the client has come back and said they would like to try a new button colour on the login page. That’s fine, let’s try out some new colours.

This presents a problem now though, no?

Any changes I make to that button colour, will be shown to the developers in Dev Mode.

I don’t want to remove the “Ready for development” status for the Login page, as we’re still iterating through concepts, and there’s no need to stop development on the page until we decide on a new button colour.

My expectation on how this would work would be similar to how it works for developers in their workflows.

The designer would be working in a “designer” mode, where I can make as many changes and iterations as I wanted. But the developer wouldn’t see those changes until I published them to a new developer version of the file (this would be similar to how you can select what components you want to update when publishing a shared library - I should be able to select what sections/frames I want to publish to the new developer version).

Currently the way that Dev Mode is implemented, I still have to separate developer and designer frames. We need developers working on pages that have been approved by the client, and we need designers to be able to iterate on those pages with the client, but without the developers seeing those changes until the client agrees to a new version.

Am I missing something here? I didn’t think this would have been an unusual case.


From the beta version, I feel Dev mode is mainly trying to improve the using experience of developers (plugins, more intuitive UI to see the parameter of selected elements). I do agree that seems only the “Mark as ready for dev” feature relates to the designer’s workflow.


A great addition to the status would be to allow Designers to mark changes that notify the Developers (with compare feature inside Dev Mode).
In the current form all this feels more oriented towards the classic “handoff” process, which in my opinion is somewhat outdated. As you said, iterations and parallel work follow a different kind of process and I think the Status feature needs to account for that.

Overall I question the need for a developer view at all.

One of the values of “the Figma way” (to me) is that it has a useful overlap for developers and designers. They both work on the same asset more or less the same way, with some useful features for export/handoff.

It’s mentioned in another comment: this moves towards a harder delineation between designer and developer, which IMHO is a step backward (we already have tools that are essentially output generators for developers). This generally leads to things like, “yeah I got the assets from the tool but I needed to edit some of the CSS and that’s a pain in the tool so I just did it manually.” Boom…drift. The effect of “The Figma Way” becomes somewhat marginal.

Instead of something like “ready for development”, I’d just tag thing with the phase of design they’re in: in progress, in review, complete. Developers aren’t the only ones that use “complete” assets, other designers commonly use assets from Figma files too.

And one other thing: please, in the Developer view, make the style windows editable (as they used to be). Or, put them back in the design view under an “Advanced” tab or something. For what it’s worth, with that restored, I may never use developer view.


And I think it is also very necessary for designers also can easily switch to see the codes. But now dev mode seems more likely just want to increase the bill for users.


That’s exactly the overlap I’m talking about. Designers and developers don’t have such a hard line between them; “I just generate the styles, I don’t actually deal with the CSS” vs. “I just deal with the CSS I don’t get involved in generating the styles.”

Everybody deals with the CSS all the time pretty much. Those windows need to be up-front and editable.

1 Like

Have you considered using branches for this workflow?

This would be an approach that would make a lot of sense to your dev team (if nothing else).

would love to, but that’s only available on the org plan.