How to Write a Project Brief for a News Developer (October 2026)

A project brief for a news developer is a one-to-two-page document that states the editorial purpose of a journalism product, the audience it serves, the data and API sources behind it, the pages and features required, the deadline it has to meet, and what is explicitly out of scope.

Most newsroom briefs fail on the same two points. They describe the feature instead of the problem, and they leave the boundaries unstated, so every late idea quietly becomes an unpaid change request. The fix is a document a developer can read in ten minutes and quote a number against. That takes about two hours once you know which inputs matter.

This guide walks through what to gather, how to draft each section, and the errors that cost newsrooms the most time. It is written for editors, product managers and audience staff briefing an in-house developer, a freelance developer or an agency.

What You Need

Gather these before you start writing. Anything you cannot source goes into the brief labelled as an open question, not dressed up as a fact.

The problem or the pitch

One paragraph on what is not working today. What does the reader or reporter currently do, and what does it cost them? A useful test: if you cannot name the current failure, you are describing a feature request, not a problem.

Evidence about the audience

Search queries, session recordings, reader emails, social threads, support tickets, a survey, or the numbers behind last year’s version. Quote the evidence rather than asserting it. “Readers asked three times for a key races hub” beats “readers need this”.

Data sources and access

Name every source, who owns it, the format, how often it updates, and how you will reach it. For a data project, also record provenance: where each record came from, when it was requested, and whether it came from a public records office, an agency response or a scrape. Provenance is the difference between a dataset a newsroom can defend and one a lawyer cannot.

The systems it has to live inside

Your CMS and its supported fields, your hosting, your CDN, your analytics stack, your ad server, your newsletter tooling, any existing component library. A brief that ignores these generates a quote that assumes a greenfield build, and the number will be wrong by a factor of three.

Constraints

Browser and device support, page weight and Core Web Vitals budgets, accessibility standard, privacy rules around reader data, languages, security review, whether it needs to work offline. Constraints are easier to state than to retrofit.

People and decisions

Who approves, who reviews legal or standards, who owns the content afterward, and who the developer reports to. In a newsroom the last one is where briefs go wrong: if the reporter, the audience team and the product manager all answer to the developer directly, nobody is actually in charge.

Timing and hard dates

Not just a launch date. Election day, a filing deadline, a court hearing, an embargo lift, a budget cycle, an event start time. Newsroom deadlines are external and immovable, so they belong in the brief as constraints rather than as goals.

Budget range and capacity

Even a rough band changes the conversation, because it tells a freelancer what shape of build is on the table. Also state who is paying: an existing team with other commitments, or a contracted partner with a calendar you actually control.

Step-by-Step: How to Write a Project Brief for a News Developer

Work through these seven sections in order. Each one answers a question the developer will otherwise have to ask you, and the order stops you from describing solutions before you have agreed on the problem.

1. Start with the newsroom problem, not the feature

Open with the audience problem, who is affected, what the current limitation is, and why it matters now. Then name the question you want the developer to investigate, rather than the answer you want them to build.

Weak: “We need an election results tracker with a swing chart.” Stronger: “On results night, readers land on the live blog and leave because there is no single place showing who won and where. We want to understand whether a persistent results page, updated from the county feed, keeps them on the site and reduces re-entry from search. The developer should propose the smallest version of that and tell us what it would take to be wrong.”

2. Define the audience and intended user journey

State the primary audience, the secondary users, and the contexts. Where do they arrive from, what do they do first, what decision are they trying to make, and where do they get stuck? Name the moments where help is needed.

Keep reader-facing requirements separate from internal ones. Readers need a legible result, a timestamp and a way to share it. The standards desk needs a correction path and a way to see what is live. Mixing them produces a brief that reads as two documents stapled together.

3. State the goal, the scope and the non-goals

Turn the problem into one measurable product goal. Then define what ships in the first release, list the explicit non-goals, and describe a minimum viable version that is genuinely shippable on your hardest date.

The non-goals list is the highest-leverage part of the whole document. “No user accounts in v1”, “no archive migration”, “no custom illustration package”, “no second language”. Every item you write there is an argument you will not have later. Scope creep is rarely malicious; it is usually a reasonable idea that arrived without a boundary to land on.

4. Describe the newsroom workflow and functional requirements

Map the work from editorial input through publishing, updating, review and maintenance. Then cover the requirements that actually decide the estimate: roles and permissions, content fields, editorial states such as draft, in review, live and corrected, search and filtering, alerts, integrations with existing tools, error and empty states, accessibility, performance targets, and reporting.

Write user stories where they help, one per behaviour, in the newsroom’s own language. “As a reporter, I can flag a result as provisional so readers know it may change” is estimable. “Make it look authoritative” is not. Add acceptance criteria as you go, in plain sentences a non-technical editor can check.

