A lot of mockup and prototyping tools are based on static images and click-through links, such as the popular tool InVision. This model is successful for delivering a navigable model of a website, and is perfectly acceptable for testing the information architecture of desktop sites. As mobile apps are less about task-based navigation, and more about quick swipes and taps, it is important for designers to be able to be able to communicate the exact interactions they are imagining. With a lot of minute, nebulous details that add up to the “feel” of a mobile interaction (think of the spring-like bounces of a “swipe-down-to-refresh”), being able to show how something will actually work is much more actionable than vague descriptions e.g. “this menu would show up when the custom swipes here”.
So how does Framer work, and what separates it from straight coding? It supports integration with Photoshop (by default) and Sketch (with a plugin) files. This is done by automatically turning the layers/objects from the .psd files into individual fields, without having to go through the tedious process of exporting slices of files and linking them one-by-one. The automatic integration also means that changes made within the visual files are automatically translated into the prototype, allowing for live updates.
Another one of the major perks of Framer is that it bridges the gap between design and development, a problem that is harder to bridge with image linking and wireframes. By having designers work in code, the prototypes are more analogous to the actual product, meaning that 1) designers have an idea of how the tool will be built, and 2) developers will have realistic buildings blocks to start their work. Opinions on whether or not designers should code will vary from person to person, but tools such as Framer do present valuable opportunities in the right environment.
Hack Design. “Prototyping Advanced Mobile Interactions with Framer”.
Stakelon, Jay. “Hello Framer: Getting started with Framer.js”.