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

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

Starting with a blank slate is every designer’s dream. Being given free reign to decide on the appropriate tooling to build a brand new product is a challenge, but provides an opportunity to experiment and find what works for the project at hand.

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

With our growth as a business skyrocketing, we were in a position to double both the product and engineering teams. I’d been keeping tabs on the design tool landscape since making the decision to go all in on a Sketch plus Zeplin plus InVision stack, and given we were bringing a few more designers on board, I spotted an opportunity for us to run a test to see if Figma could fit into our workflow. This was a great opportunity to test the collaboration features with the plan to operate on a more paired-designer workflow going forward.

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

One of my aims as lead designer is to provide the business with the most cost-efficient approach to equiping out the design team. With the team expanding, I predicted that our costs and tool management could get way out of control very quickly.

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

How did we do it?

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.

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.

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.

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.

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

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.

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).

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.

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.

The libraries

In this final section, I’ll be running you through how we structured our shared libraries and components. We had originally used a different setup before the migration, so it was a great opportunity to experiment with a simpler solution now that we were putting a lens to everything.

Our libraries

Our design system is called Dolly. Why call it Dolly? Given we’re in the travel business, and you can obtain everything you want on a flight from the ‘Dolly trolley’, I felt the name would be perfect for a holistic system.

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

Component naming

We realised that the use of forward slashes in component names, although offering a useful filtering tool, was not the best approach for readability and exporting. Trying to export a single button to your computer and it being embedded in multiple folders is a real pain.

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.

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

Our assets are managed within our Dolly design system Figma project. We split assets into the following files:

• 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

We base our icons off the feathericons.com library, but modify them ever so slightly if required. For example, filling them with our brand gradients, or creating solid shapes rather than outlines to match our style.

How are the icons constructed?

There’s a guide for that.

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

Tokens form the basis of all our designs. They are the bible of our brand colour palette and typography hierarchy. We’ve kept this pretty simple, as we haven’t had a need to include things like spacers just yet, but who knows.

• Colours
• Stores our core 9 brand colours, their light and dark tints and our black to white colour scale

• 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

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

• When creating your components, make sure you rename the text label. If you don’t, the text you override in your instance will be reset when the component is changed in the library. Save yourself a headache
• 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!

Congratulations for making it through, I think we all need a drink after that. I hope I’ve managed to share some deep insight into how we shifted over to Figma and the structure we employ to ensure our files are easy to find, structured and set up with collaboration in mind.

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.