On this page
For years our hand-off was a file and a hope. Design finished, a link went to the developer, and three weeks later we found out which of our decisions had survived. Usually most of them, but never the ones we cared about most.
Today our developer sits in the first sketch review of every web project. Not to approve the design, but to ask the questions that would otherwise arrive too late. Here is what changed at Fernlow, across our desks in Rotterdam and Montréal, and what we hand over now.
Ask the awkward questions at the sketch
A sketch is the cheapest place to find out that a layout depends on text that will never be that short, or on a photo the client does not have. Developers spot these things fast, because they see a page as content flowing into a structure, not as a picture.
The cheapest layout to fix is a sketch that a developer has already questioned.
Our rule is simple: no screen goes into high fidelity until a developer has seen it as a pencil drawing or a grey wireframe and said what worries them.
Design states, not screens
A homepage is not one picture. It is a set of states: empty, loading, full, too full, broken. We design the long product name, the missing photo, the error after a form is sent, and the page in French, which runs about a fifth longer than the English. Our Montréal clients publish in both languages, and a button sized for “Book” breaks on the day it has to say “Réserver”.
Name things once
Colours, spacing steps, type sizes, and corner radii get a name in a shared list before any page is designed. The same names appear in the design file and in the code. When a client asks for headings “a bit smaller”, we change one value with one name, and every page follows.
For the Ravel & Hue website, the 96 colours of the paint fan lived in one data file. Our developer suggested generating every swatch page from that file instead of laying each one out by hand. It took a week off the build and meant the fan, the packaging, and the site could never drift apart.
Hand off a system, not pictures
Our hand-off is a short document and a working prototype, never a folder of flat images. The checklist we send with every site:
- the named list of colours, spacing, type sizes, and radii, with their values
- every component in all of its states, including empty and error
- the longest real text for each heading, button, and menu item, in every language
- motion notes in plain words: what moves, how far, for how long, and what happens with reduced motion
- the images in their final crops, with alt text written by us, not left for later
- a list of open questions, each with a name next to it
Review the build, not the file
Design review happens in the browser, on real devices, at real sizes. We check on a large screen, a small laptop, and a phone held in one hand. Every issue is logged with a screenshot, the device, and a short note on what we expected. “Feels off” is not an issue; “the heading wraps to four lines at 375 pixels” is.
What it costs, and what it saves
Bringing a developer in early adds a few hours to the first two weeks. It removes most of the surprises from the last two, which is where surprises are expensive and patience is short. After nine years and more than 260 projects, it is the change we would make first if we were starting the studio again.
