Musings · Build
Why I write the code too
A design isn't finished when it's approved. It's finished when it's live and someone's day got easier.
When people hire a designer, they usually expect a file at the end. Screens, maybe a clickable prototype, and a handoff meeting with whoever builds it. Then the designer leaves and the build begins.
On most of my projects, I'm the one who builds it. I write the production front-end: the HTML, CSS and JavaScript people actually see and touch, or the pages and components inside a platform like Salesforce. Here's why, and when it doesn't make sense.
The handoff is where things get lost
The first version of my process was written in 2017, for a large science research program. Designers handed Photoshop files and pixel values to a front-end team. The gap between "approved" and "live" was measured in quarters.
Nobody was doing a bad job. The handoff itself was the problem. A file can show what a screen looks like. It can't show how the screen behaves when the network is slow, what order the keyboard moves through it, or what happens when someone's name is forty characters long. Those questions get answered anyway. If the designer isn't there, someone else answers them, usually under deadline, often by guessing.
The last hundred decisions happen in code
A mockup can't feel latency, tab order or a bad connection. The last hundred design decisions on any project happen in code. What the button says while it's saving. Where focus goes after an error. How a long table behaves on a phone. Whether a menu still works for someone using a screen reader.
Those aren't engineering details. They are the experience. If I designed the screen, I want to be in the room when they're decided. The simplest way to be in the room is to write the code.
It keeps me honest, too. When I know I'll have to build what I draw, I don't draw things that can't exist. And I know exactly what I'm asking a back-end engineer for, because I'm the one who needs it.
What it looks like on real projects
At NASA, I ran a study on why scientists weren't moving from an old data-search tool to its replacement. The findings went into the backlog and were worked, and I implemented a share of the fixes myself. I was writing production front-end on that team, not handing off a PDF. The old tool retired cleanly and its users moved over. Research, backlog, build, and the old system switched off without stranding anyone. Most research never gets to finish that loop.
At Mattress Firm, I redesigned the two Salesforce tools every sales associate carries on a tablet. I also deployed the changes to their Salesforce myself. The redesign went out to every store.
For Imperva, a new customer-support portal went from user interviews to wireframes to production HTML and CSS, which I wrote, deployed alongside a development team in Israel. For Marsh, the layout and navigation fixes that came out of a design review went straight into their Salesforce, instead of becoming a ticket that waits a quarter.
Days, not quarters
The first thing you notice is speed. When the same person designs and builds, there's no handoff queue. The gap between "approved" and "live" is days, not quarters.
The second thing is fewer surprises. The person on the first call is the person in your code. Nobody has to translate what the designer meant. And the checks happen in one place: every change I make is read by me and run on a real device, with a screen reader, before it goes in.
When you should hire a separate developer
Writing the front-end doesn't mean I should build everything. There are good reasons to bring someone else in, or to hand the build to your own team.
You already have developers. If you have engineers who will own the product for years, they should build it. My job then is to give them a design system and written decisions they can build from, not a stack of screens. On an enterprise case-management system for KPMG, I shipped the design system alongside the screens for exactly that reason. A team working from a system builds the fifth screen the way the first was designed. Their team built it.
The hard part is behind the screen. Databases, integrations, data migration, security. Those belong to the people who run those systems. I work alongside them, and I tell them early what the experience needs, so they aren't building to a guess.
The project needs more hands. On bigger projects I bring in contractors I trust, and they're credited on the work.
You have designs and just need them built. I do that too. One page or a set of components, coded and checked, in HTML, CSS and JavaScript, React, or Salesforce Lightning. Tested with a screen reader and on real phones. It starts at $1,600, and the code is yours, in your repository.
The point of all of it
One sentence decides how I work: if the designs we make aren't used, then they don't exist. A beautiful file nobody built doesn't help anyone. Writing the code is how I make sure the thing I designed is the thing people actually get.
If that sounds like your situation, let's talk.