Handing a Design to Somebody Who Will Build It

What a design usually contains

Three or four pages, at one width, in their ideal state.

Every field filled correctly, every image present and well-proportioned, every list at the length that looks best.

Which is the site on its best day and is perhaps a tenth of what has to be built.

The rest gets invented during the build by somebody who is not the designer and does not want to interrupt anybody.

The states nobody draws

• Hover and pressed for every control.
• Focus, for keyboard users.
• Error on every form field.
• Empty, where a list has nothing.
• Loading, where something takes time.
• Disabled, where an action is unavailable.

The third causes the most trouble. A form design showing perfectly completed fields says nothing about what a wrong entry looks like, where the message appears, or whether the rest of the form survives, and those decisions get made under time pressure.

Every width, not just two

Since the design is usually drawn at a desktop width and perhaps a phone one.

Between those there is a range of widths where the layout has to decide what to do, and that decision was not drawn.

Say what each row becomes as the screen narrows: what stacks, in what order, and what disappears.

That is a paragraph per section rather than another set of drawings, and it removes most of the guessing.

Also say what happens at the very wide end, since a layout with no maximum width produces lines of text stretching across a large monitor.

Supply the content extremes

Because the design was drawn against convenient content.

Show the longest heading, the shortest, and one with an awkward word that cannot break.

Show a name that runs to two lines, a price with more digits, and a list with one item and with thirty.

Show a photograph in the wrong aspect ratio, since one will arrive eventually.

A design that has been drawn against those cases is a design that survives, and one drawn against ideal content is a prototype.

This is the item that most reliably prevents things breaking three months after launch.

A worked example

A business approved a design showing four pages at desktop width.

During the build the developer made decisions about the form error styling, what the menu did at tablet width, what happened when a service list had two items, and where the focus outline went.

None of those was wrong exactly, and none matched the design's character, so the finished site felt slightly inconsistent without anybody being able to say why.

On the following project the designer supplied a page of states and a paragraph per section on stacking behaviour.

The build had eleven questions instead of about forty, and the result matched the design.

The additional design effort was half a day.

Name the values, not the appearance

Since a picture is measured differently by everybody who looks at it.

Supply the actual numbers: type sizes, line spacing, the spacing scale between sections, the corner radius, the colours as codes.

A short list of those is more useful than any number of annotated screenshots, because it can be applied rather than interpreted.

It also becomes the basis for consistency afterwards, since the same list tells whoever adds a page next year what to use.

Where a design tool can export those directly, export them, and where it cannot, write them out.

Say what matters and what does not

The instruction that saves the most time during a build.

Every design contains things that are decisions and things that are incidental, and a developer cannot tell which is which.

Mark the elements where the exact treatment matters, and say plainly where a reasonable approximation is fine.

Without that, a careful developer spends hours matching something nobody cared about, and a hurried one changes something that mattered.

Three lines of that guidance saves more time than any amount of additional drawing.

Agree how questions get asked

Since there will be questions and the handling of them decides the outcome.

Name one person who answers, and a route that produces a reply the same day.

The failure mode is a developer with a question, a designer who is on another project, and a deadline, which produces an invented answer.

Where a quick answer is not available, agree in advance that the developer chooses and flags it for review rather than guessing silently.

A short list of flagged decisions at the end of a build is a good outcome and a silent set of them is not.

Ask for it back as a working page

A step worth agreeing before anything is built.

Review the first completed page in a browser rather than as a screenshot, on a phone as well as a desktop, before the rest are built.

That is when the states and the stacking can be checked cheaply, since the same decisions are about to be repeated across every other page.

Reviewing screenshots at this stage reintroduces the original problem, because a screenshot is again the ideal state at one width.

One page reviewed properly saves the same corrections being applied nine times afterwards.

The counter-case

Over-specifying is its own cost.

A design documented to the last pixel takes longer to produce than the difference it makes, particularly on a small site built from a template.

Experienced developers also make good decisions and resent being told how to do their job.

And for a project where the same person designs and builds, most of this is unnecessary.

Supply the states, the widths, the extremes, and the values, and say what is incidental.

The handover

1. Draw the states: hover, focus, error, empty.
2. Say what stacks and in what order.
3. Show the longest and shortest content.
4. List the values, not the appearance.
5. Mark what is exact and what is approximate.
6. Name who answers questions.
7. Ask for a list of decisions made.

Step five prevents the two opposite failures at once, since a developer who cannot tell what matters will either waste time on something incidental or change something that was deliberate.

What happens when the relationship breaks down is covered in the designer who went quiet.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.