Where the design community meets.
I don't quite understand the argument. Obviously, if you decide to change something, you have to apply these changes to the design file, the interaction prototype and the real product. But how is this the fault of the tools you use in each step?
I will try to explain it further. I design a user flow in sketch. Than i move over to principle / flinto and so on. Now my Developer / Client / Stakeholder / PM says change this or that. I go back make my changes in Sketch two views will disappear another complete different will be placed, the interaction changed. The prototype is useless, it might be faster to create a new one. This is what i meant with dead end, it is time consuming to change the prototype, if you work in sprints like i do you won't have the time to make changes all over the place. Like i said above on another comment i only do prototypes when developers ask me to do and only after the story is set and the developer is on it. But to elaborate and test designs i am not sure that it is a good thing to play with principle or other high fidelity prototyping tools. Besides the dribbble people who do it for fame ;-)
Sure thing ... but the fact, that prototypes take a lot of time and therefore iterating on them constantly is not a viable option in every situation, is not the fault of the tool (which I had the impression you were implying with "dead end" in the first place).
Oh then i might explained it not correctly. But i think you know what i meant with Dead End.
Still want to add something to our conversation. I think that all the prototyping tools (and i tried a lot of them) aren't suited for designing user flows. Because in the end in my experience is that some, of course not all prototypes are over the top. These tools seduces the designer while working with it to create a cool transition or a crazy interaction. Which the developer in most cases cannot reproduce in a short time and i worked with winners of the Apple Design Award. Because the focus will then lie on animation/transition instead of flow and interaction.
For me are transitions and crazy interactions are only used when it brings performance or a better experience. I see it more as a cherry on the cake.
I understand what you are saying, and I promise you that most of us work in Sprints, and "Agile" environments with living products. Just because a flow changes doesn't mean the entire interaction design isn't broken. You can add another view into the flow, or alter as needed, updating the few behaviors that need changes. We do occasionally make those rare rapid changes before implementation (even scrapping entire flows), but more often we have simpler clickthrough prototypes, and white-boarding sessions that decide flows before we ever get to adding the micro-interactions that Flinto, etc are intended to provide.
I'd also wager most of us (myself included) don't do an entire prototype flow within Flinto, ProtoPie, Principle, etc. but instead use them to show complex visual behaviors that provide callouts, direct the user, and enhance the overall experience. I can't imagine (nor would I recommend) doing an entire application flow in those tools, and would never attempt to do that.
Figma clickthroughs have been mainly what we use now, and jump into Principle (as of late) for micro-interactions, and to demonstrate to the development team how we want something to function. I've even created quick prototypes with vanilla HTML, CSS and JS.
Jan, I come from a developer perspective (35 years) and I'm crazy in love with Supernova Studio because it backs up what you do in design with full code generation. (I also have a long pedigree in code-gen having worked on the two dominant products in Classic MacOS days).
I have long despaired about how the tooling world was ever-focused on products which only got as far as generating image assets and sometimes videos for hand-over but had no brakes to bring them back to reality. Obviously, a skilled dev team can build anything but the budget often doesn't allow for it.
Supernova Studio requires you start in Sketch and their one weak point at this time is re-importing a single screen loses some details, but it's a team that moves very fast so any criticism you read needs to be current.
After importing static screens from Sketch you then set properties, add animation, prototyping links between pages and generate full working native code or React Native apps.
Because it's constraining your work to the needs of the code generator, it's like having a developer by your side continuously. They also have a cloud product for sharing designs and reviewing.
Two other products worth looking at if you're just prototyping animations but want working output:
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.