For four years, I've had a foot in two rooms. In one, I'm presenting Figma mockups and talking through user flows. In the other, I'm in a code editor implementing those same flows, sometimes catching my own design decisions turning out to be harder to build than I'd assumed. Being both "the designer who codes" and "the developer who designs" isn't a title anyone gave me — it's just where the work landed, across enough client projects that I've started noticing patterns in what that overlap actually changes.
It kills a specific kind of bad handoff
The classic failure mode in design-to-dev handoff is designing something that looks great in Figma but wasn't built with real constraints in mind — text that doesn't account for translation length, a layout that assumes every card has an image, a component that looks reusable but secretly isn't. I've made these mistakes. I've also had to live with them on the development side, which is a very effective way to stop making them. Many of the designs we had to implement also came from external design agencies, so I had a close look at what is done right and what happens when things go wrong: a fellow developer desperate because "how am I supposed to ever do this in code?" followed by crickets and pity looks across the team.
When I'm designing, I'm asking implementation questions earlier than most designers would think to: what happens when this field is empty, how many states does this component actually need, is this "custom" interaction going to cost the client three extra days for a marginal visual gain.
It also makes me a more opinionated developer
The flip side is just as real. When I'm implementing someone else's design — or even revisiting my own from a few weeks earlier — I catch accessibility and usability issues that a purely execution-focused developer might implement faithfully without questioning. A contrast ratio that technically passes but reads poorly on a real screen. A focus order that makes sense visually but not to a screen reader. I flag these, sometimes propose an alternative, and because I understand the design reasoning behind the original choice, the conversation tends to be a negotiation rather than a complaint.
Where it gets genuinely hard
I want to be honest about the tradeoffs, because "I do both" can sound like a strict upgrade and it isn't. Context-switching has a real cost — moving from a research-and-empathy headspace into a logic-and-syntax headspace (and back) within the same afternoon is tiring in a way that staying in one lane isn't. There's also a risk of being pulled into "just fix it yourself" territory on both sides: designers assuming I'll code around a design flaw instead of them addressing it, developers assuming I'll re-design something instead of raising it as a proper design conversation. Keeping the boundaries of each role clear, even when I'm capable of doing both, has been its own skill to learn.
Why I still think it's the right fit for me
My favorite part of any project is still the same thing it's always been: watching a client's face when they see a solution that finally clicks for them, and then a few weeks later, watching that same solution actually work for the people using it. Understanding both the "why" behind a design decision and the "how" of building it means I can be useful at more points in that journey — not just to hand off cleanly, but to actually close the loop between what was intended and what gets shipped.