from mockup to code (efficiently)

Lately I find myself in the once-familiar position of taking mockups and converting them to markup and CSS. This is generally a pretty simple task, one you could optionally pass off to a junior dev. But that assumes there's a clear process for it. Obvious divisions of labor, patterns, and best practices, I'm finding, make a hell of a lot of difference. Without those things, it becomes even more painful than it has to be. Join me, won't you, as I go back in time to when I last did this stuff and try to figure out what made it work well:

It doesn't matter if it's a fully rendered mockup with all the colors and borders and padding decided on. It can be just a wireframe. However, you need a picture of the final product you hope to produce. If your website was a novel, you'd draft an outline. If your team is just you, maybe you can make it work with no documentation. Once there's even a single other person, however, you need some representation of the end goal in order to begin doing work. From a mockup or wireframe, you can start getting a feel for the data you'll need access to, which is something you want as early as possible.

If you're both visual designer and frontend dev, this and the step above may be one in the same. But if those roles are handled by separate folks, the work of the first needs to be translated into the domain of the second. The way elements fit together visually is different (obvs) than the way they fit together in markup. Separations and groupings not evident in an image become much more clear with HTML tags around them. It's easier to see where an array of data will be looped through, or where a condition will determine visibility, an error state, or some other presentational change. Translating to markup should leave you with a fuzzy sketch of the data you'll need to receive from the server.

If you're working on a dynamic page, you're using some sort of template. Whether it's client-side or server-side, you should replace the dynamic pieces of your dummy markup with template tags. Creating dummy data at the same time will let you test your template, even if you're not the backend developer, or you're waiting on something in your application's data layer to be ready. While dummy data obviously won't help you catch edge cases like unescaped characters or data that's longer or shorter than what you're expecting, it will firm up the picture of your viewmodel so that whoever's connecting it to live data can do that work without a lot of back-and-forth.

This is the awesome part where whoever's doing the server-side code swaps hard-coded viewmodel values for dynamic stuff and everything just magically works.

J/K. This is the part where you find the bugs. Not just the data bugs mentioned above, but bugs in the design, such as, "that just doesn't look very good with text in it." So you back-track to whichever step contains the bug and go through the steps again. If you can show me a development process that avoids that sort of repetition, I will print out this blog post and eat it.

Pretty simple stuff, but notice there are a bunch of different roles in there, and this allows those that touch the frontend to proceed on their own schedule without holding each other up. It also prevents people in those roles from being engaged too early and floundering trying to make guesses about what the eventual shape of a page or application will be, letting everyone waste less effort.

It also delivers work products biased heavily toward YAGNIBSW ("You Ain't Gonna Need It But So What?"). It builds in a thoughtful amount of rigor and separation of concerns at the point where it's easy and cheap to do so, which will save you time down the road if you go through a lot of revisions, and will at worst seem less cowboy-ish and cool if you don't.

Are there any other steps you use, or an entirely different, better way of doing it?