Moving Freetrade into Figma
By: Mitchell Petrie
Tags: Figma, Product Design, Design Process, Design

What is Free…trade?

So for those of you who aren’t familiar with Freetrade, we’re a challenger stockbroker. Our mission is opening the world of investing to everyone. We do this by cutting out the fees, rethinking the tech and, most importantly, using super-simple, intuitive design for our products.

A little background

Going back just a few months we only had one designer. However, come November last year we quickly grew the team from 1 to 3 with a 4th hire coming not long after.

We knew that having a master file with no version control wasn’t going to work for us so we wanted to explore how we evolve our process.

What mattered to us?

Now, there’s nothing design teams love more than to try a load of shiny new tools but really, it came down to what mattered most to us.

Open & Transparent

At Freetrade we have a super transparent culture. We share work early and often both internally and externally with our community. We have weekly design critiques, where anyone from the team can join and give feedback. We even opened up our roadmap for you all to see. So we wanted our new process to reflect that transparency and enable us to share more seamlessly.

Remote collaboration

We have a partially distributed team — meaning there are often times where we’ll want to collaborate but aren’t able to sit beside one another.

Previously, collaborating like this means entering the hell that is sharing your screen and trying to guide others around, pointing frantically only to realise they can’t see anything you’re doing.

Future proof

Because we’re a small team migrating everyone was relatively simple. But, we would be growing the team quickly and would prefer not to need to do this again anytime soon. So we wanted to make sure that the approach we took would grow with us.

Our choice?

Figma. Whilst we believed this would be best for our team there were some things we’d be sad to see go.

Pulling live data into our designs.

Various auto-layout plugins i.e. Anima.

What do we need to do?

Now that we knew where we wanted to get too, what did we need to do to get there?

Component Library

With such a new team we knew that moving to Figma without bringing our component library with us would create a lot of inconsistency. So we decided this would be the first thing we wanted to have.

Core Flows

To make things easier for everyone we also wanted to have our core screens and flows in Figma so that people could reuse them rather than have to start from scratch each time.

This also gave us a good opportunity to iron out any issues with our component library

Bring in the rest of the team!

With both our component library and most core flows in Figma we could begin to bring in the rest of the team.

Instead of just bring everyone in all at once we asked that people just use Figma for any new projects so as not to disrupt any on-going work.

Timelines

I’d love to say we did some fancy cost/benefit analysis. A Gantt chart or two and spreadsheets as far as the eye could see but in reality, it looked a little more like this:

Switching Day

So, we switched - from this point on Figma would be the tool we used for all new projects.

Working together

From day one being able to collaborate in the same file was great. We could jump on a call, and both work side by side, leaving comments or iterations of our own.

Components

Because of the way that overrides work in Figma we were able to go from 11 variations of a row down to just 5. And, it was a similar story for the rest of our component library. This made it easier to maintain and faster to find and use our components.

Cost savings

Here’s your chance to make friends with your finance team.

For us, switching to using just Figma instead of Sketch, Wake & Zeplin was ~65% cheaper. About £279/person each year.

A not-so-obvious problem

But, not everything went smoothly. People were familiar with our existing process and because there was no official way of marking something as the leading idea it became hard for people to focus their feedback or even know if work was ready to be built.

Problem solved… right?

I decided to start adding watermelons to designs that were my current favourite. Now, obviously, this was genius.

However, it didn’t catch on…

Another approach

After we put in more than 30 seconds of thought into this problem we decided to create a document template for our projects.

This would also appear in the project browser.

First, we created a page for a project thumbnail this essentially maps to the epic in Jira and makes it easy for someone to go and learn more about the context of a project

Page per user story

We then created pages for each user story

We did this to make it easy to understand specific flows, keep feedback focussed to the problem we’re solving and make it easier to hand over chunks of work to developers rather than crushing them by dropping the whole project on them at once.

Status block

We’ve also created a component that makes it easy to set the status of a piece of work. Currently, the states we have are:

Work in progress

Open for feedback

Ready for development

However, iteration is a naturally messy and somewhat unstructured process so we wanted to have a place where we could explore quickly, make a mess and find the best solution.

For that, we added a drafts page:

Drafts

Here, we have every single iteration we go through as we work on a project. It’s messy but having it in its own page allows us to explore freely without clogging up more polished flows.