What Should Website Discovery Produce Before Development Starts?

What Should Website Discovery Produce Before Development Starts? is easiest to manage when the project team can see the decision it needs to make, the evidence already available and the work that remains uncertain. Discovery is useful when it turns a proposed solution into a decision about a real user problem, the evidence needed to understand it and the constraints that might change the answer. This guide is for South African businesses commissioning or coordinating development work. It provides planning guidance rather than contractual, legal or financial advice, and it does not assume that an unseen website or team has already completed any of the activities described.

The factual boundaries in this article are informed by How the discovery phase works, Service Standard, Governance principles for agile service delivery. These sources describe general delivery, governance, service and documentation principles; they do not prove the capabilities, staffing, price, timeline or outcome of a particular supplier or project.

Start with the decision, not the document

Before asking for a new worksheet, meeting or status label, state the decision the team must make. In this case, the decision is connected to what should website discovery produce before development starts?. A useful statement names the affected business or user task, the current condition and the evidence that would make one option preferable to another. If the request is still a preferred solution rather than a defined problem, keep that distinction visible.

The discovery guidance says a team should understand the problem, users, constraints and opportunities before committing to build. That principle is useful beyond discovery: each later project gate should make the next commitment easier to explain. A page titled “approved” is not evidence by itself. The team should be able to identify what was approved and what remains open.

Write the decision in plain language, then list the consequences of each answer. If the answer is “continue”, what work becomes ready? If the answer is “defer”, what evidence is missing? If the answer is “do not proceed”, what alternative will address the need? This prevents a process artefact from becoming a substitute for judgement.

Separate evidence, assumptions and constraints

Create three columns in the project record. Evidence is something the team can inspect, such as an approved content file, an observed workflow, a confirmed provider requirement or a test result. An assumption is a statement that still needs checking. A constraint is a condition that affects the choices available, such as an existing process, access boundary, supplier dependency or approved deadline.

The GOV.UK governance guidance recommends evidence-based decisions, clear boundaries and owned risks. The context is public-service delivery, so it is not a contract for a South African commercial project. The transferable lesson is the discipline of making authority, evidence and escalation explicit.

Avoid filling empty cells with plausible details. If the content owner has not supplied final copy, write “awaiting approved content” rather than drafting a fictional example and treating it as ready. If a supplier has not confirmed an integration requirement, write “provider confirmation required”. This makes the unresolved work visible and protects later estimates from false certainty.

For each constraint, add a consequence and a next action. A missing login may block a particular test but not all design review. An unresolved approval route may block release even if the build itself is complete. The register should show that difference.

Define ownership and the review route

A project record needs more than a list of names. For each decision, assign who supplies the evidence, who reviews it, who has authority to approve it and who must be informed. One person can hold more than one role, but the roles should not be implied. This is especially important when a marketing manager, operations lead, supplier and developer each see a different part of the workflow.

The agile tools guidance describes backlogs, team reviews and visible work records as ways to communicate, plan and improve. A business website does not need to copy a government delivery ceremony, but it benefits from the same transparency: show what was completed, what is being reviewed and where a dependency needs attention.

Set a response path for disagreement. First compare the report with the approved requirement or observed behaviour. Then identify the decision owner. If the evidence is incomplete, create a short investigation rather than allowing the loudest participant to define the result. Record the decision and its effect on dependent work.

Also agree how absence is handled. A named approver may be unavailable, a supplier may not respond or the data owner may change. Do not assume that silence is approval. Record the substitute route or the condition under which the decision must wait.

Apply the method to this project question

Define decisions discovery must resolve; identify evidence and constraints; document open questions; assess readiness to commit. The practical way to apply this is to turn each part into a small reviewable record. Start with the current state, then state the required outcome, then identify the evidence and owner. Keep commercial terms, legal responsibilities and technical implementation choices separate unless the approved project record connects them.

For what should website discovery produce before development starts?, ask whether the proposed answer changes a user-facing workflow, a staff responsibility, a content dependency, an integration, a release decision or ongoing support. The answer determines who needs to review it. It also determines which evidence is meaningful. A screenshot may help explain presentation, but it does not prove that a data migration, permission rule or support route works.

