Web-type projects require excellent communication and coordination among the various stakeholders involved. In this document, we have gathered some details to facilitate our communication.
Primary communication via email #
We prefer to communicate via email, as it is a medium that allows us to:
- Organize and establish priorities, status, and tracking of issues.
- Maintain a record of what has been discussed and perform searches on it.
- Review matters more thoroughly before providing a response.
- Communicate at the most convenient time for each stakeholder involved.
- Include multimedia elements (images, videos, files) that help in understanding the message.
In any case, it is important that email communication presents the subject clearly and concisely (whenever possible) to facilitate reading and comprehension for all parties.
Requesting a quote for website development #
To request a quote, it is advisable to provide as much objective and subjective information regarding the project as you can. This will allow us to provide the most accurate quote possible.
We are aware that gathering this information, making sense of it, synthesizing it, and documenting it requires a significant effort. However, please keep in mind that this work is necessary sooner or later. That is why we request it this way; if you are unable to perform this task, we can offer a consultancy service prior to the quote to define this information. If for any reason you do not wish to specify this information before the quote is prepared, we may be unable to provide one, or it may be highly inaccurate.
Objective information #
We primarily need all information affecting the project regarding three major areas:
Information architecture #
This is the art of organizing information as clearly and logically as possible; the goal is to ensure that users accessing the website receive the information we want to convey easily, can find what they are looking for, and experience intuitive navigation and order.
Defining this involves determining each of the pages that make up the website, as well as the content displayed on each of them.
This definition is recorded in a document that defines the organization and relationships between all elements of the website. The design work will depend on this document.
Design #
If you provide the design, we do not require the final design for the quote (if you can provide it, all the better, but we understand this is usually not confirmed until there is a development quote), but we would need indications of what the design might look like. While the information architecture may already provide many clues, there are some elements whose layout can vary from very simple to very complex, and this can significantly affect our dedication and, therefore, the budget.
If no final design exists, we will make an estimate in our quote based on the indications provided.
Functionalities #
With the information architecture and design indications, we can likely deduce many of the functionalities that must be considered when developing the website. Additionally, there are many basic functionalities that we already provide “as standard” when developing a new website.
However, you may want your website to do something special—something that cannot be deduced from this documentation—or you may want to emphasize a particular element. This would be the time to indicate it. Any information in this regard will help us provide a more reliable quote. Before preparing the quote, we may schedule a meeting with you to request more details about these functionalities.
Subjective information #
As an additional element to the objective information, we would like to know more subjective details about the project; this will help us better understand what the project requires and truly needs.
This information may include:
- What the project’s objectives are.
- What traffic and usage are expected.
- What return on investment is expected.
- What expectations this project has within the project management triangle.
Non-useful information #
The information provided must necessarily be specific. There is information that we cannot consider useful for the purpose of creating a quote.
- Indicating that it should be like another website without adding additional information: While having existing projects as a reference is truly valuable information to help us understand the project, it is not useful information on its own for quoting. It is necessary to specify which elements our project will adopt and how it will do so, because a reference of this type can generate different project concepts for different people.
Example: The owner of Tesla says he wants to produce a vehicle that is like an Audi (without specifying that he wants a fully electric vehicle, and that it actually shares no parts with an Audi). It is true that both look alike—both are cars with four wheels used for travel—but they differ enormously in design, components, project projection, and technology. . - Indicating that it should be like X but simpler without adding additional information: Again, having a reference is extremely important and valuable, but on its own, it is not useful. The concept of simplicity will be radically different in each person’s mind, which is why specificity is required.
Example: The owner of Tesla says he wants to produce a vehicle that is like a tram without overhead lines but simpler. He is likely thinking of an electric car with batteries that allows for free travel on any paved road, but others might think of a funicular, a shorter battery-powered tram, a diesel-powered tram, etc. - Withholding relevant information is not useful: There are details that can be very important; if you do not convey them to us, it may cause our quote and the proposal we have made to become invalid for this project.
Functionalities must be clear from the start of the project; having them appear halfway through will only result in us having to stop the project, analyze how this new feature influences it, and determine if we can proceed as is or if we must go back and redo things, thereby requiring a new proposal.
Example: The owner of Tesla says he wants to produce a car but does not convey that he wants a battery-powered electric car. When they have already designed the gasoline engine, gearbox, exhaust, filters, fuel tank, and the space in the bodywork for these components… he suddenly says no, what he wanted was an electric car, so none of those components will be needed.
Coordination with design #
This information can now be found at https://giga4.team/docs/coordinacion-con-diseno/
Communication of new tasks #
Please keep the following details in mind when communicating a change to be made to a website.
- Indicate clearly and concisely what is currently there and what you want to change it to.
- Provide details, for example, if you want a specific color, a change in typography, etc.
- It is also helpful to indicate the reason and/or objective for this change; this way, we can understand what is intended to be achieved.
Communication of errors or items to be reviewed #
In the event that you detect a problem, error, or something you believe has not functioned correctly, we recommend following these steps to communicate it to us:
- Indicate what the problem was and what the situation should be without the problem.
- If an error message is involved, copy and paste it into the email. Try not to transcribe from memory, as this would make it difficult to identify the problem the message refers to.
- Indicate how you encountered the problem.
- Always copy and paste the URL where it occurs.
- If it might be helpful, attach screenshots or videos.