Chris’ Corner: Design the Job

Y’all use Figma for design work? I’d be willing to bet a lot of you do at your organization. I’m still wrapping my brain around the fact that Adobe has to write a billion dollar check to not acquire it. It’s no wonder why they wanted it — there is a new household name in design software after Adobe had that on lock for(counts fingers)ever.

I have no particular allegiances, except to the web, so I’m pleased that Figma is very web native. I’m also impressed that Photoshop is a website now, too, but Figma entirely embraces webness. Figma has been doing lots of releases focused on web developers. Variables seems big. Cool to see CodePen alum Jake talk Code Connect, a way to wire up your real componentry 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 even build in Figma with components, which obviously jives with most modern day web development. But there is some buy-in cost to building a component. I think of this banger intro 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 huge undertaking.

Eternal Struggle of the Systemless Design File: Getting Into the Habit of Using Components in Figma

I don’t have any great 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 its… fairly obvious you should.

Speaking of componentry, the one everyone always thinks of first is the Button. Of course, all websites are littered in the things. The variations can be absolutely endless. Sizes, colors, groups, icons, full width, toggles. Then of course all the different states. Do you consider the links inside menus buttons? Sometimes? Phew. I likely can’t write anything you haven’t heard before, but I do like reading what other companies actually do. For example, Domas Markevičius’ Designing the perfect button for Wix. It sounds like they had some success with thinking about buttons from fairly first principles, so, hey, nice. I particularly like the focus on clarity:

A button must clearly communicate what it does, with zero space for interpretation. Text is the primary element that explains intention.

Speaking of what companies actually do, I appreciated Design Engineering at Vercel. Watch all the little 8 second videos in the post! They offer a pretty decent definition even:

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 technology

There 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. Maybe Design Engineering is a way for the less-JavaScript-focused side of The Divide coming back into good graces. I love writeups of specific examples, like Jim there writing about the intricate details of how a resizer bar works (don’t we know it). Certainly feels good to see the work being appreciated instead of this gaslighting situation mired in 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.”