“Separators. 

Shape fill or stroke?”

Ilya Miskov on Twitter

https://twitter.com/ilyamiskov/status/1689665743997005824

I understand where you’re coming from on this but I have to ask:

— what # conversations did you have *in partnership* w engineering on this?
— % o projects you explicitly followed up post-launch on whether the structure of your components in Figma matched that logic in code?

I get this sentiment 100%, and where a design file is its own end, I agree, but I don’t buy the framing of “permanently working in a silo by yourself”—90% of the time, a Figma file of “a final design” is functionally just a prototype

Less incendiary thought: This is a failure of design leadership more than anything. This doesn't happen in eng orgs (as far as I know) because code style guides and linters are a thing and if you don't follow them, it can go on a perf review

https://twitter.com/ilyamiskov/status/1689665743997005824

As a community, we can’t even agree on something as simple as how to properly compose a divider line. The use of borders was hardly even mentioned in the conversation. 🤯

It's mostly automated because poor code was deemed enough of a problem that automation tools were built. Poor design organization might be less externally damaging than a security hole but it still costs organizations time at scale—it's just much more invisible time.

A whiteboard is erased by necessity, but it doesn’t *have* to be—I’ll bet most orgs have a hundred un-deleted, years old Miro or FigJam boards at this point. And a design file, that’s kept around but unmaintained, is just cruft, and I bet this happens more often than the inverse.

I don't think that every file needs perfectly named layers—the name is relatively unimportant. But if you don't group things logically, use features like autolayout, or do otherwise make your file sanitary then you're doing a poor job.

I ask because I’ve seen so much work in design orgs in anticipation of the perceived beliefs of how people further down a converter belt, or an okay understanding of code makes you think you know about code production.

And it’s humbling how little design teach you about all that

What you’re describing is a messy workshop-problem, not an tool-incompetence problem. Chefs clean their workstation for next morning’s shift, not a potential 2-years-in-the-future-shift, or even a 2 week one.

The “design” is the one that ships. Not the one imagined in Figma file

this doesn’t feel like an apt comparison. poor code org will have more bugs + is mostly automated, while poor design org (naming layers in your example) feels less potentially damaging + is mostly manual (far as i know).

I just saw 2 components (except they weren't components). They were groups, rectangles, some frames... no auto-layout. The two *components* should have been the same but were structurally incompatible. The divider line separating the two blocks should have been a border... 😖

The example I was shown by a friend looked pretty much like this. This is unacceptable. If I were a design manager, I would honestly fire this person.

I was thinking this as well. For me personally this would be the <hr> component. And most everything else would be a border on an auto layout frame/component.

also the idea that "there's no right way to do the work" is naive. there is 100% a right way to compose a design file, or at least ways that are more right than others

Counterpoint: Mastery of software like PS, Sketch or Figma in (virtual) product design doesn’t matter, and is myopic, because its output’s just facilitates discussion or document decisions—in high detail—for others (ENG) to build the darn thing from

Sure, if you are permanently working in a silo by yourself. However, most people work on teams with other designers. If this is you and you don't build usable files, youre slowing down the person that works on that file after you and wasting their time.

Better yet, have a “divider” component that has to be used so that everyone is doing the same thing

This is a deflection that doesn't make your analogy make more sense or your argument any stronger. The point is that design files are not just vehicles for ideas that are going to be thrown away anyway; they are living, working documents that snapshot an interface in time.

So long as any changes happening between a design file and shipping don’t flow back into the design file, the neatly organized file will always be a historic artifact that’s out of date

This is actually subjective (I’m a shape OR borders person myself), but a design team _should_ decide this amongst themselves and stick to it like an engineering team sticks to a tab width.

design feels like one of the only creative professions where you can just blatantly not know how to use your tools, to the point of being successful and celebrated for how much ire you cause your coworkers

"i don't organize my layers" shouldn't be a source of pride, it means you're a fucking asshole lol

I don’t organize and name my layers in Figma for the same reasons I don’t organize and name each section on a whiteboard: They’re immaterial stepping stones that output jpegs.

(Design system & components is the exception since they’re an end in and of themselves)

A whiteboard is erased when youre done with it. A design file is not. That is not a good analogy.

Design leaders are usually either too understaffed or too far from production for it to turn up on their radar, but if I'm spending even 2-4 hours a week remaking other people's designs so that I can do my work, then something is wrong 

(this is not me this week, its a friend)

Think this is a good example. The reason you’d have to remake this is that it has no concept that it will need to be built in code and rendered on different screens. It’s not just a tidy thing, it’s an understanding the system that will be used to build it thing.

Again, it is a snapshot of an interface in time. At that moment is a prototype, but in the future it is a reference point to be built upon for the next snapshot.

Working documents that someday—be it tomorrow or in 2 years— will be used by someone else as the starting point for their work. It is courteous to make a file that isn't a shitshow of unnamed, unframed layers so that that person can get started quickly and easily.

Which leads back to the thought about being understaffed. In many situations, people don't have the luxury of scrutinizing craft because you only have 1–2 designers and hiring more is either very difficult or not an option.

Posts