Build something new
Start with the audience, content, essential journeys and the decisions the website needs to support. Establish a useful first release before expanding the feature list.
Division 03 / Give the website a clear job
A website should make something easier.
A new website, an existing experience or a difficult technical constraint. Define the visitor’s task first, then the work needed to support it.
01The work in context
A website is a set of decisions.
A website can look finished while leaving its most important job undone. Visitors may still struggle to understand an offer, complete a task or reach the right next step.
Improve what already exists
Identify the pages or interactions causing friction. Separate problems in content and design from constraints in the underlying implementation.
Resolve a technical constraint
Bring the observed problem, its impact and the existing environment. The proposed scope can then be tied to a testable change.
02 / Define the engagement
Proposed scope · Awaiting business confirmation
Make the deliverables part of the conversation.
A page and journey plan
Proposed output: required pages, priority user tasks, content responsibilities and clear boundaries for the first release.
A working implementation
Proposed scope: the agreed website and interactions, with responsive behavior and accessibility considered as part of the build.
Acceptance and handover
Proposed output: checks against the agreed requirements, remaining issues and the information needed to run and maintain the result.
These are proposed scoping topics, not a fixed package or a delivery promise. Methods, outputs, responsibilities, timing and fees need to be confirmed before an engagement.
03 / A useful first message
Start with what you know.
- What should a visitor understand or complete on the website?
- Is this a new build or a change to an existing site?
- What content, systems or deadlines does the work need to account for?
Keep the first message high-level. Do not include passwords, access tokens or confidential records.
04 / Questions worth asking
A few things to know.
Can the project focus on an existing website?
That is a valid starting point for an inquiry. Describe the current website, the problem and the result you need. Feasibility depends on the implementation, access and agreed scope.
Do I need a complete specification before making contact?
No. A description of the audience, the main task and the current obstacle is enough to begin a scope discussion. Existing content or constraints are useful if you have them.
How would we know the website is finished?
Agree acceptance criteria before the build. These should describe the required pages, working journeys, supported environments and relevant quality checks. Unresolved items should be recorded at handover.
Are hosting and ongoing maintenance included?
They must be agreed explicitly. Hosting ownership, operating costs, maintenance responsibilities and post-launch work should be defined in the engagement rather than assumed.
Can accessibility and search requirements be included from the start?
Yes. Define the intended audience, important search content and accessibility acceptance checks while scoping the website. Specify the testing and responsibilities in the agreement; a build alone does not guarantee compliance or rankings.
Related perspectives
The next question may sit nearby.
The next conversation
Bring the problem into focus.
An outline is enough to begin. Tell us the situation and the decision you need to make.
Discuss a website project