[zapt02]

As a developer, I feel like the target market are product owners or managers that want to pretend to have bigger product insight than is viable for their role. At the point where you're building these complex mockups featuring real logic and real code you might as well code it out. If it takes you much longer to release a test build than make a prototype in this cluttered UI then you should be working on your tooling.

[jhanschoo]

It depends on how tolerant your application is dependent on bugs. I see this as a user-friendly intermediate between mainstream programming and formally-verified programming:

It is easy to see that your program is in one of several states ensure that its state-transition behaviors are consistent with the state transitions you have designed, and it is easy enough to reason about state transitions at a high enough level. On the other hand, it is difficult to reason about the state of multiple asynchronous components. This will help with that.

In addition, when designing a new feature, I can see this helping to decide where would be an appropriate and natural place to tack on the feature.

[lebek]

I think the interactive diagram is the most important artifact here, rather than the visual prototype. The synchronized combination of the two is even better.

This kind of thing isn't usually implemented as a formal state machine in "real" code, so even if designers were capable of writing the "real" code, they wouldn't be able to automatically generate an interactive diagram the way this thing can.