A clear crowdsourcing brief gives contributors the context, boundaries, and motivation they need to produce useful work. This guide explains how to turn a broad request into a focused project that is easier to join, manage, and evaluate.
1. Start with a specific outcome
The first job of a brief is to explain what the project must achieve. “We need ideas from the community” is too vague because contributors cannot tell which ideas are relevant, how many you need, or what will happen afterward.
Write the desired outcome as a practical result. For example:
- “Collect 50 realistic ideas for reducing food waste in small restaurants.”
- “Find five volunteer-tested translations of our emergency-preparedness checklist.”
- “Gather photographs that show how commuters use our new bike-storage system.”
- “Identify recurring problems in the first-time customer onboarding process.”
A strong outcome normally includes an action and a useful deliverable. It may also include a quantity, deadline, location, audience, or quality requirement. You do not need to know every detail at the beginning, but contributors should understand what success looks like.
Use this sentence as a starting point:
We are asking [type of contributors] to create or provide [specific deliverable] so that [organization or audience] can [intended use] by [deadline or project stage].
Avoid promising that every contribution will be adopted. If the project is exploratory, say that the results will inform a decision, shortlist, prototype, report, or future campaign.
2. Define the problem and its boundaries
People submit better work when they understand the problem behind the request. Give enough background to establish relevance, but do not bury the brief in organizational history.
Explain:
- What situation led to the project
- Who experiences the problem
- Why the issue matters now
- What has already been tried
- What constraints contributors must respect
- What is explicitly outside the scope
For example, a brief about improving a public website might state that visitors struggle to find permit information on mobile devices. It could explain that the team is looking for navigation and content ideas, not a complete redesign or legal advice.
Boundaries protect both sides. They reduce unsuitable submissions and prevent contributors from spending time on work that cannot be used. Include restrictions such as budget, technology, geography, age range, accessibility requirements, brand rules, safety rules, or data-protection limitations.
Be honest about fixed decisions. If the project must use an existing platform, say so. If the budget cannot change, do not ask contributors to propose solutions that require expensive new infrastructure.
3. Describe the ideal contributor without excluding useful people
A crowdsourcing project can be open to everyone while still describing the perspectives that would be especially valuable. Identify the experience, knowledge, location, language, or lived perspective that would help.
You might invite:
- Existing customers who have completed a particular task
- Professionals with relevant technical experience
- Residents of a specific area
- Students, caregivers, hobbyists, or volunteers
- People who have encountered the problem personally
- Contributors who can provide examples in a particular language
Distinguish between requirements and preferences. A requirement is necessary to participate, such as being over a certain age or having used a service. A preference is helpful but not essential, such as familiarity with a particular design tool.
Do not make the audience description so narrow that valuable outsiders assume they are unwelcome. If first-hand experience matters most, say that clearly. If professional credentials are not needed, say that too.
4. Turn the request into clear tasks
A contributor should be able to read the brief and know exactly what to do next. Break a large assignment into steps and specify the expected format for each response.
For an idea-gathering project, the instructions might be:
- Choose one problem from the list provided.
- Describe the current situation in no more than 150 words.
- Propose one solution.
- Explain who would benefit.
- List the main cost, risk, or implementation obstacle.
- Attach an example, sketch, link, or photograph if useful.
Specify whether people may submit multiple entries, collaborate, revise their work, or comment on other submissions. Clarify whether short answers are welcome or whether detailed evidence is expected.
Use plain verbs such as “describe,” “rank,” “upload,” “compare,” and “explain.” Replace unclear language such as “provide innovative insights” with a concrete prompt such as “suggest one approach that could be tested within four weeks and a modest budget.”
If contributors must answer several questions, number them and keep the order consistent. A template reduces missing information and makes later review much faster.
5. Set the submission format and quality standard
The brief should remove avoidable uncertainty about how work is submitted. Include the accepted file types, word limits, dimensions, naming rules, language, and platform instructions.
Consider stating:
- Maximum length for written responses
- Maximum file size
- Accepted image, audio, video, or document formats
- Whether links must be publicly accessible
- Whether names, contact details, or biographies are required
- Whether anonymous submissions are allowed
- Whether machine-generated or assisted content must be disclosed
- Whether sources or permission records must be included
Define quality in observable terms. “High quality” is not enough. A useful entry might need to be specific, understandable, feasible, original, evidence-based, respectful, or relevant to a target audience.
A compact evaluation table can help contributors self-check before submitting:
| Criterion | What a strong submission shows | Common weakness |
|---|---|---|
| Relevance | Directly addresses the stated problem | Discusses a related but different issue |
| Clarity | Uses concrete examples and readable language | Relies on vague claims or jargon |
| Feasibility | Fits the stated resources and constraints | Requires unavailable time, money, or access |
| Usefulness | Provides information the team can act on | Offers a general opinion without detail |
| Responsibility | Respects safety, privacy, and permissions | Includes sensitive data or uncredited material |
If the project values one criterion more than another, say so. Contributors should not have to guess whether novelty matters more than practicality.
6. Explain timing, stages, and communication
Include every important date in one place. If there is only one deadline, label it clearly. If the project has stages, list them in order:
- Brief published: March 4
- Questions accepted until: March 10
- Submission deadline: March 18
- Review period: March 19–29
- Selected contributors contacted: April 2
- Results or next steps shared: April 12
Use the time zone for online projects and specify whether the deadline ends at the beginning or end of the stated day. If deadlines may change, explain how participants will be notified.
Tell contributors how questions should be asked and when they can expect a response. A public question-and-answer page can prevent the same clarification from being repeated. If private information may be involved, provide a private contact route instead.
Do not promise individual feedback if the team cannot provide it. You can state that selected entries will receive detailed feedback while other contributors will receive a general update.
7. Make incentives and recognition transparent
Incentives may include payment, prizes, gift cards, professional exposure, access to research findings, certificates, portfolio credit, or the opportunity to influence a product or decision. Describe the incentive accurately and explain who qualifies.
Clarify:
- The amount or approximate value
- Whether payment is per submission, per selected entry, or shared among winners
- The number of awards available
- Eligibility restrictions
- When and how payment will be made
- Whether taxes, fees, or currency conversion affect the amount
- What happens if no submission meets the requirements
Recognition also needs permission. State whether names, usernames, photographs, or links will be published. Allow contributors to choose a display name where appropriate.
An incentive should support participation without disguising the real effort involved. If the task requires research, editing, photography, coding, or repeated revisions, describe that workload honestly. If the project is unpaid, explain the nonfinancial reason to participate and make the expected time commitment visible.
8. Cover ownership, permissions, privacy, and safety
Contributors need to know what happens to their work after submission. The brief should link to or summarize the relevant terms in plain language.
Address:
- Whether contributors keep ownership of their work
- What license or permission the organization receives
- Whether the permission is exclusive or nonexclusive
- Where the work may be published or adapted
- Whether contributors will be credited
- How long submissions will be retained
- How personal information will be handled
- Whether submitted material can be withdrawn
Do not request personal information that is unnecessary for the project. Warn people not to include private customer records, medical details, passwords, financial information, children’s images without proper permission, or confidential workplace material.
For photographs, interviews, recordings, and case studies, explain whose consent is required. For location-based projects, mention whether exact addresses or identifying details should be removed.
If legal terms are complicated, have the appropriate person review them before publication. A simple brief cannot replace formal terms where rights, payment, regulated information, or safety risks are significant.
9. Design a fair review process
A review process is more credible when contributors can understand how decisions will be made. Name the review stages, the decision-makers or panel type, and the criteria that matter most.
For example, submissions may first be checked for eligibility, then scored for relevance, clarity, feasibility, and potential impact. A shortlisting panel may select finalists, followed by a practical test or community vote. Explain whether a public vote is advisory or decisive.
Watch for conflicts of interest. Reviewers should not score work from close colleagues, direct competitors, or family members without disclosure and a replacement process.
If you expect a large number of entries, prepare a consistent scoring sheet. Record reasons for rejection using categories such as incomplete, outside scope, duplicate, unsafe, or not feasible. This improves consistency and makes it easier to answer questions without making unsupported claims.
Avoid implying that the highest-scoring idea will definitely be implemented. Implementation may depend on later testing, funding, approvals, technical feasibility, or community response.
10. Test the brief before publishing
Ask someone unfamiliar with the project to read the brief and answer five questions without help:
- What is the project trying to achieve?
- Who is eligible to participate?
- What exactly must be submitted?
- When and where is it due?
- How will entries be evaluated and used?
If the reader cannot answer quickly, revise the brief. Pay particular attention to words that have multiple meanings, missing file requirements, conflicting dates, and instructions hidden in long paragraphs.
A small pilot can reveal problems before the main launch. Invite a few representative contributors to complete the task, then note where they hesitate, ask repeated questions, or interpret the prompt differently. Use the pilot to improve the instructions; do not quietly change the rules for already-submitted work.
Troubleshooting common brief problems
You receive many irrelevant submissions. Narrow the outcome, add examples and nonexamples, and move eligibility requirements near the top. Recheck whether the headline promises something broader than the actual task.
You receive very few submissions. Reduce unnecessary requirements, shorten the form, extend the deadline, improve the explanation of the incentive, or recruit through communities that already contain the relevant contributors.
Submissions are too shallow. Ask for a specific example, evidence, explanation of trade-offs, or a required template. State the approximate time needed so participants understand the expected depth.
Contributors ask the same questions repeatedly. Create a visible FAQ, update the brief, and send the clarification to everyone. If the answer changes the task materially, announce the change and consider extending the deadline.
Entries are difficult to compare. Standardize questions, limits, and formats. Use a scoring rubric and separate eligibility screening from quality scoring.
The project produces ideas that cannot be used. Include real constraints earlier and ask contributors to explain cost, risks, dependencies, and a first test. Consider separating idea generation from feasibility assessment.
People worry about losing control of their work. Explain rights and permissions before submission, use plain language, and avoid requesting broader rights than the project needs.
A reusable crowdsourcing brief structure
You can adapt this order for most projects:
- Project title and one-sentence invitation
- Desired outcome
- Problem background
- Who should participate
- Task instructions and response template
- Scope, constraints, and examples
- Submission format and deadline
- Incentives and recognition
- Review criteria and selection process
- Ownership, privacy, and safety terms
- Contact method and frequently asked questions
Keep the most important information near the beginning and link to detailed policies where necessary. Before publishing, check every date, contact address, attachment, form field, and link. A brief succeeds when a suitable contributor can understand the opportunity, complete the task correctly, and make an informed decision about participation.