Product design happens outside of Figma
Product design happens outside of Figma
And why learning Figma won't instantly make you a designer
Hi, it’s Arek! Welcome to Fundament, a newsletter that enables growth in UX and product design. Not subscribed yet? Join for free now:
Last week, during my attendance at WaysConf in Kraków, I had a lovely chat with Miranda Slayter, Principal Designer at Booking and author at UX Survival Guide (my full interview with Miranda will be published in Fundament this October). She told me about a recent interaction with one of her mentees who was struggling to land a new job. Miranda asked them to show a portfolio that they’ve been presenting during the interviews. “Why did you make this UI element like this?” she asked. “I don’t know. It just looked nice,” the mentee responded.
This designer clearly had no idea what and why they were doing.
I was stunned.
But at the same time, I shouldn’t be.
From the past few months of scrolling Twitter, I have observed that hundreds of less experienced designers think that learning Figma equals becoming a designer. They don’t see anything besides the visual part of our job.
Thinking that Figma is a silver bullet is super dangerous for our growth. It’s just a useful tool that helps create some design artifacts and communicate your ideas to the stakeholders, product managers, and engineers. Tools come and go. Mastering the most popular one is important, but you won’t use it solely to do your job as a product designer.
Don’t get me wrong. I use Figma at my current workplace. I brought it to two of my previous workplaces. I’ve been a huge fan of this tool. I still remember the old days of Photoshop and Illustrator, so I appreciate how far the design tools have come and how they have made our lives easier.
Figma is not an issue.
The issue is the lack of realization that there’s much more to do before putting the first rectangle on a canvas and much to do afterward.
Shifting the discussion
The actual product design is not just pushing pixels on the screen. In fact, most of the work happens outside of Figma.
I tried to measure and categorize the activities I do at work. Weeks are very different and dependent on the project and its phase, so these are very rounded averages from the last couple of months:
Discussing priorities, reviewing mockups, and planning future ideas with PMs and engineers – 10 hours
Planning research, talking to users and customers – 3 hours
Analyzing customer feedback – 1 hour
Collecting the data and breaking down the problem – 7 hours
Creating mockups and prototypes in Figma – 11 hours
Writing documentation – 5 hours
Mentoring other team members – 3 hours
On average, I spend only 28% of my time creating prototypes and mockups. Does it mean I don’t design enough?
Hell no.
As Jira isn’t Product Management, or PowerPoint isn’t Marketing, so Figma isn’t Product Design.
I admire what Artiom Dashinsky promotes in his writings. Our industry needs to shift its discussion from tools and visual design to collaboration, strategy, ownership, and design advocacy. The earlier you get this and implement those ideas at work, the faster you will grow as a designer.
Before you jump into the solution space
Jumping straight into Figma after we get a request to design a new user flow is super tempting. When a product manager explains a design problem, you immediately start to see possible solutions in your head. Even worse, you fall in love with the first idea, which is most likely garbage.
If you are not yet familiar with the Double Diamond framework, I recommend reading this article from Productboard’s blog. At a glance, this framework emphasizes understanding the needs and proper problem definition before proposing any solution. It doesn’t exactly mean that you should do super extensive research every time you are approached with a new design task, but at least try to understand why you are tasked with it.
Before you even open Figma, try to answer these questions using your knowledge, previous research data, and the knowledge of other people at your organization:
Why do we need this feature?
How can we make sure this feature will bring value to our users?
How will this feature interact with other parts of the existing system?
How will we measure the success of the feature?
Once you state the problem and collect all the data and answers to all (or most) unknowns, you might slowly start using your creative superpowers and push a few rectangles in Figma. Don’t forget to validate the prototype with your users, stakeholders, and engineers.
Has it always been like this?
I’m guilty of a charge. I did exactly the same things at the beginning of my career. Nobody taught me how to do it properly, so I kind of understand the mass of newcomers who can’t see anything beyond rectangles in Figma. They came here to make beautiful and shiny things but don’t yet understand what it exactly means and how to validate if anybody really needs it.
Who’s fault is it?
Let’s repeat one more time: the actual product design is not about making things shiny.* It’s about bringing value to the users and making the business profitable. Once you understand that Figma is just a tiny aspect of your job, you will grow faster and start having a tangible impact on the product you were hired to design. It’s a difficult job but super fun and rewarding!
* Sometimes it’s also about making things shiny. If one of the goals of your product is to delight users with outstanding visuals, you’ll keep a lot of attention to this part but still, it won’t be the only priority.