header phone
Pinky Sky
cover image
hero image
day one
day two
blue gradient
blue gradient
white gradient
black gradient
black gradient
free will

What We're Working On: Motion Prototyping for Facebook


We’re working with the Facebook team on an exciting product right now but that’s a story for another time. What we’ve learned on the Facebook project is something we want to share about answering the endless question that we as designers are all left asking more and more: “When do I use this design tool versus that one?”

The answer is often, “F*@& it, I’ll use what I know.” At least it has been for me.

But, after 3 months working with the Facebook team on motion and interaction design, we have a solid handle on what to use and when—at least when it comes to Principle and Framer.

Too Many Tools

Lately, it feels like much of the conversation in our design team’s Slack channel is about the constant barrage of new tools being released for designers. We love our friends at Sketch, Framer, InVision, Principle, Abstract, Adobe (and the list goes on), but it’s a lot to keep up with. It’s easy to feel a bit lost when trying to pick the right tools for the unique needs of a new project. 

The timeless question of which one to use and when was exactly what we ran into while working with the Facebook team recently. The project has helped us create better guidelines on when to use Framer and Principle for different situations. 

Facebook’s Ask

Anytime we work on a product that billions of people use, we get mixed emotions — excitement and trepidation. We’re excited to work on big challenges but the seriousness of the task comes with a bit of natural anxiety.

We’ve worked with the Facebook team before, but in this case, there was one essential prerequisite for all testable prototypes: they needed to be as close to the live product as possible. 

Framer was the obvious choice, but this posed a different problem as our first outputs are never final prototype worthy. We needed a process that allowed us to design experiments on top of a well known, existing product while moving quickly and being able to hand off fully interactive prototypes to engineering teams. 

Our success in this undertaking depended heavily on nailing our technical design process and using the right tool at the right time.

The Game Plan

As with most projects we do at MetaLab, we start with fast moving ideas. We iterate quickly until we get it right. This part of our work doesn’t allow us the time or headspace to get bogged down in tools and minutiae—it’s about trying new things quickly and moving on from what isn’t working. 

This led us to our plan for the project:

  1. Whiteboard ideas. We work internally to vet the best of these and nail down an overall direction.
  2. Whittle down the top whiteboard ideas into lo-fi wireframes in Sketch. We’ll validate those ideas based on technical feasibility, impact, and innovation, choosing the strongest ones.
  3. We move our strongest ideas into Principle to create simple animations and interactions. Then we’ll present those ideas to the client team and user test them ourselves to further validate what does and doesn’t work.
  4. Based on user testing and Facebook team input on concepts, we’d further whittle down the ideas to the top 3 and build those into more robust prototypes using Framer.
  5. We’d test those, refine our designs, and ship something that we all loved.

Getting Going

It turns out, our plan held up along the way. We stood at whiteboards and created early concept ideas for a few straight work days. We went through a lot of whiteboard markers and coffee, but we thought through all edge cases and angles by the end of it.

Being a remote team, we hopped on Zoom calls with Facebook and walked through our concepts and the thinking behind them. We thought we’d get a lot of questions on each idea but to both us and the Facebook team, it was clear what the best ideas were and we all agreed on 6 foundational concepts to iterate on.

It was time to dive into Sketch and turn those 6 whiteboard sketches into designs that could bring the ideas to life. 

We broke our designs into small sections and worked on each piece in short sprints. First, we took our designs from Sketch, and created motion prototypes in Principle. We’d test internally then send the best concepts to the Facebook team for review.  While we waited for feedback we’d start on the next section. Once our ideas were validated we’d create a more robust prototype in Framer.

Framer allowed us to dig deep into the details to get the smallest moments of delight into the prototypes. We find the best place to start is building the global components that will be applied across all prototypes. 

From there we added the validated Principle concepts, like swipe gestures or interactive buttons, piece by piece. This allowed us to see how each interaction fit into the greater ecosystem. If something didn’t work, we could remove that piece without having to scrap the entire prototype.

This project confirmed for us that there’s a time and place for different tools as there isn’t yet, one single tool that solves for the full workflow of digital product design. Instead, we used a cyclical workflow—building quick interactions in Principle, validating our ideas, then bringing the final designs to life in Framer.  

While the Facebook engineering team is busy bringing our designs to life (at which time we can show you exactly what we worked on), we’re glad we can share our takeaways on tools from this project.

The “When to Use Principle” Playbook

The high-level summary of Principle is that it is great for quickly validating an interaction or transition to show and sell a specific idea or concept. 

Here are our overall principles on when to use Principle:

  1. To show one simple thing; this is when you don’t need interactivity but you need (or just want) to display the magic moment of the experience to convey the emotion that’s felt by the user.
  2. When you need to move quick and scrappy with motion. The number of Principle prototypes that we throw away could fill a room at this point, but that’s a good thing.
  3. For short sprint's where you need motion to show an idea—the more tangible it feels, the easier it is to get stakeholders on board.
  4. If it is a very strong visual idea. Principle provides a low friction way to make something realistic. Getting maximum output with minimum input, especially in concept stages is key.
  5. For new patterns and innovation. If it’s new and groundbreaking, people will need more than a storyboard to understand it.
The number of Principle prototypes that we throw away could fill a room at this point, but that’s a good thing.

The “When to Use Framer” Playbook

The high-level summary of Framer is that it is great for creating interactive prototypes that need deep, specific examples of motion and delight. It’s meant to be used for more solid ideas and you run the risk of wasting a bunch of time bringing half-baked concepts to life that end up being thrown out.

Here are our overall principles on when to use Framer:

  1. Take the time to learn. Framer is a mix of design and engineering — be prepared to spend a lot of time getting things right. While the outputs can be incredible, the inputs to get you there are time-consuming.
  2. To show logic of an event. Once you have specific details of how pieces work together, you can create if/then statements which show various user journeys within the same prototype. Use this to your advantage.
  3. For dynamic testing — the person can choose their own journey rather than being shown the options of motion 1 at a time. This gives you more genuine feedback when testing concepts.

How we managed our Framer prototypes

As each concept shared similar patterns, and evolved and changed over the course of the engagement, we tried to keep things simple by having a single Framer file. This allowed us to share global components across all concepts, and update once without the headache of copy and pasting code across multiple prototypes. Conditionals allowed us to pull this off.

In the opening lines of our Framer prototype, we have a list of conditionals which correspond to the separate prototypes within the document. If we added a new version, we’d update the list. As you’re learning more about the code side of Framer, using things like this will become very useful to you.

An example of our conditionals for this project were: 


     FULLSCREEN: 'fullscreen',
     INLINE: 'inline'

Below this, we defined which conditional we wanted to use.  


Later in our code where we defined our functionality, we wrapped our code in an IF statement.  

if flow == FLOWS.FULLSCREEN      
else if flow == FLOWS.INLINE      

But First, Learn

If there is one thing to leave you with, it is to tell you to learn how to use both Framer and Principle. Being multi-disciplinary within product design allows you to not only show the ideas you have in your mind in the real world but also bring them to life with real interactions and delightful moments that users want more and more in their apps. 

While the learning curve can be steep (especially for Framer) I believe it is well worth it. Often, the best place to start is downloading others prototypes to see how they built it, then try to replicate it for similar interactions in products that you’re designing. We all have to start somewhere, and for me, this was a great place to get going. So jump in and start learning, you won’t regret it.

If you have any questions for me, just say hey on Twitter. Or ping my project confidant, Geordie, who went through all of this with me on Twitter.