Working with FramerJS in the UX Design Process

Overview

Framer is a prototyping tool that allows designers to test and validate their gestures and interactions. I wanted to walk through the standard design process and go in depth into how it fits with that process. Also, since I had previous iOS development experience, I wanted to explore how it’s different and what items could translate over when an app enters the development process.

We’ll examine an example problem with note taking apps, go briefly over ideation, in-depth on how to think about a prototype, and quickly go over what the next step would be. Our final prototype will function like this.

Problem and Scenario

1. Define the problem.

To begin, define the problem. For this example, I wanted explore note taking applications. In the Getting Things Done (GTD) methodology, the first step is to throw any notes, ideas, or actions into the inbox. It’s a holding spot to be sorted through once a day or week.

Currently, the task of reviewing an inbox translates to immediately filing/tagging/categorizing items. This leads to added friction before ever adding items into an inbox. Rather than placing any random thought in the inbox, I’ve found myself with analysis paralysis, not adding items because I don’t have a preconceived idea of where they’re going to be tagged. This defeats the purpose of the inbox.

With that in mind, I wanted to explore an explicit intermediate step in the GTD workflow. A user could decide to keep or remove items in their inbox, but not file inbox items at that point. So how might this look? That’s where we write a scenario!

Example of how the iOS Notes app shows individual notes.

2. Write the Ideal Scenario

The next step a person could take is to write out a scenario. The scenario should capture your idea and how it integrates itself in a person’s flow. It shouldn’t be specific; for example write “she organized her items with it” rather than “she pressed and held the cell to move it up”. I like to write a scenario because it helps provide context to the situation. The scenario for our example reads:

Joe Miller (shoutout to The Expanse) enjoys using his device as part of his job. In particular, he uses his notes app throughout the day, adding his thoughts, notes, and ideas into his inbox. Joe has no hesitation putting random thoughts in his inbox. On his commute from work to home, Joe doesn’t want to file items, but does have the time to review and quickly sort the item worth keeping to file later or toss items.

Joe Miller on his device examining notes. From SyFy’s The Expanse Episode 3

Ideation

3. Generate Ideas

The next step would be to generate as many possible solutions as possible. At this point, there is no dumb idea. One of my favorite techniques is a similar to the Crazy Eights specified by Google Venture’s Jake Knapp. Set a timer for five minutes, sketch as many ideas as you can in that time period. Take a one minute break to refresh. Repeat one or two more times. Then review the ideas. Again, no idea is dumb.

If you ever get sketchers block in that five minute period, SCAMPER. I got this from White Space is Not Your Enemy and is originally from Bob Eberle. The idea is that once to take a look at the ideas you have generated and:

• Substitute
• Combine
• Adapt
• Mangify or modify
• Put it to other uses
• Eliminate parts
• Rearrange/Reverse

Doing this can transform one or two ideas into six or more.

The next step would be to narrow down the ideas into those worth validating. I won’t go into detail on this, but will point towards Google Venture’s Design Sprints. They provide a great resource for going into the decision phase.

For our example, my selected idea combined the standard page swipe and Tweetbot’s swipe to dismiss interaction. With this, I began prototyping.

Apple News’ Page Swipe

Tweetbot’s Swipe to Dismiss

Prototype

4. Decide What and How to Prototype

One of the primary reasons to prototype is to validate the whether or not a design functions. You could pick from many different tools to generate different levels of prototypes.

It’s important to know what you want to validate so you can select the right tool to create the right prototype. For example, testing the effectiveness of a e-commerce funnel on a website would best be served with a click through prototype. In this case, you’re testing the flow rather than the individual interactions; InVision would be a viable option. In our example, we’re testing at the gesture and interaction level. Framer is a great tool to rapidly create and test designs at this level.

5. Break Down the Interaction

Because we’re combining interactions understanding the specific interactions occurring will help guide building the prototype. In our case we’ll be recreating:

1. Swipe left/right to change the note in view
2. Swipe Up/Down that leads to the note rotating
3. Rotational velocity is based on the swipe speed
4. Opacity changes as the note moves toward the edges

We’ve got a great starting point to build a prototype in framer. As you prototype, you may find things are off from what you want to create. That’s ok. Stop, breakdown exactly what you want to prototype, and get back on it.

6. Build the Parts

At this point, a designer could start designing in Sketch (or your tool of choice) and import the pages into Framer. For this example, I started with basic shapes such as rectangles and ovals to represent where content would be. By using rectangles and ovals, I find that it stops from getting lost in content. However, if a person were going to heavily add animations or interactions with the specific content, then it’d definitely be worth examining importing from Sketch.

For our example, I first added the notes into a page view. There’s already a really great example on the Framer page to create this.

The next step was to simulate the swipe up and down.

Once the individual note could be swiped up and down, I added the rotation to the note layer.

The last step was to change the opacity as it disappeared.

Here’s the final prototype with all the parts combined.

View Prototype

7. Add Content

Cool, we have an interaction. Depending on what you’re testing, you could call this a stop point. For example, a designer might just want to examine how an interaction feels. This would be a perfect stop point and prototype to examine that. For our example, however, without content we don’t have the context in which we’d be using the design. Let’s add some!

Framer is nice because it uses code. While that creates a learning curve, it does allow for things like using JSON to add content. With that in mind, I used Google Sheets to create a spreadsheet with content that could be imported into the Framer prototype.

Here’s our prototype with the content added from the Google Sheets:

View Prototype

Validate

8. Validate

“Sweet prototype! What now?” The next step a designer could take is to validate the design. Again we can go back to the Google Ventures design sprint on ways to validate the design. This is out of the scope of this article, but the most important step if we were to actually be creating a design that would go to production.

In Retrospective

Framer is a great prototyping tool to test designs at the interaction and gesture level. As part of the design process, it can help guide what paths in the design to go down and what paths are dead ends.

It’s different from coding in Swift/Objective-C in that it’s made to create something for the UI, quickly. In iOS, to create this as a reusable framework would end up using a UICollectionViewController and a custom rollout of UICollectionViewFlowLayout.

For me, Framer specifically allows me to think about the interaction, the look, and the feel. If I create spaghetti code, that’s OK! The goal is to validate the design and not to go to production. Framer is the perfect tool for this. That said, I am planning on recreating this in Swift using a UIScrollView and UIViews to compare how prototyping in Swift without thinking about extensibility compares. I can already say, Framer’s use of “states” is a fantastic approach to animation.

I like that Framer helps change design from explaining to showing and provides a tangible product that can be validated in context rather than staring at static mockups. Framer also allows designers to have a conversation with developers with specific information on animation timing, location, and opacity. It will help the developer get an idea of where to start. All this can only help create better end products and that’s the ultimate goal.

I hope you enjoyed this journey! I’ve shared the final prototype here for to reuse as needed. If you have feedback or just want to reach out, I’m available on twitter @dandancortez.

Originally published on my portfolio at www.dhcortez.com.