Web development: how to define a step-by-step project

Your company needs a new website, but in trying to explain it, mixed requests appear: "that is modern", "that positions", "that allows contact" or "that we can update it".The problem is not to have many ideas; it is that they do not yet form a decidable project.

This guide helps you prepare a web development before choosing technology or asking for a proposal. When you finish you will be able to distinguish the objective of your website, order what should be included and detect the decisions that should be closed with the responsible people.

Expected outcome

The result should not be a list of pages without context. You should end with a brief and concrete description of five elements:

• what should change thanks to the web;
• whom it should serve and what action it should be able to do;
• what the first version includes and what can be expected;
• what content, data and decisions your company should provide;
• how you will check that the relevant parts work before publishing.

On this basis, web development is no longer a generic request and becomes a project that you can review, prioritize and compare with more criteria.

Step 1: Define the target

OBJECTIVE: express what the web should get for your business and for those who visit it.

Action: completes a sentence that relates an audience, an action, and an expected change. For example: "The website should help people who seek our service understand if we fit in and send us a query with the necessary information."

Avoid using adjectives as a goal. "Professional", "fast" or "complete" may be desirable qualities, but they do not indicate what should happen and how you will know if the website fulfils its function.

You also need to choose a main action. It can be asking for information, booking an appointment, asking for a quote, buying a product or accessing a private area. If all actions seem equally important, the website will have more difficulty guiding who visits it.

Check: can explain in one or two sentences who will use the web, what should be done and why that action matters to your company. If you can't do it, you're still defining the need, not the development.

Step 2: Defines the scope of the first version

OBjective: decide what should be ready for the web to fulfil its initial function.

Action: separates each element into four groups:

-Inessential: without it the defined target is not met. -Desirable: provides value, but can be incorporated later. -Future: is a possibility of evolution, not part of the first delivery. -Out of scope: does not correspond to this project.

Apply this classification to pages, forms, languages, catalogue, content migration, integration with external tools, analytics, training and maintenance. Thus, you avoid that a phrase like "we want a website with everything" hides different decisions.

A form, for example, is not defined just by existing. You must specify which fields will have, who will receive the messages, what will the person see when sending it and what will happen if the sending fails. The same is true for an integration: naming a tool does not explain what data is connected, in which direction or what should happen to an incidence.

Check: each feature included has a motive related to the target and a visible priority. The desirable or future is not presented as part of the first version.

Step 3: Collect data and assign responsible

OBJECTIVE: prevent the project from being blocked by pending content, accesses that do not appear or decisions without responsible person.

Action: identifies what your company needs to contribute and who takes care of each part. At a minimum, clarify:

• who validates texts, images and commercial messages;
• what content already exists and what needs to be created or revised;
• whether pages, documents, products or data will be moved from a previous website;
• which accounts and accesses are needed for domain, hosting, mail, analytics or connected services;
• who makes decisions when there is a doubt of scope;
• who will update the website after its publication.

It is not appropriate to assume that the content will arrive "when you touch". If a service page, product sheet or image is necessary to publish, it is part of the planning even if prepared by another person.

If the website collects personal data, processes payments or has specific sectoral requirements, it validates the applicable obligations with the corresponding legal, fiscal or compliance profiles. Development should be adapted to those decisions, not substituted for them.

Check: each relevant unit has an agreed date and delivery date or condition. If an access, content or approval is missing, it is indicated as an open unit.

Step 4: Choose the solution after defining the need

OBJECTIVE: select a way to build and maintain the web that fits the actual reach.

Action: compares options according to the needs already defined. A solution based on a standard structure can fit when pages and functions follow a known pattern. A more personalized development can make sense when there are own paths, specific rules, data to manage or integrations that a standard solution does not reasonably cover.

Technology should not be the starting point. Before deciding, it reviews practical questions:

• who will edit the contents and how often;
• whether there will be different user profiles or permissions;
• which external tools should be connected;
• what data should be stored, migrated or exported;
• what changes are envisaged after the first version;
• who will assume updates, support and evolution.

This conversation also serves to separate the initial construction from subsequent needs. Maintaining, updating content or adding new functions are different decisions and should be described separately.

Check: you can justify the chosen solution without resorting to vague preferences. It should be clear what requirements it covers, what limits your company accepts, and what decisions are left for a later phase.

Step 5: Validate before publishing

OBjective: check that the web responds to what has been agreed and not just that it "looks good".

Action: defines acceptance criteria for important parties. A useful criterion indicates the initial situation, action and expected result.

For example, a criterion for a form could be: when a person completes the required fields correctly and sends the request, he sees a clear confirmation and the message reaches the defined destination. If there is an error, he receives an understandable indication to correct it.

It also checks priority routes from different devices and with profiles that will actually use the web. It checks links, contents, forms, permissions, notices and connections to external services when they are part of the scope. Validation does not eliminate all possible incidents, but it allows detecting discrepancies before the web is available to the public.

Check: each relevant delivery can be evaluated with an observable condition. Incidences, changes and pending elements are recorded to decide whether to block the publication or move to a later phase.

Errors in execution that should be avoided

-Levirate technology before you understand the problem. A platform can condition the project if it becomes the main decision too soon. -Confused reach with desires. Future ideas are useful, but mixing everything makes it difficult to know what is expected from the first version. -Leave content unaccounted for. A website is not ready to post because the structure is finished if messages, images or essential information are missing. -Speaking about functions without describing the route."We need reservations" or "We want a customer area" is not enough to define users, data, rules and exceptions. -Agree ambiguous terms. Words like "intuitive", "complete" or "optimized" need to be translated into verifiable behaviours. -Validate only at the end. Revising objectives, scope, and content during the project reduces the likelihood of discovering disagreements when it is already harder to correct them.

Defining a project well does not require you to know web development in depth. It allows you to provide information that only your company knows and ask that technical decisions be explained according to their practical effect.

If you still have doubts about the scope, integrations or how to propose a first version, you can explain your web development project to AVSISTEC to assess what information should be specified before moving forward.