Use the service standard as a reminder to keep the service usable, secure and improvable, while treating its public-service context as guidance rather than a promise about this project. Where access or ownership is involved, verify the actual rule at the application and operational boundary; a hidden button is not a complete authorisation decision.

Make the output useful after the meeting

A planning asset should survive the meeting that created it. Put the date, version, source of each decision and current status in the record. Link the item to the relevant brief, screen, workflow, test result or issue without copying sensitive information into a public document. If the record changes, preserve the previous decision or note what was superseded.

For issue-sized work, a structured task can be enough. GitHub's issue documentation shows the general pattern of using a written issue to track a task, bug, idea or piece of work. The tool is not the important part. What matters is that the description provides enough context for a reviewer to understand the request, its evidence and the next action.

Define a small status vocabulary that the project actually uses, such as open, awaiting input, ready for review, accepted, deferred and closed. Do not create ten statuses that nobody updates. Add a last-reviewed date and owner so an old “ready” label cannot be mistaken for current evidence.

When data or access is involved, keep secrets out of the worksheet. The OWASP logging guidance is a useful reminder that operational records can contain sensitive information and should be designed and protected accordingly.

A review sequence you can repeat

1. State the decision and the user or business task it affects.
2. List the evidence, assumptions and constraints separately.
3. Assign the person who supplies evidence, the person who reviews it and the person who approves the decision.
4. Record dependencies, exceptions and the consequence of delay.
5. Agree the next check and the evidence that will show it is complete.
6. Update the record when a decision changes, rather than relying on a conversation that only some participants heard.

This sequence is deliberately modest. It does not create a guaranteed timeline, quality score or commercial outcome. It gives a project sponsor enough visibility to ask better questions and gives a development team a clearer boundary for implementation. The core agile principles support iterative delivery, learning and continuing to plan; use those ideas to keep the record current as evidence improves.

If a review exposes a missing business decision, stop the affected commitment and name the decision. If it exposes a small clarification, record it without expanding the entire project. If it exposes a larger change, route it through the agreed change process. This is how a project remains adaptable without becoming unbounded.

Discovery decision and evidence register.

Use the following blank asset as a starting point. Do not populate it with invented project facts. Each row should be completed from an approved brief, an observed workflow, a provider confirmation, a test result or a named decision owner.

After the first pass, review the asset with the people who will use its output. Ask which row is still ambiguous, which dependency could change the decision and which evidence would be sufficient for acceptance. A blank cell is a useful finding when it has an owner and a next action. It is a problem when it is silently ignored.

For this topic, add an ordinary case, an exception and a deferred case. For each, identify the trigger, responsible person, expected result, evidence and follow-up. Keep customer or staff data representative and safe. Do not paste passwords, private contact details or production records into an editorial worksheet.

FAQs

What should discovery deliver?

Start with the output that lets someone make the next decision. For this topic, that means recording the current evidence, the unresolved question, the owner and the condition for review. A named document is less important than a visible decision trail.

Can it recommend not building?

It can change when new evidence appears. The change should be recorded with what changed, why it changed, who approved it and which downstream work needs to be checked. Treat the register as a working project record, not an irreversible promise.

Which unknowns can remain?

Use a bounded exception. Record what is unknown, why it is not blocking the current decision, who will resolve it and what would happen if the answer changes. Unknown does not mean ignored.

When to pause or simplify

Do not add a process layer merely because a project feels uncertain. Pause when the underlying decision is still undefined, the evidence cannot be accessed, the owner is unknown or the proposed output would only record activity without helping someone choose or verify something. A short conversation with the right decision owner may be more valuable than a larger template.

Also avoid treating this guide as a substitute for the project’s approved agreement. Commercial terms, legal duties, response times, data responsibilities and release controls must come from the actual parties and current environment. Recommendations in this article should be adapted to the size and risk of the work.

If you need help connecting the decision to a website, application or support workflow, bring the current state, the desired outcome, known constraints and the completed blank asset to a development conversation. Custom development can be discussed around the evidence available and the next bounded step, without pretending that an unseen project has already been assessed.