3 daily habits that help me expand my vision as a design engineer

I used to spend hours looking at beautiful interfaces thinking “how did this guy get to this level?”

I thought it was talent. a gift. that some people were just born knowing how to compose layouts and I was born knowing how to center a div with margin auto.

nope. it’s practice. it’s repertoire. it’s doing the right things consistently.

over the past few years I’ve developed 3 habits that completely changed how I see frontend. they’re not hacks. they’re not shortcuts. they’re exercises that expanded my vision as a design engineer in a way no course or tutorial ever did.

and the best part: any dev can start today.

consume references with intention

I usually start my day 1h before work. I make my tea (yes, I’m a tea guy. I’ve accepted my fate) and browse through X/Twitter, Layers, Design Spells, Dribbble.

basically anywhere people are posting good UI.

but it’s not random scrolling. it’s an exercise. it looks like random scrolling if my boss sees me, but it’s an exercise.

let me give you an example: say I stop at a screen with an avatar group. instead of just thinking “nice” and hitting like, I stop and try to break it down.

how does this layout work? how do the avatars overlap? if I had to code this right now, how would I structure it?

at first you’ll probably think position: absolute with negative margin for everything. and that’s fine. we’ve all been through that phase. some never left. no judgment.

the point is that over time this exercise becomes automatic. you start looking at any interface and immediately understand the logic behind it. even when you shouldn’t, like when you’re in your banking app and instead of paying your bills you’re analyzing the border-radius on the cards.

the goal isn’t to copy anything. it’s to train your eye to read interfaces the same way you read code. to understand why something makes sense visually.

the difference between a dev who implements layouts and a design engineer who creates interfaces starts right here. in the intention behind how you consume what you see every day.

practice animation outside of code

I know this sounds pointless. “bro I’m a dev, if I’m not coding the animation why would I open After Effects?”

that’s exactly what I used to think. until I realized the problem was never the code. it was me not knowing what a good animation should look like. I was slapping transition: all 0.3s ease on everything and thought I was killing it.

the exercise is simple: install After Effects or open LottieLab, grab any Figma component you have saved, export it and start playing around. keyframes, easing curves, momentum, timing.

no tutorials. no trying to finish anything. just experiment.

you start to understand why an ease-in-out works here but not there. why 200ms is better than 400ms in that context.

and then when you go back to code, you stop guessing values. you stop putting 400ms ease-out on a dropdown menu hover. I used to do this all the time. the dropdown would descend in slow motion like a dramatic soap opera scene. nobody deserves that.

it seems silly. but it’s the kind of thing that makes someone use your product and feel like there’s something different about it. without being able to explain what.

that feeling of “this feels polished” never comes from the code. it comes from someone who understands timing.

read code from people you admire

for a long time I’d look at the interface of certain projects and think “how did this person reach this level of component craft?”

I started asking people I think are really good at frontend. “how did you pick up these construction patterns, this way of organizing components?”

and most of them gave basically the same answer: reading code from people they thought were next level.

no secret course. no magic bootcamp. literally opening GitHub and reading code like reading a book before bed. yes, we’re that kind of people.

João for example told me he learned a lot about component creation and React best practices by studying the Radix codebase. in my case the turning point came from looking at Paco Coursey’s cmdk and the Supabase repo.

you open the code, start navigating, and suddenly it clicks: “oh so that’s how you solve this.” it’s like discovering the jar lid opens the other way. changes everything.

you don’t need to invent everything from scratch. the best code decisions I’ve ever made came from studying how someone I admire solved the same problem.

some people I admire and have learned a ton from following: pqoqubbw, Diego Haz, John Phamous, among others.

what changes after 3 months

these 3 habits aren’t revolutionary. they’re not a secret. most people I admire in frontend do some version of this.

the difference is consistency.

do these 3 things for 3 months and the way you look at interfaces changes. you stop being the dev who implements screens and become the dev who understands interfaces.

and that difference, in today’s market, is worth more than any new framework. including the one that launched last week that you’re already wanting to migrate everything to.