What to give a developer with the layout, so they do not invent the screens

The file arrives, the frames look done, and the first question in the build is a screen the file does not contain. No rows. The save failed. The name is longer than the card. The person is not allowed to see this. Someone has to draw those, and if you did not, the developer will. You will meet that drawing at review and say it is not the layout. That review is a redraw you could have avoided with four extra frames and one real example.

This note is for the designer, or for the person at the agency who sends the file on. It is not the marketer's brief and it is not the pack of passwords. It is the picture, and the sentences that stop a developer from inventing the picture. We are on the same side of the client call. The surprise lands on both of us.

1. What the build asks on the first day

A happy path is a necessary frame and a bad specification. The product spends most of its life off that path. The list is empty because the account is new. The request fails because a field was refused. The screen waits because something else is slow. A name, a title or an address overflows the box you sized with two short words. A person without permission still has to land somewhere, even if that somewhere is a plain refusal.

If those frames are missing, they are not "details for later". They are the first questions, because the developer cannot ship the happy path alone without choosing the others in code. Choosing in code means the choice is invisible until review. You then reject it, which is fair, and the calendar moves, which the client feels. Attach the frames and the rejection happens on a still image, where it is cheap.

You do not have to solve the backend. You have to show what the person sees. Empty. Failed. Waiting. Too long. Not allowed. Five frames, next to the happy one, for every screen you actually expect to be built. A screen you do not expect to be built should be marked as a direction, not left in the file looking like a commitment.

• Empty: no rows, a new account, a search with nothing matched.
• Failed: the save did not work, and the person can tell what to fix.
• Waiting: the screen has been asked to do something and has not finished.
• Too long: a name, a title, a price, in the length the product really stores.
• Not allowed: where a person lands when this screen is not for them.

2. Placeholder text hides the break

A block of fake Latin hides the wrap. A CRM card, a cart and a staff directory do not break in the same place. The card breaks on a company name and a note. The cart breaks on a long product title and a currency. The directory breaks on a name that has a patronymic, or on a missing phone. Your frame was sized against "John Smith" and a round price. The product will not be.

Put one anonymised example from the real product in the file. A long name. A missing phone. A price with the currency the store actually charges. You do not need a dump of the database, and you should not paste a customer's private row into a shared design file. You need the row that will make the frame feel tight. If you cannot get a real example, say so, and use the longest values the fields allow. Silence reads as "short text is fine".

Say which parts are real content and which are still chrome. A developer will build the chrome as if it were content, or skip a label you meant as final, depending on how the last file was organised. A note in the margin is enough. "This title is final. This table is an example. This illustration is not supplied." The illustration that is not in the file will otherwise be a rectangle in the product, and you will be asked for the asset on the day of review.

3. Say whether this screen already exists

Many layouts are not new screens. They are a change to a screen people already use: a report, a checkout, a card, a switch between customers. If you do not mark that, the developer has two bad options. Rebuild the screen from your frame and drop behaviour the frame never showed. Or ignore the parts of your frame that do not fit the running page, and surprise you at review.

Write it on the frame. "This is a change to the report people already open." "This is new." Then write what must not be redrawn. The payment step. The way a second company is kept out of the first company's rows. The button that creates the lead. A layout that quietly replaces those is a different project, and the client will hear about it as a delay rather than as a decision you both made.

If you have not seen the running screen, ask for it before you send the file. A screenshot with the real empty state is more useful than another invented hero. You are allowed to change it. You are not served by designing as if it were not there. The developer will be staring at it the whole time.

• Each frame marked "change" or "new".
• A list of what this picture must not replace.
• One screenshot of the screen as it works today, if it works today.
• Directions that are not for this build, labelled as directions.

4. What this file is not

The marketer, or you, still owes the outcome in a sentence: what a person can do that they could not do, and how we will know. That pack, including what not to put in the chat, is what to attach before development starts. Do not bury the outcome inside the design file and assume it will be read. A frame is not an acceptance check.

Access is a different pack again. If the work sits on a client's existing Laravel, the agency owes a place the change can be tried, and a named list of flows that can hurt. That is how an agency hands the project over. Your layout does not replace it. A beautiful file on a product nobody can run except on the live site is how the first mistake meets a customer.

You also do not need to pick the framework, name the query, or decide the queue. If a frame implies a behaviour the product cannot do this month, say what the person should see instead, and let that be a conversation before the estimate. A disabled control with a sentence is a design. A control that looks ready and fails in code is a bug with your name on the review.

5. Review the states you attached, not a single happy screenshot

Agree the walk before the build, so review is not a taste argument. The developer opens the empty screen, the failed save, the long name, the waiting state, and the refusal. You look at those, because you drew them. The happy path is one item on that list, not the meeting.

If a state was intentionally left out, it is a written "not in this build", not a blank. Blanks get filled. A written exclusion gets estimated as later work, which is what you wanted when you cut scope. Bring the anonymised example back at review. If the long name now fits, the frame held. If it does not, you are looking at a real miss, not at a difference of taste about grey.

Keep the client on the same list. They should see the empty account and the failed save, not only the hero. Those are the screens their staff will actually meet. A client who has only seen the happy path will call the empty state a bug. Showing it earlier is part of the handoff, not a courtesy.

• Review walks empty, failed, waiting, too long, and not allowed.
• Anything cut is written down as later, not left blank.
• The anonymised example is on the screen at review, not only in the file.
• The client has seen the empty state before their staff do.

When to bring a developer in before the build

You can add the five frames and one example without anyone else. Ask for a look when the layout sits on a product that already has customers, and you are not sure which of your frames fight a screen people use. That look is cheaper than a review in the last week.

I read a layout against the running product: what the picture is allowed to change, and which states are still missing. Services cover that kind of build on an existing system. Selected work is the same situation, with the result kept next to the operation. If you want that look, message me on LinkedIn. Send the list of states and whether the screen already exists. Leave the client's passwords out.