What moving to Figma meant to me
Notes on how adopting a new tool on a larger team ignited some best practices on process.
A couple of years ago, amidst the boom of new design and prototyping software, I was pretty reluctant to fight on the Figma/Sketch cold war. I was working on a relatively small design team and, after years helping to design products, well sold on the idea that software is not the important bit, instead the people, the processes and the thinking behind what we do is what delivers the good results (which we know end of the day is true… but everything else helps).
So no, I didn’t want to change Sketch for anything, we had our library and our processes and not only our issues were not going to to be solved by any new piece of software (if anything it would create a whole new project for us to migrate all our designs to a new system), but also I was personally not keen on what Figma was selling. I was pretty sceptical about it.
But why was I so sceptical:
- I thought of it as a web service. It didn’t look like the rest of the apps that live in my computer, it had more of a website feel to it, and I perceived it as less stable and reliable because of that. I saw Figma as a more casual piece of software.
- I frowned upon online-only. Most of us are lucky enough to enjoy a permanent decent stable connection (if we ignore for a moment our COVID times) but despite that the idea of working on something complex on the cloud was unfamiliar to me, and me and my team feared that would mean not having access to anything when offline.
- Sketch had already got me. I was committed to it. You make a tool a core part of your process and your craft, you spend lots of time learning its perks and you’ve got a nice example of how the effort heuristic makes you overvalue something.
- In-tool collaboration in a small team felt like a nice to have. I didn’t miss the interactivity between us as designers. And if at some point we needed we could always use Abstract to keep better control of our working files. I had never used it but I knew it was there in case we needed it if our team grew.
My situation changed last year when I got a new role and became part of a much bigger, scaled up design team. I joined in when they were migrating to Figma from Sketch and Abstract. They were doing so for multiple reasons, some of them being the performance problems of Abstract but also seeking a more interconnected system (and probably the design community’s pressure was another trigger there).
So we started to explore and discover how to work with it. Learning it took a matter of hours, pretty easy coming from Sketch and having used other software where the idea of resizable ‘frames’ rather than just groups or artboards was as well present (the prototyping tool Principle, for example). But learning the basics wasn’t where the biggest value laid, there was way more to it.
I don’t want to list Figma’s features and talk about how great it is, but instead I would like to mention what it meant to me and the sort of opportunities and challenges it presented me and my peers during the few months I’ve been wielding with this tool:
A democratisation of the design tool
From my honest experience, I’ve rarely seen anyone in any other role (other than designers) open my Sketch files, and when they did I wish they have never done it. These files were mine and only mine, they were a representation of my process and how I wanted to organise things. It was my organised chaos.
This changed with Figma. Now everybody had access to our designs and was able to comment and review them, both people with design backgrounds as well as other roles in the company. This made all of us think about how we wanted our work to be seen by others so they could make sense out of it.
Where and how to direct people to and what to ‘hide’ from the rest of the employees becomes a skill by itself. The same goes with contextualising explorations and outputs. Running testing sessions with other designers on that structure may become a very insightful thing to try, too.
A complex interlinked ecosystem
Everything is connected in Figma, specially since the links feature was released. Rather than files in a folder (within a folder and enclosed in yet another folder), you get a structure that you can interlink and organise at will. This means that if you start a project and it has dependencies in another one, you can link to it. Or that you can refer to specific explorations done on a specific point on one of your artboards and give a quick access to them (yes, you can link to any element of the page). It’s a complex order that you have to own with your team to get the most of it for you, your peers and your organisation.
That means being able to link to other sources or dependencies within the tool, but maybe Figma doesn’t need to be the go-to place to get around the project. Companies rely on other software such as Notion, Confluene and Jira for that. But it can be at least a source of truth for design matters.
Your own (product) structure
More people getting through the designs of a product within a complex interlinked environment requires guidance. A comprehensive structure that allows employees to find what they’re looking for (without losing themselves on the wrong files or wasting time looking at blue sky explorations) and new joiners to begin to understand the company’s product.
As prompted by other designers within my company, avoiding the Conway’s law was an important bit to bear in mind. Your product architecture is more stable and recognised by employees than the company’s team’s feeble structure.
Testing from your design tool
There’s an obvious benefit to this: not having to pay and rely on other third party software (Marvel, Invision) to upload your prototypes to (and where you usually have to further work on polishing the prototype).
With COVID in the scene, it means having a Figma link you can send out to participants and that helps them set up the interview, easing this way the job of the tester (either yourself or somebody else). A wizard-style introduction.
In conclusion, a few months after starting with it we’re till figuring out how to use it. But the social and structural aspect of it makes the challenge more interesting and collaborative.
It’s clear that Figma and what it represents came up at a time where design teams had become way bigger and with that a new set of needs emerged. So despite the will to become software agnostic as teams and as individuals, we can’t ignore the structure within the tools we use and how they define our processes and ways of working, enabling us to better navigate new setups.
This is my first post, I’d be very keen to hear feedback from you, reader. I hope I will put some more thoughts together in the future and hopefully not only about tooling but on experiences and thoughts in regards to our craft.
