Figma Motion doesn't export to Lottie.
So we built it. Now live in the LottieFiles plugin.
Click export, get an Lottie file you can ship anywhere.
Should this be free? Tell us.
The reason why my personal site has just one font size, monchrome colors, and looks “boring” is simply because I don’t consider myself a great designer.
By using as little variation as possible, I limit the amount of design mistakes I can make, and instead, I try to make the content itself (hopefully) interesting.
I know a few tricks to not make my work look like shit, but it’s far from the skills of a designer working at Linear for example.
To expand on that, from what I’ve seen, most “design engineers” excel at either design or code, not both. I never believed I can be exceptional at both, and I haven’t seen many people that are really, really great at both.
To me, trying to be great at both is like 2-in-1 shampoo conditioner, it never really works as well as two separate products designed specifically to do one thing well.
That’s why I made open source projects like Sonner and Vaul, that require some design sense, but these are far from sharing design kits for example.
And again, there are exceptions, but you shouldn’t expect all design engineers to design and build absolutely amazing things on their own.
I think most design engineers (including me) are just engineers that care about design, but that doesn’t necessarily mean they are good at designing (and vice versa).
To me, the title design engineer is misleading in that it’s more of a description of where one’s interests overlap instead of actually indicating high skill in both disciplines.
Ok happy Monday!
At risk of giving a slightly trope-y response, I think of design as the ability to identify and solve leveraged problems.
I think of engineering almost exactly the same as design, just with more emphasis on the solving part.
I see many people who are adopting the persona of “design engineer” who seem mostly into the veneer layer of software, like making interfaces a little more animated or expressive.
Those aren’t in and of themselves bad things necessarily, but if all you are doing is taking someone else’s design (their solution, their intent, maybe exemplified in a facsimile like a mockup) and implementing it into an existing system (following established principles and frameworks, never really concerning yourself with anything beyond the DOM), then that’s just like being an assembly line decorator.
Which doesn’t have zero value!
But it has far less value than someone I could task with figuring out how we should increase a specific KPI or take better advantage of caching and bundling to reduce costs and load times for our mobile users if we are blowing up in parts of Asia or Africa and understands the tradeoffs of multiple competing solutions.
So instead of chasing trendy titles I think it’s more valuable to just excel at design or engineering, first, before trying to do both and, like most fusion restaurants, just being bad at either.
Most design files quietly add 30–50% to development time.
After 10+ years of shipping products alongside engineers, here’s how I tell a buildable design file from a pretty one.
1. Tokens, not hardcoded values.
Colors, spacing, and typography should all be named. If a developer has to pick hex codes from the mockup, the handoff has already failed.
2. Components need real variants and states.
Default, hover, focus, disabled, loading, and error. Their names should match the codebase, not say “Rectangle 47.”
3. Every screen needs its states.
Empty, loading, and error, plus real edge cases like long names, missing avatars, and huge numbers.
4. Spacing should follow a system, usually 4pt or 8pt.
“Looks about right” easily turns into six rounds of pixel adjustments in code.
5. Design within the actual stack.
If the team uses Tailwind and Shadcn, the design should work with them. We design what can be built, not something developers have to reverse-engineer.
6. Simple final test.
A developer should be able to build the screen without asking a single question. If they have to guess, you’ve given them homework.
That’s the difference between being a vendor and being a partner.
We design for the people who have to make it real.