We work with a couple of freelance designers who hand us PSDs to turn into HTML and CSS, and for a while every handoff meant a round of back-and-forth emails about spacing and font sizes that weren't quite specified. It got worse as we took on more projects at once, since every designer had their own file organization habits and we were relearning each one from scratch.
Where the friction actually came from
The pattern we kept hitting wasn't really about design quality, the designs themselves were fine, it was about ambiguity in the file itself. A flattened PSD with no layer names beyond "Layer 47" tells a developer nothing about what's a button versus a decorative element. A type treatment that looks like 14px in one spot and 15px in another, because the designer eyeballed it in Photoshop rather than working from a defined scale, becomes an actual decision a developer has to make rather than a spec to implement.
None of this was anyone being careless, exactly, it's just that a PSD built for visual presentation and a PSD built to be implemented in code have different requirements, and most design work naturally optimizes for the former.
What we now ask for
- Layers organized by section, not flattened, so we can measure exact padding and understand what stacks on top of what.
- A type scale noted somewhere in the file, even just as a text layer listing sizes used, rather than us having to sample every heading with the eyedropper-equivalent to guess whether two headings that look similar are actually the same size.
- Any hover or interaction states designed separately, not left for us to guess, since guessing a hover state usually means guessing wrong at least once per project.
- Actual copy where possible, not lorem ipsum, because line lengths change layout decisions, a two-line heading wraps differently than a one-line heading and that changes spacing choices further down the page.
- A short note on any responsive behavior expected, even informally, since not every designer at this point is thinking in terms of how a layout should adapt at a narrower width.
What changed for us
Build time on a typical five-page brochure site dropped by what felt like a full day once designers started following this. It's a small amount of upfront friction that saves a lot of guessing later, and it means fewer "that's not what I designed" moments during review, which used to be the most frustrating part of a project for everyone involved, designer included.
Getting designers to actually adopt it
The checklist alone didn't do much the first time we sent it, mostly because a bullet list of requirements without context reads like busywork to someone who isn't the one implementing it. What actually worked was walking through one real handoff together, screen to screen, pointing out specifically where the ambiguity had cost us time on a past project. Once a designer sees the actual cost of a flattened layer or a missing type scale, in minutes spent guessing rather than in the abstract, the checklist stops being a chore and starts being something they reach for themselves before sending a file over.
We've also started sending the checklist earlier in the relationship, before the first project starts rather than after the first handoff goes badly, since it's a much easier conversation to have before either side has a specific frustration to point to.
A specific example that changed our minds
One project made the case for this checklist better than any explanation could. A restaurant client's menu page had a repeating card layout, and the designer's PSD showed exactly three example cards with short, similar-length descriptions. Real menu items varied wildly in description length, some just a dish name, others a full sentence, and the flattened, unlabeled layers gave us no indication of how the designer intended the card to grow, whether the image should shrink, whether the card should just get taller, whether text should truncate with an ellipsis instead.
We guessed, built it one way, and the designer flagged it in review as not matching their intent, which meant redoing card spacing on every single item on the page. That single round trip cost roughly half a day, all of it avoidable if the original file had included even one example of a longer description alongside the tidy sample copy, or a quick note about the intended overflow behavior.
That project is the one we now reference when explaining the checklist to a new designer, since "your card layout might not degrade gracefully with real content" is a much more concrete and convincing argument than a generic list of best practices.
Where we still have to guess
Even with a clean handoff, a few things are never fully specified and probably shouldn't be, exact easing curves on a hover transition, for instance, or precisely how a card should behave when its content is longer than the example shown in the design. We've stopped treating those as failures of the checklist and started treating them as normal implementation decisions that a developer is expected to make sensibly, informed by the rest of the design's tone rather than needing to be spelled out. The line we're drawing is between decisions that should have been made in design and decisions that are reasonably left to whoever's writing the CSS.
Keeping the checklist itself honest
The checklist has changed at least three times this year already, dropping a couple of requirements that never mattered in practice and adding ones we didn't anticipate needing at the start. Early versions asked for exported CSS values directly from a design tool, which sounded useful in theory but in practice designers were exporting values from an outdated version of the file more often than not, creating a new source of ambiguity rather than solving the old one. We dropped that requirement in favor of simply asking for the layered source file itself, treating it as the single source of truth rather than trusting a secondary export to stay in sync.
We keep the checklist in a shared document that both of us can edit, and we update it the same week something new bites us, rather than letting frustrations pile up unaddressed until eventually rewriting the whole thing from scratch. Treating it as a living document rather than a fixed policy has made it something designers trust is actually reflecting real, current needs rather than an arbitrary set of rules handed down once and never revisited.
Where this doesn't apply
For designers who work primarily in the browser already, sketching directly in HTML and CSS rather than handing off a static file, none of this applies in the same way, the ambiguity mostly disappears because the "design file" and the "implementation" are the same artifact. We don't have any client relationships built that way yet, most of our design partners still think and work primarily in Photoshop, but we can see a future where a checklist like this becomes less relevant as design tools and workflows shift. For now, in the world we actually work in, it's saved real time on every project since we started using it, and we'd recommend any small shop working across a design-to-development handoff to write down their own version rather than relearning the same friction points project after project.
One more habit worth mentioning
We've also started asking, before a project kicks off, roughly how many rounds of design revision the client's contract allows for, and making sure the designer we're working with knows that number too. It sounds unrelated to a technical handoff checklist, but a design that's still shifting structurally when it reaches us guarantees the checklist gets applied to a moving target, and no amount of layer organization fixes a handoff built from a file that's about to be revised again anyway. Getting the design itself reasonably settled before it reaches us has turned out to matter as much as anything on the checklist proper. It's a small conversation to have upfront, but skipping it has cost us more rework than any missing layer name ever has, since a checklist can only clean up ambiguity within a file, not the deeper problem of a file that's fundamentally still in flux when it lands on our desk.