← All writing

The long journey back to Front-end

My career started with designing in Photoshop and shipping in HTML. Twenty years later, I'm pretty much back.

In 2006, as an intern at a design studio, my job had one title - Web designer. I drew pages in Photoshop, then I built them: HTML, CSS, a bit of JavaScript. If the project needed a backend, an engineer picked it up from there, and we kept working side by side until it shipped to the client. Nobody called it a handoff. That was just how websites got made.

A few years later, UX design arrived as a title, and with it a new process. I had to write up case studies, create lo-fi wireframes, build arguments, take work to crits, research (or work with a researcher), design pixel-perfect UI, iterate, do redlines and hand off work to front-end engineers in Sketch and then Figma. The to-do list seemed overwhelming, and I almost left the field feeling irrelevant at moments.

Until I found my footing as a UX designer.

The same list of things though, didn’t leave space for front-end anymore. This was a different job altogether.


Fast forward to 2026

I feel I’m back where I started, but with better tools

Today it feels like I’ve come back to where I started. The difference is the tools. I design and prototype in code, and I get to polished, working outcomes in less time than it used to take me to slice a Photoshop file. In fact my new website took less than 20 hours to get up and running.

I also know that I need my engineers: I build the experience, not the architecture. Knowing that boundary is what makes working this way a team-adventure.


The mental model

With this latest iteration of Work - the biggest unlock I found wasn’t the tooling. It was sitting down with my engineers and agreeing on how the work actually flows.

Mental model

  1. The repository is the source of truth. The main branch in the cloud is always the latest version of the work. Not a Figma file or a deck.
  2. I check out a local copy and create a new branch. The branch is my sandbox. Nothing I try there can break anyone else’s work.
  3. I build something, and we critique it there. My design team can review it on the branch, on an actual working software instead of screenshots.
  4. I commit and push. Each commit gets a short note on what changed and why.
  5. I open a draft pull request. The triad, meaning design, engineering and product, reviews it together. Engineers see exactly what changed. PMs see it running.
  6. It merges back into main. My work becomes part of the product, next to everyone else’s. 🎉

That’s the whole loop. Once we shared it, I stopped handing work over and started contributing to the same thing my engineers and PMs were working on.

Almost twenty years later, I’m back in the same files as my engineers. That’s the part I missed most.

Subscribe on Substack →