“Make It Like the PSD”
on Wednesday 20th of November 2013
When we hand over works of art we also hand over a world of pain. Front-end developer Dan Govan explains and makes a plea for a more collaborative process.
“Make it like the PSD.” It’s something that I’ve heard often in front-end development, and it raises my hackles every time. While the design process probably involved wireframes, sitemaps, user stories and days of client meetings, the thing that’s given the ostensibly binding “sign-off” is always the Photoshop documents; essentially “artists impressions” of what the site should look like.
That they’re used to sell to the client is unsurprising. What’s baffling is that these idealised screenshots are still given to developers, project managers, and QA as instructions of intent. As web technologies progress, the adamant expectation that the site match the PSDs to the pixel is only getting more absurd.
Where PSDs fall short
A PSD has a single set of dimensions, while the size of the browser varies greatly. It’s more prevalent now with mobile devices and RWD, but it’s far from a new problem.
This should be blindingly obvious. Yet, interactions, hover/focus states, animations, and “content choreography” transitions between different portal sizes – none of these are even guessed at in a PSD.
Fonts. Oh god fonts.
They render slightly differently in Mac OS and Windows, in Firefox and Chrome, and certainly in a browser and Photoshop. This is maybe the most overlooked issue; the number of times I’ve had a bug raised to the tune of “the font is wrong” when it’s exactly as specified in the PSD is just crazy. Web fonts need to be tested and tweaked in situ.
It saddens me that designers spend time awkwardly putting real copy into dozens of PSDs, because the fact is it’s very likely to change before going live. Designing around the shape of the content is doomed. If the site is translated (where words can suddenly double in length), put into a CMS and given to the client, or made responsive, then you have limited control over the shape of much of the content. When you have all three, as is fairly common, all bets are off and robust fluidity rather than pixel perfection is what’s needed.
Un-transferable design rigour
When you see a page with five font weights and 11 font sizes with fractions of pixels, you know something’s going wrong.
Mistakenly inferred rigour
I mean those small variations in margin, color or font size that turn out to be oversights or mistakes rather than part of the design intent. They’re not worth spending hours hunting down, but they’ll still be raised in QA because it’s not like the PSD.
Design problems that only come to light at the build stage. It happens.
So what’s to be done?
Designers should learn to code
This is often an end point of these discussions, but it runs against agency siloing, ignores how much time they spend selling, and (to be honest) I’ve had as many problems with designers knowing a bit of markup (OMG TABLES) as with designers knowing none. So you don’t need to write code. I’ll throw together a prototype for you. However, understanding code can be very useful. Basic ideas like how HTML flows onto a page, that fact that drop shadows often break grid-structures, the difference between background and foreground images, that horizontal alignment in unconnected columns is near impossible in a fluid site, or making background images expand or tile could save us both a lot of time backtracking and revising design decisions that simply can’t or shouldn’t be implemented.
Get rid of Photoshop!
It would be lovely if it was used more appropriately, like for sketching or jpeg imagery, wouldn’t it? But this would be a drastic overhaul and clients want to see shiny things. If you need to use it, this guide on Photoshop etiquette can help. But frankly, you can get pretty far with style guides, layout sketches, fonts, images, etc., then moving to the browser and working iteratively.
Give us style guides
In dozens of PSDs and hundreds of amends, it’s easy for inaccuracies to creep in. So having a concrete reference point for developers (and new designers) can be invaluable: defining the palette of colors, font sizes, buttons and link behaviours.
Include designers in QA
This is certainly the most easily implemented; make the original designer part of the QA team and make sure things are in line with the vision, assuming they have availability and the project budgets for it. But that’s just the first step to…
Front-end developers and designers need to work together much more closely in a prototype-and-tweak cycle, moving closer to the browser and de-emphasising the PSD. I’d even say front-end devs should be considered a downstream designer under the direction of the Creative Lead.
Though front-end developers are awesome at filling in the gaps left by the Photoshop-driven design process, we’re still wasting a lot of time chasing down unimportant details and guessing at things that might be critical. We can’t replicate a designer’s vision or the understanding that’s developed through weeks of back and forth with clients unless we’re also part of those conversations.
So quit treating PSDs as sacrosanct canon. Prototype. Work more closely. The creative process continues into the browser whether you like it or not.
A big thank you to today’s guest author Dan Govan for allowing us to republish this post, which first ran on his blog on 25 October. Guest authors are paid for their contribution and all opinions are their own.