FROM A REQUEST TO A WORKING PROJECT
From brief to project handover
Six stages of a digital project: source material, assistant tasks, human decisions, working documents and completed examples.
For clients, project contributors and AI assistants. Start at the stage you need; a complete document set is not required before the first conversation.
Read the full workflow in Markdown ↗Structured information in JSON ↗Blank project summary ↓Complete a summary ↓
How to use these materials
Start at the stage you need. If the task is still unclear, the first stage is enough. You do not need a complete set of documents before making an enquiry.
Give important information a source and date. Separate verified facts, assumptions and open questions. Do not invent missing budgets, deadlines, audience details or performance figures.
Record each document’s status: draft, awaiting approval or approved. Include its author, reviewer, version and date. A written document is not evidence of approval.
An assistant can organise material and prepare options. Authorised people approve the concept, scope, fees, dates, publication, access and legal terms.
Share a link to a document rather than secrets. Keep passwords, tokens, third-party personal data and confidential assets out of public examples. The client decides what may be shared and how.
Six stages with working examples
Agree the stages, documents and handover conditions for the task. CHARGE illustrates how to complete them, not agreed terms or actual results.
Source material and briefWhich business problem needs to be addressed?
- Input
- A conversation, email, voice notes, product description, previous campaigns and brand material. Record what is missing and who can provide it.
- Assistant tasks
- Organise the facts into a short brief. Compare stakeholders’ requests, identify contradictions and record questions. Keep links to the source material; do not present a paraphrase as a verified fact.
- Human decisions
- The client confirms the objective, constraints and people who can approve decisions. The project lead clarifies the boundaries of the first stage and the information needed before selecting a solution.
- When to continue
- The business problem, intended audience action, known constraints and gaps are explicit. If evidence is insufficient, the next output is a set of questions or research, not an invented concept.
- Output
- A brief, a source-material inventory, an open-question log and the next decision.
Working documents
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- Learning draft. A fictional project, not a commission or an approved plan.
- Business need
- Introduce an adult audience to the fictional CHARGE range through a digital project.
- Product premise
- Three citrus flavours: orange, lime and grapefruit. The drink can carries battery-inspired graphics. These are premises for the example, not evidence of an existing product.
- Audience action
- Explore the flavours and try a short game. This is a proposed objective; the suitability of the format still needs testing.
- Available material
- Illustrative packaging images and a three-flavour palette. No audience research, media plan or channel requirements are available.
- Open questions
- Launch date, budget, channels, measurement, approvers and brand restrictions. None is considered agreed.
- Next decision
- Clarify the objective and constraints with the client, then compare ways for the audience to participate.
Idea and conceptWhy does the proposed idea fit the task and the brand?
- Input
- The brief, verified audience information, brand guidelines, past campaign material, available channels and constraints.
- Assistant tasks
- Prepare meaningfully different approaches, not just visual variations. For each option explain its relationship to the objective, audience participation, required assets, limitations and proposed test. Collect references with their sources and rights notes.
- Human decisions
- The client selects an option and approves the key message and visual direction. The team checks feasibility and whether the proposed assets can be used. Record disagreements explicitly.
- When to continue
- The selected option, approver and approval date are recorded. It is clear what the prototype will test and which unanswered questions may still change the decision. Sketches are not presented as finished designs.
- Output
- A concept, the rationale for selection, references, a palette, sketches and a prototype assignment.
Working documents
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- An option for discussion in a fictional project; no client selection has been made.
- Proposed idea
- “Build your charge”: choose a citrus flavour, play a short match-3 round, then see the result and a drink information card.
- Visual direction
- A white drink can with plus, minus and charge-segment graphics. Orange uses orange, lime uses green, and grapefruit uses coral. Fruit shapes and labels supplement colour.
- Message
- “Fresh flavour. Your charge.” is draft campaign copy, not a claim about a physiological effect.
- Alternative to compare
- A non-game flavour selector with a short interactive story. It may be more appropriate if the audience is unwilling to play.
- What to test
- Whether people understand the mechanic and its connection to the product, whether play distracts from exploring flavours, and whether all three flavours are recognisable without an explanation from the author.
- Constraints
- No promise of sales growth, physical rewards or health benefits. Campaign rules and permitted claims still need review.
User journey and prototypeWhat does a participant do, and how does the interface respond?
- Input
- The selected concept, device and channel information, intended next action, accessibility requirements and data constraints.
- Assistant tasks
- Describe the user, their goal and the sequence of screens. For every step specify the action, interface response, error and recovery. Write user stories with testable acceptance criteria. Use the same screen identifiers in the flow diagram and requirements.
- Human decisions
- The client approves the journey and outcome of participation. The designer and developer review controls, states, prototype behaviour and technical constraints. Review the prototype itself, not only its description.
- When to continue
- The main journey can be followed and errors have a recovery route. The experience has a beginning, clear rules, a result and a next action. Undescribed states are recorded as open questions rather than omitted.
- Output
- A user journey, flow diagram, user stories, screen inventory, prototype and test criteria.
Working documents
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- An illustrative scenario. The images are not a working game.
- User and goal
- An adult visitor wants to understand the flavour options quickly and try the mechanic. This is an example hypothesis, not a research finding.
- Screens
- S01: product and three flavours → S02: rules → S03: game board → S04: result and flavour card. From S04, the visitor can replay or return to the flavours.
- Move
- Swap two adjacent pieces. A match of three identical citrus pieces disappears and the charge meter increases. Rules for unsuccessful swaps and move counting need separate agreement.
- Story and criterion
- The visitor wants to understand the result of a move. Check that a valid match produces a visibly changed board, score and remaining-move count. Shape and numbers accompany colour.
- Failure states
- No valid move: show a hint or reshuffle under an agreed rule. Reload: decide in advance whether the round persists. Service unavailable: show a clear message and retain the flavour choice if the requirements provide for it.
- Prototype
- No working prototype link is available. The next step is to build and review it, not to mark the stage complete.
Plan and requirementsWhat will be delivered, who is responsible, and what does launch depend on?
- Input
- An approved concept and journey, estimates from contributors, the campaign calendar, and data and integration requirements.
- Assistant tasks
- Consolidate scope, exclusions, stages, decision owners and dependencies. For integrations describe the data, exchange direction, errors and system owner; do not invent unknown APIs. Record each change separately, including its impact on cost and timing.
- Human decisions
- Authorised participants approve scope, estimates, dates and acceptance criteria. System owners approve interfaces and access. Relevant specialists review contracts, rights and data processing.
- When to continue
- Each task has an output, an owner and a check. External dependencies are named. A media placement date is not evidence that the project will be ready. Unconfirmed estimates remain marked as provisional.
- Output
- Requirements, a dependency-aware schedule, responsibilities, acceptance criteria and a scope-change process.
Working documents
Requirements template ↗Scope change: complete the record ↗Blank template (.md) ↓Learning example (.md) ↓
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- An illustrative plan with no agreed dates or fees.
- Scope
- A landing page, selection of one of three flavours, a game mechanic and a result screen. Physical prizes, accounts and sales are excluded by the example’s premise.
- Dependencies
- Packaging and copy → prototype → designs and rules → development → testing → launch decision. No calendar dates are assigned.
- Campaign
- Advertising should lead only to an accepted working release. Media placement and product release dates are unknown.
- Integration
- No external CRM integration is confirmed. The example does not collect participant identifiers or contact details. If integration is needed, its scope and estimate must be agreed separately.
- Acceptance
- Flavour selection works, valid moves follow the rules, the result is accessible, and the journey is checked on agreed devices. The complete criteria will be prepared with the requirements.
- Change
- Registration or a competition is a separate change requiring an estimate, owners and a review of the rules; it is not added silently.
Development and testingWhat has actually been tested, and what still prevents launch?
- Input
- A release to test, approved requirements, a device list, an available test environment and acceptance criteria.
- Assistant tasks
- Prepare checks mapped to requirements. Record steps, expected and actual results, device, version and evidence. If a check cannot be performed, state that limitation; do not substitute an expected result for an observed one.
- Human decisions
- The contributor checks fixes, the person responsible for quality reviews the evidence, and the client accepts the work under the agreed conditions. An assistant must not declare security, accessibility or readiness verified without the relevant checks.
- When to continue
- Critical requirements have recorded test results. Known defects and untested areas are listed, and an authorised person has explicitly decided whether the remaining issues are acceptable.
- Output
- A test record, defects and limitations, retest evidence, and a readiness decision.
Working documents
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- An illustrative test-record draft. No game checks have been performed.
- Version and environment
- No working game URL is available. Devices and reviewer have not been assigned.
- T01: flavour selection
- Expected: the selected flavour and product card remain consistent across screens. Actual result: not tested.
- T02: match
- Expected: a valid move updates the board, score and meter according to the rules. Actual result: not tested.
- T03: completion
- Expected: when moves run out, the result, replay and product return are available. Actual result: not tested.
- T04: controls
- Expected: hints, focus, keyboard controls and flavour distinctions do not depend on colour alone. Actual result: not tested.
- Decision
- Launch readiness is not established until a working release and test record are available.
Launch and handoverCan the client operate the project after it is handed over?
- Input
- An accepted release, source-file inventory, domain and hosting owners, dependencies and agreed support terms.
- Assistant tasks
- Prepare a file inventory, build and deployment instructions, a resource-and-owner register, and a list of licences and restrictions. Transfer secrets separately through an agreed secure process. Arrange a handover check with the receiving team.
- Human decisions
- The client and supplier confirm the package and actual access. Legal terms for use and rights transfer are approved separately; a file inventory neither replaces a contract nor proves ownership of exclusive rights.
- When to continue
- The receiving team can find the material, build and deploy the project from the instructions. Every resource has a known owner, and support, enquiries, backups and termination arrangements are agreed.
- Output
- A handover package, instructions, a resource-and-licence register, confirmation of receipt and ongoing support terms.
Working documents
Handover: complete the worksheet ↗Blank handover template ↗Hosting and support: complete the checklist ↗Learning example (.md) ↓
Completed example: CHARGE
A fictional project. This is a learning draft, not evidence of delivered work.
- Status
- An illustrative inventory for a future handover, not a certificate of completed work.
- Material
- Game and landing-page source, designs, copy, three-flavour images and rules. Each file needs a version and storage location; none is provided yet.
- Hosting
- The domain, hosting account, payment arrangements, owners and recovery process are not yet defined.
- Rights
- Check the basis for using fonts, graphics, music, code and packaging. The rights transferred are determined by an agreement, not this inventory.
- Receipt check
- The recipient should confirm that the material opens and reproduce a build from the instructions. This check has not been performed.
- Support
- Responsible contacts, term, service hours, included work and termination conditions must be agreed before launch.
- Secrets
- Passwords and keys are excluded from the learning document. Transfer them separately to an authorised recipient.
Complete a project summary
A summary and links to detailed documents, not another technical specification. Fields are blank; unknown answers can remain explicitly unknown.
Completion takes place in your browser. This page does not submit or store your answers. Download the document before leaving; do not rely on the browser retaining it.
Sources and adaptation
Keiss Media working guidance and learning examples. This route reuses the library’s existing brief, concept, requirements, scope-change, handover and hosting resources. Their sources and reuse terms are given on the respective pages. The new journey, planning and test-record templates connect those resources; they are not an official standard or a contract. User stories and acceptance criteria were checked against the GOV.UK Service Manual; the distinction between objectives and hypotheses follows 18F Methods. The examples were written for the fictional CHARGE project.
Rights, contracts and commitments require separate review. These working templates do not replace legal documents.
Version 1.0 · 24 October 2026