Migrating to Figma: the business case, the process, and the libraries

Luis Ouriach
Mar 30, 2020 · 13 min read
Boarding the Figma express. Part 1 — The business case.

Upgrade Pack is a market-first flight and hotel upgrade app. Available to mass affluent banking customers, or as a unique employee benefit, Upgrade Pack provides users the opportunity to upgrade their flights or hotels — with a discount — via a simple to use iOS and Android app.

Over the course of Q4 2019, we decided to migrate our design tool suite over to Figma for myriad reasons. I’ve documented the process and decided to write up a transparent trio of articles for you all.

I’ve broken down our migration process into three stages. Put your seatbelt on, this is going to be a fun ride.

Figma, a backstory

Joining Upgrade Pack as the first visual designer in September 2018 landed me in this position and I was excited to test the waters of what was possible on the design tool landscape. During my interview process I decided to give InVision Studio a run for its money, and upon starting the position I decided to try and stretch it in-house. Unfortunately, at this point our engineers just didn’t find the hand off process as slick as it could be, so that was struck off. I was also testing a Sketch plus Zeplin workflow at the same time, and it just felt a lot more complete. Bye, bye InVision Studio. Our UX designer and VP of Product still found immense value in the InVision prototyping and Freehand products, so those were kept in our suite.

Having had little exposure to Figma in the past, and the library feature not being quite as sophisticated as Sketch’s at this point in time, I made a snap decision to run with my old trusty Sketch.

We needed to start building yesterday, and I knew that I could deliver with Sketch.

Fast forward 6 months

I decided to bite the bullet and introduced Figma to our UI and UX designers, and we operated with a free license for them both for a few months to get a proper feel for the tool; a migration was not going to happen with just a day or two to test the platform.

We caught up frequently about their happiness within the tool and we tried to treat it as if we were using it full time — components, file structure etc. The conclusion? Figma was faster, more transparent, and easier to plan, find and — thanks to project structure — organise files. I was reluctant because of how much work had gone into structuring our system pre-Figma, but decided to investigate a business case for a migration.

The business case

Sketch 4 person annual cost: $1668. Figma 4 person annual cost: $720.

I jumped into a spreadsheet to do some quick maths on our landscape going forward and quickly realised that our costs could spiral with even marginal team growth It was time to act — we are a startup after all.

Having run the numbers and been given a firm thumbs up from our UI and UX designer that Figma was indeed as powerful as we had hoped for, I pitched the idea and we started to consider a formal migration process.

I needed to anticipate the potential destruction of shifting our entire app, design system / UI kit, and handover process over to something new. And this meant carrying out a proper analysis of the migration and what was required.

With the numbers crunched, and our team on board, we were in a great position to put pedal to the metal and make this thing happen.

The structure

With blood sweat and tears. No, I jest. The process was long, but taking an incremental approach allowed us to be systematic about the migration and also run an analytical comb over our existing approach to design management.

I started with Trello, listing out everything I could think of that needed migrating over. This wasn’t a granular list, because we quickly realised that with so many interlinked aspects within our design ecosystem it just wasn’t possible to deliver a lot of the project on a micro level.

Our Trello ticket checklist.

The Trello ticket included some broad stroke tasks (individual flows) and some smaller, fundamental libraries (typography, colour etc). Our priority order was to first tackle the library items, and then take each user flow one by one across and create individual components from each screen on an individual basis.

But wait! With us having an opportunity to gain some perspective on existing document and library structure, it would’ve been a big opportunity missed if we didn’t complete a component and screen audit.

This was mainly done with printouts, marker pens and a healthy, robust discussion about what was and wasn’t working.

We took a look over our:

  • Typography layer styles
  • Color layer styles
  • Screen naming conventions
  • Component naming conventions
  • Assets / icons for the core app, airlines, hotels, and flags

Having previously created an atomic naming system in our Sketch libraries, we were in a position to debate whether this was indeed the best approach going forward.

Project structure

Buckle up.

This was the biggest struggle for us when migrating, because we were used to a Finder structure that split everything up by folders by user flow.

Our Mac Finder folder structure.

With Figma preferring a Project approach to how you structure files, we settled on the following system after much deliberation.

  1. Create a Project for each department of the business and major project that require designs
  2. Split our product design work into
  3. A Core file for approved and built user flows that are standard across the app experience (user profile, settings, payment management)
  4. A specific file for each specific platform vertical (flights, hotels)
  5. A Features file, for each new User Story or task that needs to be developed

Once our Feature files have been prioritised, added to a sprint and shipped, we merge the work into the corresponding main file and archive the previous file.

This will be easier if I show you.

The Figma file process.

File naming

You may have noticed a little emoji in the above image. Whilst working with files in the initial stages of our migration, we were getting confused about which file belonged to which project when flipping between Figma’s tabs.

We decided that we needed a symbol for each project so that when skimming through files we can quickly associate them. The easiest way for us to implement this was by using emojis, given that they take little space and are cross-platform.

Firstly, we tried to use colours to represent each project, but that would require a deeper cognitive association between projects and files which we just didn’t have. Why should the mobile app be green, for example.

We then tried shapes — circles, triangles, squares etc. This also led us to think that it was just too far a stretch to associate a shape with a project; is marketing a triangle or a square?

After scanning through the Mac emoji list, we discovered our answer. The emoji / glyph style we used is the CIRCLED LATIN CAPITAL LETTER, and we have matched it to the first letter of each project.

See below for the letter A example.

Mac’s Fontbook.

And here’s the full project listing alongside their respective project.

Our individual file names.

