How to brief a digital project without knowing the technology

Describe today

What exists now? What is slow, broken, confusing, manual or missing? Include links, screenshots, files or a quick process description.

Describe done

What should a person be able to do when the work is complete? Define a useful observable result rather than a vague goal such as “modernise the system”.

List constraints

Budget, deadline, existing platform, required integrations, legal restrictions, internal approvals and available skills can all change the correct solution.

Separate first release from future ideas

Mark must-haves, useful extras and later ideas. This protects the smallest valuable version from becoming buried under everything the project might one day do.

Turn the guidance into a working plan

Treat how to brief a digital project without knowing the technology as a defined improvement, not an open-ended activity. Write down the current situation, the customer or operational problem, the smallest useful outcome and the evidence that would show progress. Keep the first pass narrow enough that one person can own it and another person can review it.

Use this practical sequence as the acceptance check: Current problem; Definition of done; Users; Must-haves; Constraints; Assets/access; Approver; Future ideas separated. Record what already exists before changing it, then make the highest-value correction first. If the work depends on a platform, provider or external account, identify access and backup requirements before the change window rather than discovering them during implementation.

A realistic small-business example

A business asking for ‘an app’ may really need staff to stop copying enquiry details between a form, spreadsheet and email template. A good brief describes that current workflow, the people involved, the mistakes or delays and the required outcome. Technology options can then be compared against the real job. The smallest useful solution might be an integration, an internal tool or a changed process rather than a standalone app.

Review the result and keep it useful

Review the work against the reader's decision, not only grammar and tone. Confirm that claims are supported, examples are relevant, limitations are visible and the next action is clear. Ask someone close to the intended audience to explain what they think the page or document means; misunderstandings are better evidence than internal preference debates.

Keep the source, date and owner of changing facts. Schedule a review when prices, services, legislation, platform behaviour or cited evidence changes. Useful content can often be updated in place; publishing a new near-duplicate every time creates confusion for readers and leaves the business maintaining several versions of the same answer.