Editor’s note: We’ve made some big changes to Framer, and this article refers to a deprecated tool. Learn more about what Framer is today →
Almost a year ago, Deliveroo Design Lead Jonny Burch gave us a behind the scenes look at how the team was beginning to use Framer in their workflow. In this two part series, Deliveroo product designers Tim Davey and Brendan Fagan share their respective beginner and veteran perspectives on how Framer continues to influence Deliveroo’s design, prototyping and user testing workflow.
For the past few months, we’ve been thinking a lot about different ways we can help people discover food. We wanted to explore personalized recommendations, better filtering and improved search. Over time, we started to hone down a few directions we were happy to bring to user testing.
At Deliveroo, we’ve learnt it’s important to work with live data, real locations, real restaurants. Adding believable content to mockups in Sketch has always been a very manual process and really time consuming.
More importantly, the flat prototypes we gave to users often felt like they were on rails. We found that when the restaurants and locations we used were clearly hypothetical, the feedback we receive could feel hypothetical too.
When dealing with food, our aim is to tap into a test participant’s core associations, how they feel when they’re hungry, tired, impatient, curious — We weren’t always getting that with flat prototypes.
If a test participant suspends their belief in a prototype, you no longer receive that raw, honest feedback that carries with it real emotion. That’s the stuff we want to act on to improve our products.
Brendan Fagan and I saw the opportunity to create a single high-fidelity prototype using Framer which would encompass all of these concepts using live data we could control.
The reluctant beginner
I was excited to get started but there was a hurdle. Until recently, I avoided Framer. I had picked it up and put it down countless times, never having fully gotten to grips with it. Tools like Marvel, Principle and Flinto made up the backbone of my prototyping knowhow. For the most part they worked but I quickly hit their limitations.
Despite my reluctance, Framer seemed to have evolved a bit since the last time I’d last used it. There was a new Design tab, the Code side didn’t seem any less daunting and, lucky for me, Brendan Fagan had recently joined the team and brought with him a wealth of experience I could lean on.
Getting over it
I started with video tutorials. There’s plenty around and they were good at teaching me how to do a single thing, but I had a hard time re-using the same logic elsewhere. I was often left with loads of questions around why the syntax was the way it was. Video tutorials didn’t give that supporting context. I wanted to know why that thing did that thing!
The Framer documentation is comprehensive and always on hand but I found it tricky knowing which was the right method to use and when. I was quickly learning that there were many ways to achieve something in Framer and I couldn’t figure why one was better than the other.
A lot of the time my prototypes would fail because of a single character was off or because the indentation was wrong. This is where I would usually churn and go back to my timeline driven prototyping tool.
I have made, fire!
Somehow, with a lot of trial and error, I felt like I was getting somewhere! I started to understand the different ways you can approach an interaction and most importantly, what breaks when you remove something.
I started really small and got comfortable writing code that wasn’t perfect but did the job.
Even though I was still learning, small interactions like this were already proving useful when working with engineers.
Framer allowed me to communicate triggers, delays and durations with ease and accuracy. Our new discovery experience was starting to see the benefit.
I got confident enough to create page layouts, nesting some components, using loops and arrays to display real data from our web site using JSON. I could later use this to collaborate with Brendan on something much bigger.
When we tested this with users, we found we had way more control over the data in the prototypes and how they behaved. And they appeared a lot more real and as a result, the quality of feedback we were getting was a lot better.
The biggest help for me, by far, was finding a Framer veteran and pairing with them. Your nearest whizz has typically made the same mistakes you have and can help you avoid them, as well as guiding you on how to approach something conceptually. I also found that engineers are more than happy to help you out. Even if they hate the idea of CoffeeScript, they likely understand the principle and can help you debug something.
At Deliveroo, we set up an internal Slack channel where people can post problems and get help. There’s also the wider community Framer Slack channel and Facebook group which are both great.
Up and over
By the end I had a handful of solid interactions and layouts which I could use to help create the larger prototype Brendan Fagan and I would bring to users.
Here’s what I took away from my time getting to grips with with Framer.
Find ways to add value
If you’re tight on free time, there are ways to weave learning Framer into any project. If you can apply what you’re learning to something you can hand over and get built, then it’s worth the time and effort.
This stuff isn’t easy, ask for help
If you can use Framer, then try and help others learn, run workshops with your team, set up Slack channels and help designers get over the hump. If you’re learning like me, nag people, find the help and make the most of all the resources out there.
Pretty soon, I was using Framer to iterate on the Deliveroo discovery screen and various micro interactions. Continue on to Part 2 to find out what Brendan Fagan was working on and how we eventually collaborated to create a single high-fidelity prototype. If you like what you read, come work with me at Deliveroo— we’re hiring product designers, content strategists, and researchers!
