Setting up for success with Figma
An introduction to the design tool bringing developers to the table
As a designer turned software engineer, I like to think that I’ve seen both sides of the seemingly existential struggle that is designing a piece of software. Whether you’re working on a simple landing page or a fully-fledged native app, the back-and-forth required for every iteration of your project’s design can easily turn into quite the headache.
Cue Figma. With this browser-based design tool, your design team can still leverage so much of the functionality of powerhouses like the Adobe creative suite. But with no paywall blocking the path, the development team can collaborate directly, and in real-time, without straining the budget to purchase additional software licenses. Figma has a great education section that can get you on your way as a designer, so if that’s you, go nuts! For my friends here who want to navigate Figma as software developers, stick around for the rundown on how this design tool can open the door to a better workflow.
The best design is one you can access.
Like I’ve already mentioned, a major difference between Figma and other design tools is all about access. Figma is not only free, but it’s also cloud-based, so whatever you see on screen is what everyone can see across the project (barring any internet issues, of course). Beyond the initial issue of software access, the other most common blocker for developers implementing a design can be a lack of access to the styles needed to bring it to life in the codebase.
The inability to see what CSS or HTML is being used for the multitude of elements across the board usually spells out extra time — whether hours or days — trying to play with a sea of CSS properties and check against the design files to see if it “looks right”. Once you’re on the project in Figma, you have full access to any relevant stylings with the option to view in plain CSS, iOS, or Android styles. And if your design team is on top of their game, there will even be an element name (presented as a line of commented-out code) that you can use to create descriptive class names and ids in your code. No more trying to come up with a self-descriptive name for the seventh type of a button in your project to panic and settle for “btn-7”!
It’s all about the handoff.
Depending on how things work at your company, you might find that there isn’t much explicit collaboration between designers and developers. And I can understand why — if not everyone has access to the design tools being used, it can add a lot of time to the initial design if designers are sending email after email with attachments for various elements of the design and waiting for feedback from the development team. As a result, developers are usually left out of much of this process. They’re instead handed a fairly complete design, and if there is a change that needs to be made, that can delay implementation and add time that your company may not have to the process.
With Figma, it’s easy enough to invite collaborators via their Teams feature or sharing the project link directly with collaborators. Whichever path your team takes, this opens the gates to a more integrated creation process and can ultimately save you time (and a lot of emails) to make the most out of your software. Just think about it — even if there’s only one developer invited to collaborate at the start of the project, that’s one more set of eyes that can look at the emerging designs and help guide it toward components and layouts that can be achieved programmatically given the team’s budget and timeline. This can also help the team as a whole to manage expectations for the project and act address pain points as the come up. Speaking of pain points…
When in doubt, comment it out.
As much as Figma helps break down a lot of barriers between the design and development team to foster collaboration, we’re not mind readers. Inevitably, you’re going to have questions, and while you can’t pluck the answer straight from your colleague’s consciousness, Figma’s commenting feature is about as close as you’re going to get. And don’t worry about cluttering the workspace with comments; they’re easy enough to toggle on and off. Documentation is everything, and it’s definitely easier to put your concerns on the table while you’re in the design, especially if you spy a potential troublemaker of a component. I’ve had my fair share of experiences where I ignored lingering thoughts about a troublesome component until I was so deep in the code that the only way out was to continue on — and I’d like to try to guide you from a similar fate if I can.
While this is by no means an exhaustive foray into everything Figma has to offer for developers, let alone those in hybrid or strictly designer roles, I hope this has helped introduce you to a new tool that can make your workflow a little easier and more enjoyable. If you’d like to dive deeper into what Figma can bring to the table, you can check out this Figma for Beginners playlist on Youtube or this excellent Figma for Developers guide for more information.
