Many of you use Figma for design work, right? I’m willing to bet that a lot of you do at your organization. I’m still amazed by the fact that Adobe had to write a billion-dollar check to not acquire it. It’s no surprise why they wanted it – there is a new household name in design software after Adobe had that on lock for what seems like forever.
I have no particular allegiances, except to the web, so I’m happy that Figma is very web-native. I’m also impressed that Photoshop is now a website, but Figma fully embraces webness. Figma has been releasing updates focused on web developers. Variables seem significant. It’s cool to see CodePen alum Jake talk about Code Connect, a way to wire up your real components with Figma!
Not to mention their whole Dev Mode thing, a way of using Figma that’s more like a developer consuming what’s there rather than a designer building what’s there.
You can even build in Figma with components, which aligns with most modern web development practices. But there is a cost to building a component. I think of this insightful paragraph from Blair Culbreth:
When to make components in Figma? Start too soon in your design process and you feel too locked in when you’re still experimenting. Too late and suddenly going back and componentizing is a huge undertaking.
Eternal Struggle of the Systemless Design File: Getting Into the Habit of Using Components in Figma
I don’t have any groundbreaking advice beyond what Blair says. I really like her advice on making a Header and Footer component right away. At least you’ll have that going for you. Then make more as soon as it’s fairly obvious you should.
Speaking of componentry, the one everyone always thinks of first is the Button. Of course, all websites are filled with them. The variations can be endless – sizes, colors, groups, icons, full width, toggles. Then, of course, all the different states. Do you consider the links inside menus buttons? Sometimes? I likely can’t write anything you haven’t heard before, but I do enjoy reading about what other companies actually do. For example, Domas Markevičius’ article on Designing the perfect button for Wix. It seems like they had success by focusing on clarity:
A button must clearly communicate what it does, with zero space for interpretation. Text is the primary element that explains intention.
Regarding what companies actually do, I found Design Engineering at Vercel interesting. Watch all the short videos in the post! They offer a good definition:
Design Engineers care about delivering exceptional user experiences that resonate with the viewer. For the web, this means:
Delightful user interactions and affordances
Building reusable components/primitives
Page speed
Cross-browser support
Support for inclusive input modes (touch, pointers, etc.)
Respecting user preferences
Accessible to users of assistive technologyThere is a lot of work behind the pretty pixels. Design Engineers must go beyond visual appeal and ensure the other pieces that make an exceptional user experience are taken care of.
Even the job title Design Engineering feels relatively new, almost being retroactively applied to people doing that style of work. Perhaps Design Engineering is a way for the less JavaScript-focused side of The Divide to come back into good graces. I enjoy reading about specific examples, like Jim’s detailed explanation of how a resizer bar works. It’s nice to see the work being appreciated instead of being overshadowed by the opposite.
Selfishly, I think of Design Engineering partially as “the kind of cool stuff you see on CodePen a lot, but you do it for a job.”
