Using Framer to prototype page transitions

As web technologies are evolving at a fast pace, so are the trends in design. Mobile experiences and the way they evolved creatively have set the stage for more fluid, almost magical web interfaces, leaving behind the era when we talked about websites as having separate pages that load instantly and paving the way for the ones that behave naturally and come alive through transitions and animations. This lets us create stories that are better told on desktops than on mobile phones because of the bigger canvas we can take advantage of.

Prototyping transitions

When we talk about prototyping we think of prototyping flows. Product flow prototypes let you experience the product early on, making it easy to identify and fix functionality and user experience issues through user testing. But more than prototyping flows, there are very few tools that let you go focus on simulating very accurately page transitions and interactions. Especially ones that give you control over even the smallest details or the transition.

At Namogo we started looking into how we can perfect the design process to make room for exploring how views or pages transition from one another and how elements react, change or transform to adapt for new content.

Creating an interface that surprises and delights means adding this extra layer in the design process. One that is both necessary and a pleasure to work on. We explored how we can better create these as well as the precise moment in the design process where it’s best to do it. A while back we stumbled upon Framer.

Understanding Framer

Framer is a tool that let’s you design any interaction. It focuses on letting you create high-fidelity prototypes. Because you can take control of every pixel, event, property, there’s really not much you can’t do and it’s up to you to decide how far you want to go.

There’s a catch: it requires a bit of programming knowledge. For designers that are reluctant to step into that territory, that might spell frustration. For those who are willing to try, it’s quite simple once you get into it. For beginners, it’s really easy to look at it this way: Framer is much more descriptive than anything else because it focuses on the front-end / design part of things as oppose to working with complex back-end data.

How we use it for transitions and animations

At this point, it’s quite difficult to use Framer to prototype entire app flows for a complex mobile app or website. Though there are some solutions to do this, it’s still far from being able to do so. But let’s say you need to describe as accurately as possible a transition between two pages that involves elements changing properties (size, position, etc.) to accommodate a new layout or new content. I’m not going to go into how to write the code. I’d rather show how we approach this process. Learning Framer basics is quite simple.

When is it good to prototype

During the wireframing stage. We want to design wireframes for developers as well. That means that the wireframes should provide the developer early on as much information as possible about the HTML structure of the website in order to better understand how the transition can be achieved.

Our wireframes are done in Sketch and are pretty straight-forward. We don’t use text inside them (no lorem, or hipsum or lipsum, only annotations that provide our clients enough information so that they understand the structure and content hierarchy). We want to transition from a list of articles (left) to an article page (right) by clicking on the yellow circle button. At this point, we have a clear understanding of the structure of the pages, so we can focus on how these elements are animated from the left view to the right view.


Moving from Sketch to Framer

Having such a great layer based connection between Sketch and Framer is purely amazing. We’re still surprised by how easy it is to import graphics into Framer, though we sometimes like to manually create the components directly in code. Below you can see how our wireframe looks in Framer when its imported. We wrapped them in a ScrollComponent just to make it more realistic, but it’s irrelevant to what we’re trying to achieve.


Coding the actual transition

From the wireframes to actually prototyping this transition is just a matter of imagination. At this point, we only focus on the motion of structural elements and we’ll fine-tune the final transition within the visual design stage afterwards. Here’s one way to accomplish this transition.

As you can see, we’re simply changing some elements’ properties to morph the list view into the article view. My suggestion is to start with a general view of what you’re trying to achieve and bare in mind 4 things:

  1. Keep it short — nobody likes to wait too much, even though these transitions allow you to load the page in the background
  2. Make it natural — adjust times, delays and easing until it feels just right
  3. Don’t overdo it — keep transitions in the same style and design; animating too many different properties can make everything seem amateurish
  4. Iterate — you won’t get things right the first time;

Prototyping early on

Describing how the interface changes structurally using wireframes makes it easy for us to make decisions at an early stage. Does the transition take too long? Does it seem natural and not forced? Is it easy to implement? When is it appropriate to show load progress? And so on. All these questions are easily answered when thought of without focusing on the design (colours, typography, graphics, styles and so on).We use the elements in the wireframes to describe the transition structurally as opposed to visually, leaving out the design part at this point. Of course there’s some dependency other visual elements (colours for example) but the goal now is not to define the animation but to explore it.

Some of the benefits

Designers use different tools to simulate animations, effects and transitions. Sometimes Photoshop for just animating stuff. sometimes others that are more popular like Pixate. While using Framer we found a few things that really make the process of designing for web much easier:

  1. Because Framers output is an HTML page powered by CSS3 transforms, properties that describe an animations’ duration, easing or others can be directly used by the front-end dev. An easing ‘cubic-bezier(1.0,0.4,0.0,0.8)’ is described exactly the same in CSS.
  2. Prototyping responsive web interfaces is simple. You can write your layer properties and condition your animations based on viewport size then just switch to a mobile view from Framer to show how the transition happens for smaller screens. For easier implementation there’s a module that is very useful.
  3. It’s fast. With very little code you can achieve amazingly detailed animations without wasting too much time.
  4. It’s designer friendly. Though there’s clearly a “designers shouldn’t code” mentality among many designers, Framer is steadily building on ways to make the learning process easier for designers. The latest release includes visual code and lets you edit layers manually.

As we explore Framer and other tools more, we plan on sharing our experiences with everyone. Because interaction design becomes more important in building digital experiences we should always find the best tools and processes that push the industry forward.


If you want to explore this further, you can try the prototype as well as the Sketch file with the wireframe.

Keep on reading our thoughts