5. Document data sources, rights and technical constraints

For each source, list the owner, format, update frequency, licensing and usage conditions, access method, known limitations and a fallback if it fails. Data provenance belongs here, not in a footnote: which record, requested when, obtained how, verified by whom.

Then separate what is known from what is open. Use two lists. The known list carries dates, numbers and named owners. The open list carries everything still being negotiated with a data partner, a legal review or a records office, with the person chasing it and the date they expect an answer. Writing that line in the brief stops a blocked dependency from being rediscovered as a surprise three weeks before launch.

Do the same split for technical constraints. Compatibility, security, privacy, browsers, devices, hosting and existing newsroom systems go in the known column with a named source for each claim.

6. Add examples, acceptance criteria and success measures

Make requirements testable. Annotated examples and edge cases do more work here than adjectives. One good example of an empty state tells a developer more than a paragraph describing the tone.

Then choose a small number of measures and know which kind each one is. Adoption measures count people. Editorial value measures whether the newsroom can do its job better, such as corrections volume or time to publish a live update. Usefulness measures whether readers reached a decision. Reliability measures whether the thing stayed up. Stacking four kinds into one number is how measurement plans die.

7. Close with decisions, owners and next steps

End with the unresolved decisions, who owns each one, the dependencies, deadlines, review cadence, approval authority and the next concrete step, such as a kickoff meeting or a prototype.

Sign-off means something specific: the named person accepts the deliverables against the written acceptance criteria, in writing, by a date. Anything informal is not signed off. A change request then means a written note describing the change, the reason, the new date and who approved it.

Worked example: a filled-in brief for an election results tracker

An abstract section list is easy to agree with and hard to use. Here is the same structure filled in for a results tracker, trimmed to the parts that carry weight.

Problem. On results night, readers land on our live blog from search, find no overall result, and leave. In the last two cycles, 62 percent of results-related search exits happened within 40 seconds of the first pageview. We do not know whether readers stayed because they got their answer or because they gave up, which is the question this project should answer first.

Audience. Primary: casual voters in the four target districts who follow results on a phone, often on mobile data, usually at work or commuting. Secondary: our politics reporters, who need one canonical result to link to instead of restating it.

Goal. Keep a reader on a single results page until they have a district result, and cut the number of live-blog posts that restate results, from roughly 40 per cycle to under 10.

In scope for v1. One results page with a per-district result and margin, a plain-text timestamp and source line on every figure, a projected-turnout caveat where the feed supplies it, share links, and a correction path that updates the visible figure and logs the change.

Out of scope. User accounts and saved districts. Historical archive migration. Local-language versions. A custom illustration set. Any predictive model beyond what the feed already provides.

Functional requirements. States: pre-count, partial count, certified result, corrected. Roles: reporter can flag a figure provisional and can issue a correction; the correction must appear in a visible log rather than overwrite silently, because the standards desk treats silent edits as a problem. Every page needs a fallback state for feed failure, which will happen at some point between 8pm and 11pm.

Non-functional requirements. Interactive render under two seconds on a mid-range Android over 4G. Page weight under 1.5 MB excluding video. Keyboard navigable and screen-reader tested against WCAG 2.2 AA. No third-party scripts on the results page.

Data sources. District feed, owner named, JSON, updates every 60 seconds during counting, licence permits public display and redistribution of derived values, fall back to the reporter-pushed snapshot if the feed is unavailable for more than five minutes. Provenance: figures traced to the district registrar’s published statement, captured and stored at publish time so a correction can name exactly what changed.

Known versus open. Known: feed format, rate limit, licence, performance target. Open: whether certified results arrive before our deadline on the last two districts, and whether the registrar will confirm margins in writing. Both are with the politics desk; answer expected two weeks out.

Hard dates. Polling day, then the first certified result. No internal soft launch. The plan assumes the buffer gets eaten, which it usually does.

Acceptance criteria. A reader on a mid-range Android sees a district result within two seconds at a 4G connection; every figure on the page shows a source and a timestamp; a correction issued by a reporter appears in the visible log within 60 seconds without a page reload; feed outage for five minutes shows the fallback state with a reader-visible note.

Success measures. Usefulness: median time from landing to reaching a district result. Adoption: returning visitors to the results page. Reliability: feed-outage fallbacks triggered and their duration. Editorial value: live-blog posts restating results. Four kinds, four owners, reviewed after the cycle.

Note what is absent. No wireframes, no framework, no component choice. Those are the developer’s, and keeping them out is what lets two developers quote the same project at similar numbers.

How to hand the brief over without losing control

