Optimizing for Collaboration in Figma
Last week, Figma Chicago held our 2nd Meetup, titled “Optimizing for Collaboration in Figma”. This is a recap of the event.
The evening was hosted at Industrious in River North, and started off with networking and food. Our first Meetup was about switching from Sketch to Figma, so I decided to make our second one about why it works so well as a collaborative tool.
If you couldn’t make it, please sign up and get notified when our next event is!
Who am I? My name is Trucy Phan and I’m one of the co-organizers of Figma Chicago. I’ve worked as a designer and developer at BlinkTag, Drop, Plate IQ, and Ample. Most recently, I was as a Senior Product Designer at Yello.
After intros and food came the presentation, followed by Q&A. Nothing too crazy there, but here’s where I switched things up a bit.
I created the presentation using Figma, then created a link to invite editors to the file. Next, I used bit.ly to shorten and customize the URL so anyone with a laptop and wi-fi access could type it in their browser, join the presentation and leave comments, and even draw art in a “Guestbook” page.
As for the presentation, collaboration on product teams is admittedly a pretty vague and loaded subject. But this isn’t my first rodeo, and what better topic to speak on from a personal perspective? Here are the main areas I covered.
- When is a design ready for development?
- If you don’t know, ask! Results from an internal survey and what I learned
- Using other Figma features for collaboration
1. When is a design ready for development?
In an ideal design to dev process, things might researched and validated, undergo design explorations and get critiqued by stakeholders, then get built alongside the occasional copy tweak or other changes.
However, we know process doesn’t follow a linear path. It can diverge or come full circle, things change, and barriers can exist to communicating that change. One of the hardest aspects of any project I’ve worked on is communicating the right amount of information at the right time to the right stakeholders, in a way that produces the least amount of friction.
One of the hardest aspects of any project I’ve worked on is communicating the right amount of information at the right time to the right stakeholders, in a way that produces the least amount of friction.
Designer: Wait! I need to update this design.
PM: I just got new requirements!
Developer: This design is missing some states.
Exec: Hello. I’m changing the scope
Although Figma is pretty great, and using it to optimize collaboration is the subject of this article, here’s a spoiler: communicating change… requires communication. 🙃
Here are some things you might want to communicate:
- 👩🏻 Who was involved in the change
- 📝 What was changed, what else might be affected, what to consider next
- 📅 When you decided to change it, when the change will take effect
- 🔗 Where the documentation is, where relevant changes can be seen
- ❓ Why you changed something
- 📦 How the change will be rolled out
Hmm, this is starting to look like a process! In the absence of good process, you’ll find yourself forgetting some of the steps above, which can lead to bugs, missed edge cases, redundant work, and frustration from stakeholders you left out.
If you don’t have one established, here’s a good place to start that outlines why having a good process matters and how it can help your team scale, save time, and be more successful.
Process aside, to answer our original question “When is a design ready for development?”, I knew I could at least start with file covers in Figma. At their most basic, they are automatically generated from a zoomed out version of the contents of the first page in your file, like this:
When I learned you can customize them, I knew I wanted to use them to communicate the status of designs.
In the first version I designed, I used the following elements:
- 🔢 Jira ticket number
- ⏺ Circles for design progress (yellow = WIP, green = ready for dev)
- 🔼 Triangles for dev progress (outline = not started, yellow = started, green = ready for QA)
However, we quickly realized as a team that there were shortcomings.
- 🚫 All the thumbnails looked identical, which made files hard to find
- 🚫 Developers needed to be users with edit access in Figma in order to update the triangle status (💸)
- 🚫 Binary design circles between WIP or Ready for Dev didn’t reflect the true statuses design files can have in their lifetime
To alleviate these problems, I designed a new cover with the following:
- ➕ Additional tags to indicate design systems work, Jira tickets, explorations, and archived files
- ➕ A thumbnail preview area to solve having files look too visually similar
- ➖ Removed triangle dev status that wasn’t being used
The tags we use include:
- “Exploration” (early-stage designs)
- “MH-1891” (a feature team abbreviation + the Jira ticket number the design was attached to)
- “Global” for design systems-related work
- “Archived” for out of date work
Depending on your design projects, other useful tags on files could include “Needs copy review” or “Ready for dev”. I’m curious: what are other methods do you use to label your files?
Edit (9/15/2019): On September 12, 2019, Figma announced a new feature that allows users to set any frame as a file thumbnail. I would recommend trying this out as well to see what system works best for you and your team.
2. If you don’t know, ask! Results from an internal survey and what I learned
If you don’t know how things are going with your team, or what to improve, it doesn’t hurt to ask your designers, PMs, and engineers.
After switching Yello’s product team from Sketch to Figma, I sent a survey to designers, PMs, and engineers to gauge how things were going. It was a low-effort, high-value activity with only about 10 questions.
Here are a few questions I asked, and what I learned.
To my surprise, not as many engineers were leaving comments in files as I had thought would be. In my mind, people were in Figma giving each other virtual high fives, tagging others when relevant, and using comments to call out things like scope creep and missing edge cases.
In reality, we’d had new engineers join and gave them Figma logins, but no one had properly onboarded them to the tool!
For this question, the low designer score made sense to me, as it was a design tool, but even the highest perceived difficulty still wasn’t close to being a 5, which was (“Very difficult”). The high rating from engineers made sense, as I had unintentionally given workshops to PMs and designers, but not all engineers. As a result of this survey, I held a Figma workshop just for engineers, made the Google Slides available on Confluence, and created a Slack channel called #figma-questions so anyone could ask for help.
Despite being the user group that had the most difficulty learning how to use Figma (2.7/5), engineers — more than designers and PMs — responded that Figma “absolutely” saved them time compared to previous tools and processes.
Despite being the user group that had the most difficulty learning how to use Figma (2.7/5), engineers — more than designers and PMs — responded that Figma “absolutely” saved them time compared to previous tools and processes.
Although each team had different PMs, designers, and developers, this ranking happens to be — top to bottom — the order that Figma was adopted by each team. The longer each team had been using Figma to work with each other, the more collaboration was rated as having improved.
The longer each team had been using Figma to work with each other, the more collaboration was rated as having improved.
3. Using other Figma features for collaboration
I. Comments
II. Jira Integration
III. Page titles and organization
IV. Observation Mode
I. Comments
Benefits:
- Used to ask for clarity for cases that weren’t considered (or aren’t shown) in a design
- You can tag someone who might have additional context or opinions to share
- Good ideas can come from anyone — through a comment, any stakeholder can suggest a better idea or alternative solution
What wasn’t working:
- 🚫 Comments from developers to designers, mixed with designer-to-designer or PM-to-designer feedback made it hard for developers to read through what was relevant for them.
- 🚫 There wasn’t always clear direction for when a developer should look at one component, versus thoroughly look through every frame, page, and prototype in a file.
What we do now:
- ✅ Designers and PMs use comments to leave feedback for each other, but AC for devs is documented in Jira instead of in Figma comments.
- ✅ Setting up meetings with devs to walk through design files and get feedback in real time, instead of long comment threads in Figma that made it difficult to document design decisions or changes.
II. Jira Integration
Benefits:
- Once a design has been attached to a Jira ticket, a designer can continue to work on the file and it will automatically update, live!
What wasn’t working:
- 🚫 Links could be added for Figma files, frames, and prototypes, but the integration only allows for one Figma link per ticket.
- 🚫 Each time you clicked on a Figma link, some people preferred opening it in their browser, and some preferred opening it in the app.
Solution:
- ✅ Designers either kept all work related to a ticket in one file, or else would add other links to specific frames or prototypes in the ticket description.
- ✅ We use this Chrome extension which lets you choose how a Figma URL opens.
III. Page titles and organization
What wasn’t working:
- 🚫 It was difficult to tell explorations and iterations from final designs that were ready for development
- 🚫 It was hard to remember which pages contained prototypes
Solutions:
- ✅ Naming pages specifically with version (v1, v2, v3), keeping explorations/scraps in their own page, and maintaining a “_master” or “_ready for dev” page
- ✅ Inserting emojis like ▶️ and ▶︎ to indicate which pages should be played as prototypes
IV. Observation mode
If you’re not familiar with Figma’s observation mode feature, when multiple people are viewing a file, you can mirror anyone’s viewport by simply clicking their avatar.
At Yello, we use observation mode for:
- Following along in a design review/crit if someone is remote or WFH (bonus: it’s not a pixelated or laggy screen share)
- Following along in a regular in-person design review/critique
- Watching what users click on in a prototype
Additional uses:
- Open a Figma URL on another device (maybe the resolution or colors are different from your monitor), and follow yourself
- Sharing a presentation deck with others, and allowing them to follow you — the way this Meetup was done! This allows attendees to leave comments on specific slides, and is more accessible in case someone can’t see the main screen from where they’re sitting. Even in our case, the shared URL worked well because our projector had contrast issues that made some slides hard to see.
Conclusion
I enjoyed meeting everyone who came to our 2nd Meetup and am looking forward to the next.
How do others facilitate and encourage collaboration? I’d love to hear in the comments, or feel free to reach out to me on Twitter. If you’re in Chicago, drop by our next Meetup!
Additional Resources
- This is an excellent, fun and short talk on Using design systems for non-traditional use cases (20 mins) by Noah Levin, Design Manager at Figma
- Another great talk from Noah on what kinds of attitudes and tools foster collaborative cultures https://www.youtube.com/embed/MJhYEgG0s9A (35 mins)
- Great article with tons of Tips for a better developer workflow in Figma — Thomas Lowry, Designer Advocate at Figma
Follow Figma
- Bite sized updates on Twitter
- Search for specific topics or ask questions on Spectrum
- Case studies, tips and more on the Figma blog
- The latest goodies in gif form with Figma releases
- Figma has a great selection of tutorials on YouTube
