Moneybox Design: Transitioning to Figma
Learn how Team Design moved from five tools to one: Figma.
Why did we choose to move from Sketch to Figma?
We’ve used Sketch as our main design tool at Moneybox for many years. In the early days, Sketch was the logical choice for all designers looking to elevate their screen designs from early Photoshop or Illustrator mocks. Figma, now dominating the designer tooling landscape, is a modern web-based design tool aimed at democratising the design process and encouraging collaboration amongst designers, project managers, developers and other stakeholders.
At Moneybox, we all share four core values in our daily work, known as our ALOT values. The ‘T’ stands for Team, and with Figma we want to bring more of the Team into our design process. By opening things up during our working process, we can encourage early feedback, which can dramatically change the direction of a project we’re working on.
Prior to the transition, we used a five-tool process:
- Miro for early diagramming and research
- Sketch for wireframing and designing
- Overflow for sharing customer journeys (and showcasing to stakeholders)
- Marvel (sometimes) for mocking up a quick prototype
- Zeplin for handing over our design files
One of our main goals of the transition to Figma was to reduce our number of tools to as few as possible. While this helps streamline the number of suppliers we work with, it’s more so we can focus on design. That way, we could spend less time moving our ideas from tool to tool.
With Figma, powerful prototyping is already built in, with FigJam, we can fully own our research, diagramming and customer journeys, and with the powerful inspect panel, we no longer need to use Zeplin to hand over designs. That takes us from five tools to a single one — Figma.
The process
Considerations
The biggest upfront consideration for multiple stakeholders, including many of the design team, was deciding what to do with our current Sketch file library. We have five “mission” teams, such as Saving or Investing, each with their own dedicated projects spanning up to nine types and housing multiple files inside. Transferring all of these files is a necessary evil! We regularly come back to old projects to work on them again, or lift ideas from previous implementations.
As a result, we agreed to port our entire library from Sketch and treat all files as archives, with the option to reactivate them if a project came along that required those screens.
We also needed a plan for anything “work in progress”. We agreed to finish any work in progress projects within the same tool they were started in, with the goal to kick off any new projects directly in Figma once we hit our deadline to transition.
Finally, we had to think about stakeholder management. How would we communicate the transition to Figma and get other teammates involved? For our design team, this was a relatively easy process. For the most part, our designers already work with Figma in other ways (or have previously), and through regularly sharing snippets of how we were optimising our system, we generated excitement in the team.
We had to slowly introduce other stakeholders to the new way of doing this. As part of this, we made sure to keep Overflow and Zeplin around to start with. This would mean we could hand over in the same way as before, while slowly easing away from those tools.
The process
One of the advantages of this process is that it wasn’t the first rodeo for many of us! A lot of our team have experience with transitioning between tools, so managing that process was relatively straightforward once we had the rationale in place. One of our designers, Karl, is proficient in JavaScript and writes plugins for Figma already, so we leveraged this to make our transition easier. Read more about how we achieved this here.
Our first challenge was to move over our design system. Once we’d imported that file, it worked almost immediately, except for a few specific issues around tints, masks, and background layers. We wrote a script to fix these issues instantly without needing to manually update each item. We then optimised the design system itself, converting multiple component types into a single variant of a master component, with lots of smart switching. This made it easier for designers to get the component they need without detaching from the master library.
Next, we wanted to define the end date for the project. We set ourselves a target of using one “orbit” cycle (our 8-week sprint process) to test Figma in core projects and get our design system up and running. We then decided to utilise the next orbit to get the design team up to speed with the new system, one at a time.
Finally, we had to agree when to turn Sketch and the other tools “off” and make the full switch. In reality, it’s a bit of a drip feed process, but we knew that we’d want to stick to our end date. As the core team leading the transition, our three design system owners dog fed our new setup by using Figma for new projects before launching to the wider team. This allowed us to spot any bugs and opportunities for refinement. We got a lot of value out of this stress test in terms of updates to how we built out our design system. For example, we identified improvements to component flexibility (through Figma Variants), and rethought our approach to colour, by switching our naming convention to use design tokens that better align with development.
To avoid teething issues, we chose to upskill our designers as much as possible, utilising lunch and learns as well as individual sessions to build out interesting or complex components. Getting to grips with our new way of doing things is still an ongoing process, but with our new design system, and open design clinics for anyone to join, we’re making good progress.
We’ve found it particularly successful to trial playground files that teach a Figma concept through an instructional process, and plan to use these more in future. We tested our first as an explainer of Auto Layout and encouraged our designers to complete it to get a better grasp of how it works. The end result is that they have a flexible component that they can then use!
Conclusion
Overall, the process of transitioning from Sketch to Figma has been fairly painless. Like any change, there’s always going to be teething problems and it’s not a perfect transition, but so far we’ve been able to run several projects within Figma entirely, without any stakeholder disruption.
Moving to a new tool also gave us a chance to rethink our design system and make the enhancements and improvements that would most benefit our team. Ultimately, we’ve not only been able to switch painlessly to a new tool, we’ve also been able to improve our system for the long term and align more closely with our development counterparts.
Catch up on the replay of our latest Design Meetup, where Karl walks through the Sketch to Figma transition in more detail.