Send the document, then walk through it in one meeting rather than three. The goal of that meeting is not to sell the idea. It is to hear the questions a developer would otherwise send by email over a week, and to agree who answers the ones you cannot.

Before the meeting, decide the three things you are least willing to trade. Those are your fixed points, and saying so early saves everyone from discovering them at sign-off.

What to expect back: an estimate broken into phases, a list of assumptions the estimate rests on, and a list of questions. Read the assumptions line by line. That list is where a scope document quietly becomes a scope negotiation, and it is the last cheap moment to correct an assumption before work starts.

Then agree the review rhythm in writing. A weekly 20 minutes is plenty for most newsroom projects; election-driven builds want a standing daily slot for the final fortnight. Fix a named approver and a named deputy, and put a date on every open question you take away.

The brief quality test: could a developer quote a number?

A section is finished when a developer can turn it into hours or a yes-or-no answer. “Fast”, “modern”, “simple” and “intuitive” cost nothing to write and nothing to estimate. “Results page renders in under two seconds on a mid-range Android over 4G, with a maximum page weight of 1.5 MB excluding video” can be built against. If a line cannot be turned into hours or a yes-or-no, rewrite it.

Common Mistakes and How to Fix Them

These nine errors account for most of the time newsrooms lose to development. Each one has a fix that costs ten minutes while you are drafting, which is far cheaper than fixing it during testing.

Common briefing errors and how to fix them

Starting with the feature

A brief that opens with “build a map explorer” has already chosen the answer, and the developer can only price it. Fix: state the reader failure first and ask for the smallest thing that addresses it.

Vague audience language

“For our users” tells a developer nothing about devices, context or motivation. Fix: name one segment and one situation, then say how you know it is representative.

Scope with no boundary

Everything in the brief is in scope, which means nothing is protected. Fix: write the non-goals list before the requirements list, and put it where people will read it.

Assumptions presented as facts

“The API will be fast” is an assumption wearing a fact’s clothes. Fix: label it, name who is confirming it and by when.

No edge cases

Briefs describe the happy path and then discover the unhappy one during testing. Fix: name at least the empty, error, stale-data and long-name cases for every screen.

Accessibility as a closing line

“Make it accessible” is not a requirement. Fix: state the standard you are held to, the keyboard and screen-reader behaviours that matter, and who tests it.

Unstated data rights

A dataset that cannot legally be republished is a launch-stopping surprise. Fix: write the licence or usage terms into the brief, or state that they are unconfirmed and name who is checking.

Goals and tasks mixed together

“Increase newsletter signups by adding a modal” collapses an outcome and a solution into one sentence, so neither can be judged. Fix: one goal, then the requirements that might reach it.

No acceptance criteria

Without them, “done” is a matter of opinion and the review turns personal. Fix: one checkable sentence per requirement, written so an editor who did not build it can verify it.

Nobody owns the decision

Three stakeholders, three priorities, no tie-breaker. Fix: name the approver, their deputy, and how a disagreement gets resolved before it stalls a sprint.

A copy-paste brief skeleton

Fill these in. Keep the structure, cut what genuinely does not apply, and do not leave a field blank without saying why.

Project name and one-line description.
Problem. What fails today, for whom, and the evidence.

Primary audience and context. Who they are and where they are when they need this.

Goal. One measurable outcome, with the date it should be true by.

In scope for v1. Pages, features, states, and what ships on day one.

Out of scope. Explicitly listed, with the reason if there is one.

Minimum viable version. The smallest thing that still answers the problem.

Functional requirements. Roles, fields, states, search, alerts, integrations, error states.

Non-functional requirements. Performance budget, accessibility standard, browsers, devices, security, privacy, languages.

Data sources. For each: owner, format, update frequency, licence, access method, fallback, provenance note.

Known facts versus open questions. Two lists, each open question with an owner and an expected answer date.

Hard dates. Election day, filing date, embargo lift, event start.

Review gates. Standards, legal, security, accessibility, with who signs each.

Acceptance criteria. One checkable sentence per requirement.

Success measures. A few, labelled by type: adoption, editorial value, usefulness, reliability.

Roles. Owner, approver, developer contact, content maintainer.

Change process. How a change is requested, priced in time, and approved.

A length check that has served me well: if the brief runs past two pages of body text, the extra pages are usually open questions wearing a requirement’s clothes. Move them into the open list.

Frequently Asked Questions

Start with the problem paragraph and the non-goals list. Everything else in the brief can be assembled in an hour once those two are written, and they are the two that decide whether a developer sends back an estimate or a list of questions. Written for 2026, and worth revisiting after each project: the sections you ended up rewriting are usually the ones the next brief needs.