People have asked why the Upgradepack.com project is marked with a ⓪. I opted to use the 0 because our website is the digital storefront and, well, the foundation of digital is 0s and 1s.

File structure

Things are about to get aligned.

I like to keep our files prim and proper, which means going to the nth degree when it comes down to the naming of pages, layers and components. Some might say you don’t need to go that far, but my goal is always to allow a smooth transition between designers, product managers and engineers, and having clean files is a surefire way to limit confusion when looking over someone else’s work.

File cover images

Every file has a page for its ‘cover’ — what we see when viewing a list of all our files, seen below.

On the cover, each file has:

  • Screenshot of the screen / element in question
  • Name of the file, one word (two words if a subsection)

Pages

Every file contains the following:

  • Cover — The image that we see when in the main file list
  • _research — Competitor analyses, design ideas etc
  • Scratchpad — Where our initial and unused design ideas live
  • User flow — An optional page should a prototype or extended user flow be required
  • Ready for development — A page for the signed off designs to live. Once designs are here, they are essentially at a point where editing is no longer required for this iteration. If we want to make changes, they need to be mandated by product lead, with tech made aware

Now onto how we structure our Frames within files.

Figma file structure.

Here are the rules:

  • Each Frame has a label above it, with a margin of 120px
  • Each Frame is spaced 240px horizontally from one another
  • Each Frame is spaced 400px vertically from one another

And the naming?

  • Frames are named to match the coded template name in the app
  • Frames are grouped by flow
  • We use a four digit naming convention to allow for up to 10 variations on a single flow, and 100 individual variations on each Frame (ideally not).
File naming conventions.

You’ll notice in the above image that we have a mixture of full numbers in the 00’s and some with a 50 (Search — 1150 — Hotel brand — selected). We use 50 variations for when a state change occurs. This may be when an input field is focussed for example.

So what about the numbers in between 00 and 50? Well, we use 10s for when there are micro differences in screens. For example, we may show content variations across a single screen. An example of this may be for different address standards across the world, demonstrated below.

Sequence numbering in Figma,.

Ooft, that was a long one. I hope you’ve seen how deep a dive we took into our process and structure with the Figma migration.

It took its time, but we’re really happy with how robust our system is; it has set us up for a really efficient and scalable product process going forward.

Pert 3 — The libraries

The libraries

Our libraries

We split the files in this project up by assets / icons and tokens.

Component naming

Atomic and simple library naming conventions.

Figma’s Frame grouping is brilliant for grouping similar components and removing the need for long names to describe something. We’re shooting for bonus points by using Autolayout on our Frames.

This means that (with a button, for example) we transitioned from this:

a/Button/M/Gold/Base
a = atom
Button = component
M = Medium size
Gold = Colour
Base = State

To this:

Figma file: Ⓜ︎_Components
Figma Page: Buttons
Frame: Medium
Component name: gold base

And here it is visually.

Buttons in Figma.

Breaking things down this way makes file names look so much more attractive, and we can remove the atomic naming conventions now that the whole team are on board with the process conceptually.

This isn’t just used on things like buttons either. We’ve employed a more descriptive approach to all of our components, including the booking itinerary cards shown below.

You can see that the component naming is in plain English. Removing the atomic structure from our names has made discovery a lot easier.

Assets

  • Icons — For assets that are used across all of our products. This is split down into pages:
  • Core — Functional icons that are not tied to a campaign, partner or platform
  • Partners — Our airline and hotel partners
  • Marketing — Social media icons and featured PR logos
  • Utilities — Cursors and OS icons
  • Scratchpad — Ideas or abandoned icons
  • Flags — Selected country flags, cross referenced to a Github library that our developers user

Making the icons

How are the icons constructed?

Icon guidelines.

We work to an icon size of 24x24px, with an internal 4px grid system. This builds a 6x6 grid within each Frame, giving us finite control over each part of the icon.

I created a starter Frame for us to duplicate when making new icons which speeds up the workflow a little bit.

Tokens

  • Colours
  • Stores our core 9 brand colours, their light and dark tints and our black to white colour scale
Our colour library.
  • Typography
  • Stores our mobile and web typography systems
  • We run from XS up to XL, using the golden ratio (1:1.618) to scale each step
  • We use 1.5 for line height across our body text, and 1.1 for our headings
Our typography library.

I’m sure those of you that code are looking at those hard coded pixel values and getting a headache, but as design tools are limited by pixel values, we have been explicit in this way. I also provided our developers with a CSS file that has the calculated font sizes in REM format.

Some tips

  • Don’t try to predict the future. It’s easier to design for the now and change later, rather than creating lots of work that you probably won’t ever need or use going forward. This is particularly the case for things like buttons. You don’t need ten colour variants just now, so don’t waste time building them
  • Try to keep all relevant work within the same file. Research, user flows, and the final work for development is going to be easier to track as individual pages rather than separate files.
  • You don’t always have to be right. A flexible mindset will allow your design system / UI kit to grow the way it needs to. If something needs changing, plan and adjust accordingly. After all, we’re working in an agile space

We’re done!

If you have any questions about how we work as a design team at Upgrade Pack, drop me a message on Twitter @disco_lu.

I’d like to thank Merve Guneyhan for putting up with my pernickety requests during this migration, she did some incredible work on it all.

8px Magazine

Life, by designers.

Sign up for 8px Magazine

By 8px Magazine

Latest from our publication. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

8px Magazine

Life, by designers.

Luis Ouriach

Written by

Design and community @FigmaDesign, newsletter writer, co-host @thenoisepod, creator of @8pxmag. Sarcastic.

8px Magazine

Life, by designers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store