The Future of Design is Collaborative
Why I’m Joining Figma
After almost 2 years in New York, I am excited to be moving back to San Francisco to manage the design team at Figma. I couldn’t be more thrilled for my new home, where I’ll be working with an incredibly talented team building the future of collaborative design tools.
In this post, I want to highlight three things:
- Why I’m joining Figma
- A fun glance into my unique interview process
- Some thoughts on the future of design tools
Why Figma?
When I first met Dylan (co-founder and CEO of Figma) a few years ago, I was skeptical that a full-featured design tool could be built with browser technology. Since then, the team has quickly proven me wrong with their ability to keep up with modern design needs like design systems, responsive components, and prototyping — all the while inventing their own new paradigms like multiplayer and vector networks. Figma has become a serious high quality tool in just a single year of being publicly available.
Excited about this progress, I introduced Figma to our team at ClassPass. I was managing the design team there for over a year at the time and Figma quickly became one of our primary design tools. It dramatically improved our product development process:
- We started co-creating and reviewing designs in real time during our critiques to reduce back and forth or ambiguous feedback. Instead of asking “have you thought about this?”, we simply tried suggestions in context together.
- We moved faster by having multiple roles collaborate in our design files. Our PM, marketing, and legal teams explored copy on their own so they could understand the impact of text length in layout, saving us the menial time of updating, re-exporting, and sending back each iteration. Our engineers measured or exported assets as they needed to. Our CEO included comments in context of the designs themselves instead of email.
- Our product teams finally had a single link as the source of truth for our latest designs. Since files in Figma are always up to date, PMs and engineers no longer needed to install an app or download yet another version of: Dashboard-2.1.4-NL-Final-Design-I-Promise-This-Time.sketch
I loved seeing how Figma improved our process. So when Dylan reached out to say they were looking for a Design Manager, I was excited to learn more about the team behind the product I’d been enjoying.
How I used Design Sprint methodologies to find the right job fit
Making career transitions as a designer later in your career can be challenging. Should you go deeper into design management, or explore engineering further and try to build an app? Should you join a small startup, a mid-sized company, a large corporation, or an agency?
It helps to identify with the company’s mission, team, and culture, but how do you evaluate those things? You can start to sense a company’s mission from the outside, but a team and culture take more time to understand. Fortunately, Rasmus, an awesome designer at Figma with lots of career experience from Dropbox, Facebook, and Spotify, gave me some great advice:
For me, spending time with the team, having coffee over discussions around design, made all the difference. I got to really feel what it could be like to work there — and it just felt right.
I took his advice, realizing that working with the company would help both sides evaluate if there’s a mutual fit. So after a few phone screens with the rest of the team, I jumped on a plane to SF to work on a sample project for a week.
I highly recommend this sort of engagement if both parties are able to try it — you get to play employee for a bit and see how you like it, and they get to learn more about you. You learn and iterate quickly in a week, rather than taking one big gamble —it’s just like prototyping in Design Sprints, but for your job.
Being a small team, the qualities they were looking for in a Design Manager weren’t the same as they would be for a larger company. At Figma, it’s a bit more like a player/coach hybrid, where you’re balancing some amount of product design work with managing and growing the team as the company scales. To evaluate this, I worked with Dylan and the Figma leadership team to structure a week that would give us a sense of tasks in both sides of the job. It ended up looking a little something like this:
After my first day, I left the office feeling elated. I had a sense this was going to lead to something great. I was inspired by everyone around me. The team was nurturing, supportive and highly engaged in every conversation I had both in meetings or over lunch. I’m not just talking about the engineering and design teams. I learned a lot from Jason and Topher in support, Katie in marketing, and Badrul in QA. Being a small company, departments at Figma don’t yet feel siloed — you’re more connected with everyone and better understand how their respective responsibilities impact the organization. There doesn’t need to be a ton of process and structure yet. You get to focus more purely on shipping high quality products.
I’ll admit, the week was tiring, and not representative of what I think a normal work week would look like since we were on a tight time frame. It’s similar to when you run a design sprint; you aren’t always moving at that pace, things ebb and flow based on where you are in the process. I’m not sure if we’ll introduce this as an actual hiring process — in practice I don’t think it will scale well or be realistic for everyone, but for me it was the right call.
Needless to say, the hard work paid off. They decided to offer me the role — a chance to help develop and grow Figma’s existing talent and design culture — and I couldn’t say no. It just felt right. I accepted the job that very weekend! 🎉
Some thoughts on the future of design tools
Early on in my design career, I thought it was my sole responsibility to design the product to best meet the goals of the team. I thought I was supposed to go into a room, potentially with a few other designers, and leave the room with the plan of what to build. Then I was supposed to spend time explaining the idea to the rest of the team.
I quickly learned that I couldn’t have been more wrong. Fortunately, I had a fantastic teacher to correct this misunderstanding while working at Google. Our engineering lead, Dan, would show up in our design area and ask us what we were working on. I remember getting defensive, wondering why he was here in the “design room,” and telling him that we needed more time to figure things out. Instead of getting defensive in return, he simply started suggesting ideas and improvements to what we were working on. Each idea was better than the last, which made me excited…but also a bit confused. Who was this non-designer with all of these fantastic design ideas?
I learned then to drop the ego about my role as a designer, because as it turns out, everyone is a designer. We all have a responsibility to make our products great, together.
Dan taught me good ideas can come from anywhere. Within a month, we started colocating our designers with our engineers, something that sounds obvious in hindsight but at the time wasn’t all that common at Google. Oftentimes people instead sat together by role, sometimes on separate floors entirely. I fundamentally disagree with this now; sitting near each other while working together keeps teams connected as they work toward a common goal.
While physical proximity helped a lot, I noticed another point of friction while observing the way we shared our ideas. Our knowledge of design tools as designers — paired with our understanding of graphic design and gestalt principles — made it much easier for our ideas to be heard.
Consider these two ideas. Which do you think will be taken more seriously?
Even if one idea had more potential than the other, the fidelity of the design inevitably impacts how the idea is received — the book is often (unfortunately) judged by its cover. While I wish people had more patience for going through a set of sketches or wireframes, sadly I haven’t seen those ideas thrive as often in practice. Sometimes getting clearer in demonstrating the form helps people better understand its function.
Design tools of the future will make it easier to help people of all backgrounds present ideas on a level playing field.
After all, half of the UX designers I know didn’t study design originally. They studied psychology, art, business, philosophy, architecture, etc. With common components and sophisticated design systems like material design, people should be able to drag and drop these basic ideas to put them together, like legos. These days, tools shouldn’t have a steep learning curve. It should be easy to mock up concepts in high fidelity, together.
I actually don’t think we’re too far from that future. Figma’s investment in web technology lends itself to collaborative moments where a community can help each other build products faster. Sharing component libraries and design systems is as fast and simple as sharing a file or project URL with your team, and they can get running with a full-fledged high fidelity layout in no time.
Fast forward to today
I’m not sure if there will ever really be one tool to rule them all. In fact, I’m not sure I’d want that future given innovation is at its best when there are many players on the field. But if I’m betting on a tool and a company to invest in right now, I’m betting on Figma. With an impressive team that believes in open healthy communication, great values, and doing crazy things like shipping 6 features in 6 days, it seems like a great bet to me.
Want to join the rapidly growing industry of design tools? We’re hiring for a bunch of different roles. 😜
Feel free to reach out to me on Twitter if you’d like to chat!
And it doesn’t have to be about Figma. It can be about binge watching Stranger Things, Rick & Morty, or the unexpectedly entertaining The Good Place. Or it can be about fitness. Or podcasts. Or musicals. Or how unexplainably great the 🙃 emoji is. But only those things.
Huge thanks to Carmel, Peter, Katie, Dylan, Chris, Sho, Rasmus, the rest of the Figma team, Nirav, Marcin, Max, Bobby, Bryn, and many others.
