Design Handover Your Developers Can Build From Without Guessing
The package that turns approved screens into something a development team can build correctly: annotated measurements, every component state, exported assets and answers on call. GullySystem prepares handover for our own designs and for design files you already own.
What Handover Means Beyond Sending the Files
Sharing a link to a design file is not a handover. A developer opening that file has to judge spacing by eye, invent what the button looks like while it is saving, and write a message for an empty list. Every guess becomes a change request later. Handover is the deliberate work of removing those guesses.
At the End of Our Own Design Work
Every design engagement we run finishes this way, with the package and a walkthrough for whoever is building it — your team, your vendor, or ours.
For Design Files You Already Have
Designs from a previous agency, or from a designer who has since left, usually incomplete. We take stock of what is there, fill the gaps and produce something your developers can work from.
Before a Build That Is Already Scheduled
Where development starts next month and the screens are approved but nobody has specified behaviour, the specification work happens before the sprint instead of during it.
What Developers End Up Guessing
Where a specification stops short, somebody still has to decide. These are the decisions that end up being made without you in the room.
What Happens While It Is Saving
The design shows the button. It does not show the button mid-save, so each developer picks their own spinner, their own disabled state and their own wording, and the product ends up with several of each.
What an Empty List Looks Like
Screens are drawn full of sample data. The version a brand-new user actually sees first is the one nobody designed.
How Long Is Too Long
A customer name field drawn at one width, and a real customer name three times longer. Without a rule, the text wraps, truncates or breaks the row depending on who wrote that screen.
What the Error Message Says
Validation appears as a red outline with no words, so the sentence the user reads gets written by a developer late at night and reaches production unchanged.
Which Spacing Was Intentional
Two similar screens with slightly different gaps. A developer cannot tell which was a decision and which was a slip, so both get copied faithfully into the build.
What It Does in a Narrow Window
One desktop layout and no guidance below it, so the behaviour on smaller screens is invented during the build and reviewed only after it ships.
What Is Inside a Handover Package
The contents change with the product, but these parts are in every package we prepare.
Annotated Screens
Spacing, sizes, type styles, colours and alignment marked on the screen itself, so a measurement is read rather than estimated with a cursor.
Every Component State
Default, hover, focus, active, disabled, loading, error, empty, read-only and selected, drawn rather than described, for each interactive element on the screen.
Behaviour Written Down
What each control does, what is validated and at what moment, the exact message text, what happens on success and on failure, and what the screen shows while it waits.
Content and Edge Cases
Field limits, long-name behaviour, zero and negative values, very large lists, and the wording for every state that has no data in it yet.
Assets Exported Properly
Icons, logos and images exported at the sizes and formats the build needs, named consistently, with the variants your screens actually call for.
Responsive and Print Notes
How each screen reorders at smaller widths, what collapses, what is hidden, and how anything destined for paper is laid out.
The Session and the Support After It
The package answers the questions we could anticipate. The rest is answered by being available.
A Walkthrough With the Build Team
We take your developers through the screens in the order they will build them, explain the intent behind the awkward parts, and write down the questions raised so the answers exist in a document rather than in somebody's memory.
A Question Channel While the Build Runs
A named person to ask, because the questions that matter arrive at the fourth screen and not on handover day, and a developer who cannot ask will simply decide.
Design Review of the Built Screens
We compare what was built against what was approved and return a specific list — spacing, states, message wording, behaviour — instead of a vague comment that it looks off.
Mid-Build Decisions Recorded
Where something is changed during development, it is written back into the design files, so the design and the product do not begin drifting apart in the first fortnight.
What Shapes a Handover Engagement
Handover effort follows the variety inside the designs more than the number of screens on the list.
- The number of screens, and how many distinct components sit inside them
- Whether the designs are ours, complete and current, or files from elsewhere that must be assessed and completed first
- How many device sizes need documented behaviour rather than a single desktop layout
- Whether the build team is in-house, an outside vendor, or working in a different time zone
- How long build support runs, and whether review of the finished screens is included
- Whether message wording and content rules have to be written or already exist
Before Handover Comes the Design
Handover only works when there is an approved design behind it. Where the screens themselves are still to be decided, start with the wider service.
Frequently asked questions
Can you prepare a handover for designs we did not get from you?
Yes, and it is a common request. We review what you have, tell you honestly what is missing, and agree whether we complete the gaps or only document what exists. Where a design is unfinished rather than merely undocumented, we say so before starting, because documenting an incomplete screen helps nobody.
Our developers say they can read the design file themselves. Why pay for this?
They can read the layout. What they cannot read is what is not drawn: the loading state, the empty list, the error wording, the behaviour when a name is too long. Those get decided anyway — by whoever is building that screen, at the moment they hit it. This work moves those decisions to a point where you can review them cheaply.
Which design tool do you hand over in?
Whatever your team can open and keep using. We normally work in the tool your developers already have access to, and deliver annotated screens, exported assets and a written specification alongside the source file. If your build team has no design tool at all, the specification and assets are prepared so they never have to open one.
What drives the cost of a handover package?
Screen count and component variety first. Twenty screens made of the same eight components is a smaller job than eight screens each built differently. After that: how many device sizes need documenting, whether existing files must be assessed and completed, and how long you want a person available during the build.
How soon after designs are approved can handover happen?
The package is prepared while designs are being finalised rather than starting afterwards, so the gap is short when the designs are ours. For files from elsewhere, an assessment comes first, and that assessment decides the schedule. If a sprint date is fixed, tell us the date and we work backwards from it.
Do we own the handover documentation and the exported assets?
Yes, all of it, with no ongoing licence. The specification, annotated screens, asset exports and the record of decisions are yours, and another developer or agency can pick up the build from them without contacting us. That is the point of writing it down.
What do you need from our development team?
Half a day for the walkthrough, ideally with everyone who will touch the screens present, and the name of the framework and component library they build in so the specification is written in their terms. A single point of contact for questions during the build helps more than anything else, because scattered questions produce scattered answers.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private