A design request arrives with almost everything missing. "Can someone do a banner for the webinar, by Thursday." The designer now has to find out where the banner goes, what size it has to be, what it should say, whose logo is involved, whether the copy is final, and who is allowed to approve it. That is six questions, sent one at a time over a day and a half, and the Thursday deadline has already eaten most of its slack before any design work starts.
A design request form exists to collect those six answers once. The point is not process for its own sake. The point is that a designer reading a completed brief can start, and a designer reading a one line request cannot. What follows is the field list, why each field is there, and what to do with the requests after they arrive, which is the part that decides whether the form gets used a second time.
The four answers that requests usually lack
Templates for creative briefs tend to be long, and length is not what makes them work. Almost every returned round of questions comes down to one of four gaps.
Where the finished thing goes. A banner for a conference stand, a banner for an email header, and a banner for a paid social placement are three unrelated jobs with different dimensions, different text limits, and different file formats. Asking for the destination gets the specifications for free, because the destination determines them.
Who it is talking to, and what they should do next. The purpose question is often answered as "to promote the webinar", which tells a designer nothing about hierarchy. What the viewer should do, and who the viewer is, decides what goes largest.
Whether the words are final. Design built around draft copy gets rebuilt when the copy changes length, and copy almost always changes length. A single yes or no field here saves more rework than any other question on the form.
Who signs it off. Not who asked. The request that comes back after delivery with a stakeholder nobody mentioned is the most expensive failure in the whole flow, and it is prevented by one required field naming the approver.
Everything else on a design request form is useful. These four are what separate a brief that can be worked from a brief that generates a thread.
The fields that remove a round of questions
Destination and specifications
Ask for the destination as a fixed list rather than free text: website page, email, printed material, presentation slide, social post, event display, document template, other. Then let the answer drive the follow up questions. A print answer needs bleed, finished size and whether a proof is required. A social answer needs the platform and the placement. A web answer needs whether a mobile variant is part of the job.
Where a requester genuinely does not know the specification, that is worth knowing too. An "unsure" option on a dimensions field routes the request to a short conversation instead of producing a confidently wrong number that gets discovered at the end.
Message, audience and the one action
Three short questions. Who sees this, what should they understand within two seconds, and what should they do. Keeping the last one to a single action is the useful constraint. Requests that list three equally important calls to action are describing a layout problem that the requester has not resolved yet, and it is cheaper to resolve it in the form than in the third review round.
Copy, and whether it is final
Ask for the text as it should appear, in a long text field, plus a yes or no on whether it is final and signed off. Where it is not final, ask when it will be. A brief with placeholder copy and a known date is workable. A brief with placeholder copy and no date is not a brief.
Existing material
Ask for whatever exists already: brand guidelines, logo files, photography, the previous version of the same thing, the deck the slide has to sit inside. File upload rather than links, because links to a shared drive expire, move, or turn out to be restricted. Uploads that sit behind a sign in are also the safer place for anything unreleased, which covers most launch material.
The approver and the deadline
Name the approver, and ask what the deadline is attached to. A date tied to a live event is fixed. A date tied to nothing in particular is a preference, and knowing which is which is how a designer sequences four requests that all say Thursday.
Rounds
State on the form how many review rounds are included, and ask the requester to confirm they can gather feedback within the stated window. Two rounds is the common arrangement. Writing it on the intake form is what makes the fifth round a conversation rather than a surprise.
The template, written out
Rebuild this in any form tool, with conditional questions where they are marked. Around fifteen questions is the working limit.
Requester
- Name. Short text. Required.
- Email. Email. Required.
- Team. Multiple choice. Required.
- Who approves the finished work. Short text. Required.
What is being asked for
- Type of work. Multiple choice: image for web, email graphic, printed item, presentation slide, social post, event display, document or template, other. Required.
- Where exactly it will appear. Short text. Required.
- Dimensions or format, if known. Short text, with an unsure option.
- How many variants or sizes are needed. Number.
The brief
- Who is the audience. Short text. Required.
- What should they understand immediately. Long text. Required.
- What should they do. Short text. Required.
- Text as it should appear. Long text. Required.
- Is the text final and approved. Yes or no. Required.
- If not final, when will it be. Date.
Material
- Logos, brand guidelines, photography, previous versions. File upload.
- Anything to avoid, such as a colour, a competitor reference, or last year's layout. Long text.
- Examples of what good looks like. Long text or file upload.
Timing
- Needed by. Date. Required.
- What fixes that date. Short text. Required.
- Is a rough version useful before the final. Yes or no.
Recorded by the design team, not shown to the requester
- Assigned designer.
- Stage.
- Estimated hours.
- Round count.
- Link to the working file.
That last block is why a document template on a shared drive stops being enough at around ten requests a month. The team writes as much onto the record as the requester does, and most of it is not the requester's business.
One form, or one form per type of work
The instinct is to build a separate form for each kind of request, because a print job and a slide have little in common. In practice three arrangements exist, and they fail differently.
| Arrangement | What the requester experiences | What the team gets | Where it fails |
|---|---|---|---|
| One general form, free text | Fast to submit, easy to under specify | One list, but briefs of wildly varying quality | Every second request needs a round of questions, which is the original problem |
| A separate form per type of work | Has to choose correctly before starting | Precise fields per type | Requesters pick the wrong form, and the queue is split across several lists |
| One form with conditional questions | Answers a type question, then sees only what applies | One list, with type specific detail | Needs a tool that supports conditional questions, and takes an afternoon to set up |
The third is the arrangement most teams end up with, and the deciding factor is usually the second column of the third row: one list. Splitting intake across five forms means five places to look, five sets of notifications, and no way to see the real workload at a glance. If separate forms are unavoidable, the minimum requirement is that their responses land in the same view, with the same stages, so the queue can still be read in one place.
Copy is what holds the queue up
Across most design queues, the largest single cause of delay is not design time. It is waiting for final text, and it is worth handling explicitly rather than hoping.
Three arrangements help. Make the copy field required, so nothing can be submitted without at least draft words, which forces the requester to think about length. Add the final or not final flag, and use it as the trigger for a stage called waiting on copy, so the request visibly sits with the requester rather than looking like a design backlog. Then set a rule for what happens when copy arrives longer than what was submitted: a substantial rewrite after layout is a new round, not a correction.
None of that is a scheduling trick. It moves the wait into the open, which changes behaviour on the requesting side within a couple of weeks. The handling features that make it possible are unremarkable: a stage per response that the team can rename, an owner, and internal fields the requester never sees.
Review rounds, and where the comments live
Feedback scattered across three channels is the second reliable source of rework. One person replies in the chat thread, another marks up a screenshot in an email, a third mentions something in a meeting. The designer then has to reconcile comments that contradict each other, and often has to guess which one carries the most weight.
Two rules cover most of it. All feedback goes to the request record, and the named approver is responsible for reconciling internal disagreement before it gets there. That second rule is the one that saves the time, because it moves the argument to the side of the fence where the argument belongs.
Keeping the sent version attached to the request matters as well. When the reply, the attached files and the comments all sit on the same record, the question of which version was approved has an answer that does not depend on anybody's inbox. Teams running several intake streams tend to settle on the same arrangement, and the patterns look alike whether the incoming work is design requests, support tickets or applications.
What the queue looks like from the design side
A request list is only useful if it answers four questions without anybody being asked: what is waiting to be started, what is in progress and with whom, what is waiting on the requester, and what is due this week. That means a stage, an owner, a date, and a filter. Nothing more elaborate is needed at typical volumes.
The value shows up in the conversation about capacity. A design team that can say twenty three open requests, nine of them waiting on copy from three teams, has a different conversation with management than one that says it feels busy. The numbers come out of the same intake records, exported as a CSV, provided every request went through the same form.
What to change first
Make the copy field and the approver field required on whatever form is in use now, because those two remove most of the clarifying questions on their own. Then give every request a stage and an owner, so waiting on copy stops being invisible. If the current form cannot hold a stage or an owner, see what that looks like on the response itself in a tool built for it, such as Halict.
Q1. What is the difference between a design request form and a creative brief?
The request form is the intake, filled in by whoever wants the work. The brief is what the design team produces from it, sometimes after a short conversation, and it includes decisions the requester is not expected to make. A well built request form collects enough that the brief is a review rather than an interview.
Q2. Should requesters be allowed to specify how it should look?
Yes, as references rather than instructions. A field for examples of what good looks like is genuinely useful, because it reveals expectations that no amount of describing would surface. Treat it as information about the requester, not as a specification to follow.
Q3. How do you handle urgent design requests?
Name one person who can accept work outside the normal queue, cap how many such requests they may accept in a month, and require the same form afterwards. Without the cap the urgent route becomes the only route, and the queue stops reflecting what the team is actually doing.
Q4. How many review rounds should be included?
Two is the common arrangement, with a third billed or scheduled separately. What matters more than the number is stating it on the intake form, so a request for a fourth round is a known conversation rather than an argument about expectations nobody wrote down.
Q5. Is a form worth it for a team of one designer?
At more than about five requests a week, yes, and the reason is not efficiency but visibility. A single list with stages is what lets one designer show where the time goes, and it is the only defence against a workload that looks like nothing from the outside.