Graphic Design Request Form Template
A designer can work with almost any constraint except vagueness. The brief that says make it pop and arrives without dimensions, copy, or brand files doesn’t get designed — it gets interrogated: three emails, two chat pings, and a day of delay before the first draft, then another round when the draft turns out to be the wrong shape for the platform it was destined for. The revision loop that creative teams dread isn’t caused by bad designers. It’s caused by briefs that omitted the details the work depended on.
This graphic design request form template intercepts that omission at the source. It asks for the production specifics per medium, attaches the assets at intake, and forces the deadline conversation before the queue absorbs the work. The designer opens the brief and starts — because everything the first draft needed arrived with the request.
Specs That Follow the Medium
A banner and a business card are different questions, so the form asks differently: the project type is chosen first from a dropdown — social, print, digital ad, packaging, web — and the spec fields follow the choice:
- Print reveals bleed and trim, paper stock, and finish on structured fields.
- Social and digital reveal platform, dimensions, safe zones, and file weight limits.
- Web and product reveal breakpoints, dark-mode variants, and the handoff format the developers need.
The mechanism is conditional logic in service of accuracy: requesters see only the specifications their medium demands, so the brief is short and complete — the combination emails never achieve. Where dimensions are precise numbers, numeric fields and short text capture them unambiguously; no more you know, the usual banner size.
Assets at Intake, Not in a Chase
The file upload is the form’s second engine. Brand guidelines, logo vectors, fonts, product shots, the copy document, the reference inspiration — each attaches to the brief itself, living beside the specs rather than scattered across the chat thread where the last project’s files went to die. A yes/no question on whether brand guidelines exist, with the upload revealed when they do, keeps the form lean for quick jobs while making asset submission unavoidable for branded ones. The one-file-per-upload pattern also solves the designer’s recurring archaeology problem: six months later, everything that produced a given asset is findable in the response view under the brief that commissioned it.
The Brief Review
Structure the form’s closing fields around what a reviewer — art director, traffic manager, or the designer themselves — needs to accept the work into the queue: a long text field for the objective (what is this asset for, and what should it make the viewer do?), the target date field, and a priority dropdown calibrated to your team’s actual vocabulary. The objective field is the quiet quality control: briefs that can’t articulate what the asset should achieve get sent back to mature before they consume design hours — and the form gives the reviewer a documented, polite basis for doing so.
Where the queue feeds project tooling, a webhook delivers each brief onward automatically; where the team coordinates in shared workspaces, brief visibility follows role permissions so requesters see their own briefs and the studio sees everything.
After Launch: the Archive That Improves Briefs
The response archive compounds into something request-form emails never become: a pattern library. Read quarterly, it shows which request types recur (build a template for them), which briefs spawned revision loops (find the missing field), and which requesters chronically under-brief (invite them to the intake’s intro). The form stops being paperwork and becomes the studio’s memory.
The template sits in the request templates sub-category, alongside web-design requests for the development-adjacent work.
Frequently Asked Questions
How do we stop requesters from skipping the spec fields?
Make the critical ones required — dimensions, deadline, objective — so the form physically cannot submit without them. The conditional design helps too: because spec fields only appear for the chosen medium, they read as relevant rather than bureaucratic, and relevant fields get filled. A request that can’t specify its output size isn’t ready to be a request.
What if the requester genuinely doesn't know the specs?
That’s a routing answer, not a form failure: a help me decide option on the project-type field, and a note that the studio will confirm specs in a five-minute intake call. The brief still captures what the requester does know — objective, audience, deadline — and the specs conversation happens once, recorded, instead of scattered across a week of messages.
Should reference inspiration be encouraged or banned?
Encouraged, with one instruction: show us what you like about it. A reference without a stated quality is a mood board, which is fine, but a reference with we want this energy but with our palette is direction — and direction is what prevents the first draft from missing. The upload field plus one line of commentary is the strongest revision-preventer on the form.
How does this handle recurring assets like monthly social kits?
What's the right number of questions?
Twelve to sixteen, of which half are conditional and invisible for any given request. The visible burden for a simple social graphic should be six or seven fields — type, platform, size, copy source, deadline, objective — completed in under three minutes. If a routine request takes longer to brief than to design, the form is auditioning as the villain.