The Four Things to Write Down Before You Ask for Quotes

When quotes for the same project come back wildly apart, the cause is almost always the brief rather than the studios.

You do not need to produce a formal RFP. Four things is enough. And writing those four is itself useful, because it forces internal agreement before anyone external is involved.

One, the single most important action

Of everything a user does in this product, what is the most important one. Write one.

"Complete a booking." "Request a quote." "Check progress." That level is fine.

If you cannot narrow it to one, that is the biggest finding in the exercise. A product with no priority order has no basis for deciding what to emphasise on each screen, and the result is a screen where everything is the same size.

From the making side, the presence or absence of this one line changes the quality of what comes back.

Two, what the user does today

Who uses it, and how do they do this work right now.

The second half matters more. If they are not doing it at all, you are building a new habit. If they are doing it in a spreadsheet, you are replacing something. If they are doing it in a competitor's product, you are a switch. Those are three completely different designs.

Write the actual situation, not an idealised user persona. Picturing one real person and writing about them produces a more accurate answer.

Three, the constraints that cannot move

Existing systems, internal rules, mandated technology, brand decisions already made.

Leaving these out means a proposal arrives and then gets thrown away because something in it is not permitted. Constraints are cheapest when stated early.

The commonly forgotten one is your own approval process. How many people review design work, and how long a review round takes. This directly determines the schedule, so stating it makes the duration estimate realistic instead of optimistic.

Four, what has to be working by when

Not "everything by a date". What, by a date.

Writing it that way makes it possible to cut things. Writing "everything" means nothing can be cut until the deadline is close, at which point what gets cut is quality.

The best version of this is to set the first deadline at "the most important action works end to end for one user". Once that exists, the rest can be added.

What not to write

A list of screens. Fixing the screen count first means design starts from the list. The screens you need are an output of deciding what the product does.

Implementation detail. Technology constraints belong in point three. Specifying beyond that suppresses the better proposals.

A long list of reference sites. Two or three is enough. Too many obscures what you actually value. And add one line saying what specifically you like about each, because without the reason it becomes an instruction to copy the appearance.

What changes when you write them

Three things.

The spread between quotes narrows, because everyone is now pricing the same product.

Rework during the project drops, because the decisions were made before work started.

And internal agreement gets settled first. This is the largest effect, and it is the one nobody expects. Writing the four surfaces the places where your own organisation disagrees. Discovering that now is far cheaper than discovering it halfway through an engagement.

When you cannot answer one of them

Say so explicitly rather than filling it in.

A brief that says "we do not currently understand how our users do this today" is honest and actionable. What comes back will include research.

A brief where that gap was papered over gets priced against a wrong assumption, and the wrongness surfaces after work has started.

Writing down what you do not know is not weakness. It is information that makes the estimate more accurate.