Create website: checklist for making decisions before launching

Be clear that you need a website does not solve the decisions that determine if you can use it peacefully afterwards: what should explain, what action should facilitate, who will update the contents or what happens when a form fails.

This checklist for create a website helps you sort out those decisions before ordering the project, during its development or just before publishing it. At the end you will know if you can move forward with a defined scope, if you need to specify important points, or if the project requires a deeper review.

Use it by marking each check as done, pending or not applicable. It is not about accumulating pages or functions: it is about the website responding to a specific objective and can be maintained after the launch.

Purpose of the review

Before choosing a design, template or technology, it separates three decisions:

For example, a company may want to receive service requests. That’s the goal. Service pages, cases that can be published, a form and a way to attend to contacts are part of the scope. Content manager, design and integrations are decisions of solution.

Starting with this separation reduces a common problem: deciding the tool before knowing what to solve. If the target is still expressed with vague terms such as "having a presence", make it an observable action, such as explaining services, receiving queries, displaying a catalogue or giving access to information for customers.

Previous Checklist

Complete this block before asking for a proposal or starting to build. Answers do not have to be definitive in all details, but doubts affecting the scope should be visible.

-I have defined the main objective. I can explain what should facilitate the website: queries, reservations, requests, service presentation, online sale or other concrete action. -I have identified the people who will use it. I distinguish, at least, between who visits the website and who will manage it within the company. -I have chosen a main action per tour. I know what a person should be able to do after reading a relevant page: contact, ask for information, consult a service or start another process. -I have listed the required pages. Not just a home page: also services, contact, corporate information, private areas, catalogue or other sections if applicable. -I have reviewed the available contents. I know which texts, images, document, products or data exist and which ones will have to be prepared. -I have assigned responsible. Each relevant content has a person who prepares, reviews and approves it. -I have separated the essential from the desirable. The functions or pages you can expect are not presented as necessary for the first version. -I have identified restrictions. Relevant dates, tools already used, languages, external dependencies, internal requirements or migration needs are noted.

A website may seem simple until you specify what it should contain. For example, "includes a form" does not define your fields, the recipient of messages, the confirmation that the person will see, or what should happen if the send fails. Those details are part of the scope, not a minor setting.

Functional Checklist

This block checks that the website serves to perform the planned actions. Check it with real examples of use, not just by looking at a model.

-The proposal of each page is understood quickly. The title and the first contents explain what you offer or what you can find. -The navigation allows you to get to the important thing. The main sections are localizable and the names in the menu do not depend on internal or ambiguous terms. -Each relevant page has a clear next step. Not all need the same, but none should leave the person without knowing how to continue. -Contact details are correct and updated. Check phones, emails, addresses, times and external links if any. -The forms only collect the necessary information. Each field has a purpose and the team knows who will receive and respond to the requests. -The form confirms the result. After correct sending, the person receives a visible confirmation; if there is an error, understand what to correct or what alternative you have. -Commercial content answers specific questions. Explain services, operating conditions or processes with the precision that needs to be contacted by those who are evaluating contact. -Internal management is planned. You know what content you can edit, who will have access and what changes will require technical support.

If you incorporate reservations, payments, customer accounts, configurable budgets or specific rules, it is appropriate to describe each flow step by step. It indicates what the person introduces, what validations exist, what messages he receives and what happens in exceptions. A function named without that path is not yet sufficiently defined.

Technical checklist

The technical review does not require you to know the implementation, but you can ask for understandable checks and agree who takes care of each aspect.

-The website is reviewed on mobile, tablet and computer. The content remains legible, buttons can be used and forms are completed without obvious obstacles. -IImportant pages load and display their content correctly. Especially checks images, documents, videos, forms and elements that depend on external services. -Internal and external links work. They don't lead to missing pages, incorrect destinations, or documents that are no longer available. -Accesses are controlled. Domain, hosting, content manager and connected services accounts have an identified holder and recoverable accesses. -Backup has been defined. It should be clear what is saved, how often and how the web would be recovered in the event of an incident. -Updates are responsible. The system, its components and integrations require a way to review changes and correct incompatibilities. -Data sent by forms has a defined path. You know where they come from, who can consult them, and what to do if the destination stops working. -The requirements applicable to your content and data have been reviewed. If the website collects personal data, sells products or provides services subject to specific obligations, validates texts and processes with the competent professional person.

It is also appropriate to agree on acceptance criteria. Instead of approving the form, it uses a specific check: when completing the mandatory fields with valid data, a confirmation message appears and the request reaches the defined recipient. If a mandatory data is missing, the information is indicated without deleting the rest of the information entered.

Maintenance Checklist

Publishing does not close the job. A website loses utility when the contents, accesses or dependencies are left without responsibility. This block serves to prepare the subsequent operation.

-There is a person responsible for reviewing the website. You have access to the accounts required or know how to request it. -There is a routine to update content. Services, contact details, equipment, documents, products and notices are reviewed when they change. -It has been decided how to attend to incidents. It is defined what is considered an incidence, to whom it communicates and what information should be provided. -Renewals and external services are controlled. Domain, hosting, licenses or connected tools have a responsible and a warning track. -For future changes, priority is given to them. You distinguish between urgent fixes, desirable improvements and functionalities for a later phase. -Minimum documentation is available. Access, account ownership, how to update relevant content and dependencies are not left alone in a person's memory.

Not all projects require the same level of maintenance. An informative website with stable content will have different needs from a store, a customer portal or a web connected to management tools. The useful decision is to make clear what you need to keep, review and evolve, and who will.

How to interpret the result

Count the checked as done. If a point does not apply for real, excluate it from the total instead of marking it as fulfilled. Then interpret the result along with the nature of the earrings.

-Most are made and there are no critical pending: can move towards launch or technical definition. Document the decisions made so they are not lost in loose conversations. -There are several content, objective or responsible pending: still does not need to close the scope. First resolve what the website should explain, who will provide the information and what action each visitor should complete. -There are critical functional or technical pending: stop publishing until you review them. A form without recipient, accesses without clear headline, broken links or lack of backups are examples of issues that require solution before relying on the web. -No rules, users, data or integrations have been released: the project has probably ceased to be a purely informative website. Divide the scope, prioritize a first version and validate if you need a more personalized solution.

The checklist does not replace a technical, legal or business review when your case requires it. Its function is to get to that conversation with the right questions and with decisions that can be checked.

If you still have no idea how far your project needs to go or how to fit a specific function when you complete the list, you can explain your web development project to AVSISTEC to assess needs before deciding on the solution.