Web design · Structured preparation
Website planning: questions to resolve before the project
You do not need every technical answer before a website project begins. However, you should be able to explain what problem the website should solve, who makes decisions and what foundations already exist. This clarity makes quotations easier to compare and prevents important dependencies from emerging only during implementation.
The following questions take you from business objectives to ongoing maintenance. For each answer, record whether it is decided, still open or deliberately not relevant. The local checklist helps you maintain this overview without storing or transmitting information.
1. Distinguish business objectives, website goals and target audiences
What change should the business achieve?
Start with the business objective. Do you want to explain a new offering, reach suitable employees or simplify the handling of recurring enquiries? A website can support these aims, but it replaces neither a clearly defined offering nor internal workflows. Identify limitations and prerequisites too.
Derive a specific website goal from this. For example, improving preparation for consultations might lead to a goal of explaining services and required documents clearly. Define how you will recognise success. Qualitative feedback can be just as helpful as carefully chosen metrics.
Who needs to be able to act on the website?
Describe your key target audiences in terms of their needs and decision-making situation. What do they already know, what uncertainties do they have and what information do they need before making contact? Avoid defining a target audience that includes everyone indiscriminately. Prioritise the most important visitor journeys for the initial project scope.
2. Define your offering and required pages
Create an overview of your offerings and mark which should appear on the website at launch. Record differences, prerequisites and exclusions. If your offering is changing, a subject-matter decision is needed before editors can write definitive service descriptions.
Derive the page structure from your audiences’ questions. A homepage, clear service sections, company information and a contact page are often useful. Additional sections need a clear purpose. An existing navigation structure need not be retained unchanged simply because it has existed for years.
| Question | Decision needed | Responsibility |
|---|---|---|
| Which offering will launch? | Scope and limits | Management |
| Which pages are needed? | Prioritised page list | Project manager and editorial team |
| Which feature is essential? | Launch or later phase | Subject specialists |
| Who approves content? | Named person and deadline | Client |
Flag pages whose subject matter is still unclear. This reveals whether a workshop, copy revision or internal business decision is needed first. The article on business website content supports this review.
3. Describe features, online stores and bookings precisely
Describe features as complete workflows rather than isolated keywords. For search functionality, for example, clarify which content should be found. A restricted area requires consideration of roles, access and forgotten passwords. A feature list without these connections leaves the actual scope undefined.
What does a sale involve?
An online store needs more than product images. Clarify the range, variants, stock, delivery areas, payment methods, shipping, reversals and responsible people. Determine which system maintains prices and stock data. Legal and tax questions also need timely specialist preparation, particularly for cross-border sales.
What does a booking mean in your business?
Distinguish a non-binding appointment request from a confirmed booking. Define availability, buffer times, confirmations and the handling of changes. If an appointment needs checking first, the website must not imply immediate confirmation. Also consider cancellations, absences and internal calendars.
Assign every feature to a launch phase or a later extension. Ask not only whether something is technically possible, but who will manage the process afterwards. A deliberately smaller first version can make sense if it covers the main visitor journey completely and reliably.
4. Prepare content, images and languages
List existing texts and check their factual currency. An old brochure is not automatically a finished website template. Mark whether material for each page can be retained, needs revision or must be created from scratch. Also agree who supplies information and who handles editorial work.
For images, you need an overview of subjects, quality and usage rights. Clarify whether a photo shoot is required and which people or rooms may be shown. Plan alternatives if a proposed image is not approved. What the image communicates matters, not just whether it is available.
Plan languages as complete visitor journeys
Decide which audiences need which language. Include navigation, forms, confirmations and legal content alongside text pages. Define who checks translations for subject-matter accuracy and how later changes will be tracked across all language versions. Automated translation does not replace this responsibility.
Identify missing content early as separate tasks with deadlines. Otherwise, the design may rely on assumptions that later fail to fit the actual amount of text. If you are planning multiple languages, the detailed guide to a multilingual website helps define the scope.
5. Safeguard your existing domain and business email
Clarify who owns the domain, which provider manages it and who has administrative access. Check the customer account details and whether the registered contact address can be reached. Do not share passwords in a general project overview; use a suitably secure method instead.
Record existing business email addresses, forwarding rules and responsible providers. A new website does not automatically require changing email services. However, changes to domain settings can affect email operations. Existing records and dependencies must therefore be checked and preserved before a switch.
Clarify the technical starting point
- The domain owner and responsible provider are known.
- An authorised person can access domain administration.
- Existing email services and important addresses are recorded.
- Responsibility for changes to domain settings is defined.
- A date and rollback plan for the switch will be agreed.
If responsibilities are unclear, resolve them before publication day. For an existing domain, domain administration support may be useful. Allow sufficient time to obtain access in an orderly way without prematurely changing ongoing operations.
6. Plan forms, integrations and data protection together
What information does the actual workflow need?
Define each form’s purpose, required fields and recipient. Ask only for information needed for that process. Clarify how entries are validated, what happens if errors occur and which confirmation a person receives after successful submission.
The official W3C WAI tutorial describes clear labels, understandable instructions and feedback as elements of accessible forms. Include these points in the requirements rather than adding them only during the final review: 1.
Which systems will be connected?
List planned integrations such as customer management, newsletters, bookings or inventory management. For each connection, clarify the direction of data transfer, required access and behaviour during failures. Determine who handles error messages. An interface is only properly planned once its ongoing operation is understood too.
Also record which personal data forms and external services process. The FDPIC explains how to provide transparent information about this in a privacy notice. The notice must reflect the procedures actually used: Privacy notices on the internet. Seek specialist advice where legal questions are unclear.
If you would like to discuss your preparation, you can submit your goals and open questions through the website creation enquiry form.
Send a non - binding enquiry7. Assign maintenance and responsibilities firmly
Decide who will update text, images and contact details after launch. Separate this editorial maintenance from technical tasks such as updates, security checks and monitoring embedded services. These tasks do not automatically all belong to the same provider or internal person.
Name a project manager, subject-matter contacts and an authorised decision-maker. Define how feedback will be collected. Consolidated, coordinated feedback prevents contradictory individual requests from reaching implementation simultaneously. Absences require a deputy with sufficient decision-making authority.
Plan the handover with appropriate permissions and understandable documentation. Practise typical changes, such as replacing a telephone number or updating a service. Organisational preparation for maintenance is complete only when these tasks work in the intended day-to-day setting.
8. Set realistic timescales and approvals
Distinguish a preferred launch date from an immovable event. If a trade fair or campaign dictates the date, define the essential minimum scope early. Allow for holidays, internal reviews and external deliveries. A schedule without time for feedback and corrections is not a reliable foundation.
Agree approvals for the page structure, content, design and completed implementation. Record what each approval confirms and how later change requests will be handled. Approval of the design, for example, does not replace subject-matter checks of service information or review of legal content.
Before publication, include forms, mobile usability, links and important visitor journeys on a shared checklist. Name the person who gives definitive launch approval. The article on the website creation process explains how these steps fit into the overall project.
9. Distinguish budget categories and later extensions
Separate one-off project services from ongoing expenditure. Creation may include concept development, design, implementation and content work. Ongoing costs may cover the platform, hosting, domain, external tools and agreed support. Which items actually apply depends on your scope and chosen solution.
| Budget category | Possible components | Planning question |
|---|---|---|
| One-off creation | Concept, design, implementation | What is included at launch? |
| Content | Copy, images, translation | What will you supply yourself? |
| Ongoing operation | Platform, services, support | Who pays which costs? |
| Extension | New features and languages | What will be decided later? |
When reviewing quotations, ask about included services, assumptions and explicitly excluded tasks. A seemingly lower total says little if copywriting or necessary interfaces are missing. The article on website cost factors helps you examine these differences systematically.
Describe expected extensions early without having every possibility built immediately. An additional language, a future online store or a customer area can influence the choice of system. Record which assumptions remain uncertain and when decisions will be made. This keeps contingencies understandable rather than unlimited.
10. Identify open questions with the local planning checklist
Work through the interactive planning checklist with the responsible people. Mark only points whose answers are sufficiently clear. An open question is not a project failure, but a task for the next step. Even features deliberately not required should have a brief internal justification.
The checklist does not store or transmit any data. Your selection applies only to the current view and resets when you reload. If necessary, transfer decisions and open tasks into your internal project planning yourself. Confidential credentials or personal details do not belong in a general checklist.
If you then wish to send an enquiry about creating a website, your goal, intended scope, starting point and preferred timescale are enough initially. Explicitly flag unresolved points. You do not need to specify a technical solution before requirements and dependencies have been reviewed together.
Summary
- Derive the website goal from a specific business objective.
- Prioritise audiences, offerings and essential pages for launch.
- Describe features as complete workflows with clear ongoing ownership.
- Check content, image rights, languages, domain and business email in good time.
- Name responsibilities, approvals and realistic deadlines.
- Separate creation, ongoing operation and later extensions in the budget.
Frequently asked questions
Must I know every answer before the first meeting?
No. Open questions are part of preparation. What matters is distinguishing existing decisions from assumptions. Bring your goals, starting point and known dependencies above all.
Do I need finished copy already?
Not necessarily, but the required content and responsible people should be identifiable. Clarify which texts exist and who will create missing content. Copywriting needs its own time in the project schedule.
Does the domain have to move when the website changes?
Not automatically. Your existing administration and the requirements of the new operation are what matter. Always check dependencies affecting business email before making changes.
Should future features be implemented immediately?
Only if they are needed at launch or represent a justified technical prerequisite. Nevertheless, describe future plans early so they can inform the choice of suitable foundations.
How can quotations be compared meaningfully?
Compare scope, included content work, features, support and ongoing costs separately. Ask for unclear assumptions to be explained. A single total does not show which tasks you must undertake yourself.
Are my planning checklist entries stored?
No. The checklist works only locally in the current view and transmits nothing. Reloading resets the selection. Document important decisions yourself in your internal planning.
Sources
- Privacy notices on the internetFederal Data Protection and Information Commissioner FDPIC · checked on 2026 - 11 - 05
- Forms Tutorial | Web Accessibility Initiative (WAI) | W3CW3C Web Accessibility Initiative · checked on 2026 - 11 - 05
Back to the top of the article
