This past week I’ve been playing around with a Javascript-based prototyping tool called Framer. It’s really easy to get it running if you read through the documentation. It’s also pretty easy if you’re already pretty familiar with Javascript.
Interaction of a Framer prototype I built. Check it out live on CodePen.
Framer.js was built by Koen Bok, it is a great tool for any designer looking to flesh out an interaction of an interface. Framer, also integrates with Photoshop (there is a Sketch plugin), so it’s easy to export assets and begin prototyping with them as objects in Javascript. I quickly fell in love with the tool and the community supporting it.
Enough about the characteristics of Framer though, you can read about it on the website. Let’s talk about the big picture I’m trying to get at.
“The current state of tools is decent, but how they fit together is less than ideal.”
—Pasquale D’Silva on Medium.
Tools come and go, it’s easy to get caught up trying to learn the latest framework. It’s also easy to get caught using the wrong tool for a specific workflow.
Creating a good workflow for a project is a difficult task in the day to day as a product designer. There are multiple software programs that can help a designer do it’s job, all of them require a different level of skill and a different approach. So it’s an immensely important skill to be able to differentiate when and why you should jump into a design tool, especially one like Framer.js.
I have two main points why Framer.js should matter to designers:
Allow me to elaborate on these two points.
This past week, I gave a small presentation on Framer.js at our weekly code review at DevMynd (this post actually stemmed from the talk). During the presentation, I spoke a little bit on what my process was like building MassTransit with Erin Hochstatter (an iOS developer). I designed the iOS app all in Photoshop and handed over assets as well as specific numbers around type size, container widths and heights, iconography, etc.
Although I was pleased with the visuals, static images and numbers weren’t enough. I know, huge shocker. There were multiple occasions where I had to sit with Erin to explain an interaction I had imagined or instances where she had to pull me and ask. Erin was relying solely on my word to understand the desired interaction, no visual representation. This is where Framer.js would have been an excellent tool for my workflow.
As a product designer, it is my job to create the interface and the imagined experience a user will go through, but it is also my job to communicate and prototype the interaction the user will have with the product.
My second point is something I strongly believe in and at times can cause controversy amongst designers. A good friend of mine, Mig, sums up what I strongly believe:
“Understanding our tools means designers should code.” (Source)
Period. As product designers, I believe we have the responsibility to fully understand how software works to be able to design for it. Building the front end is an easy way to put pieces together for the software to fully work.
When you’re prototyping in Framer you’re not learning or writing code that will one day end up in a dark alley somewhere in your trash bin. Framer is a space where you can continually learn new ways to animate and manipulate objects in Javascript, that’s huge!
To wrap up, I recommend you join the Facebook group and follow some folks that are building awesome stuff for the Framer.js community, such as Koen Bok, Cemre Güngör and Ale Muñoz and Josh Puckett.
Also, be sure to check out my Kippt list on curated Framer.js links.