Per encarregar una web amb criteri, una agència ha d'explicar l'objectiu de negoci, les persones que la faran servir, l'acció principal, el contingut, el disseny disponible, les integracions, el context SEO i qui decideix cada part. No ha de prescriure la tecnologia: ha de donar prou context a l'equip tècnic per proposar un abast realista i detectar riscos abans de prometre una data o un preu.
Per què convé preparar la informació abans de pressupostar
Quan un client diu que vol una web nova, normalment encara no està descrivint un projecte. Pot necessitar captar contactes, explicar una proposta complexa, vendre, publicar continguts, integrar un CRM o substituir un lloc que ja posiciona. Cada cas exigeix decisions i esforç diferents.
Una web pot semblar una landing sense misteri fins que apareixen tres idiomes, un CRM, una campanya amb data tancada i la condició de no perdre allò que ja funcionava a Google. No és cap drama: només convé saber-ho abans de donar un preu.
L'agència acostuma a tenir molt clar el posicionament, la marca i la relació amb el client. Preparar aquesta informació permet traslladar el context a l'equip de desenvolupament sense convertir ningú en tècnic. Així es pot decidir què cal construir, què convé validar primer i quines preguntes continuen obertes.
L'objectiu no és tancar tots els detalls abans de parlar amb desenvolupament. És evitar pressupostar a cegues una llista de pàgines i descobrir després que faltaven idiomes, contingut, integracions, migració, permisos o un procés d'aprovació.
Quina informació necessita desenvolupament per pressupostar una web
No cal un document interminable. Aquestes són les peces que més canvien l'abast d'una web i que convé recollir abans de demanar una proposta:
| Apartat | Què ha d'explicar l'agència | Per què canvia el projecte |
|---|---|---|
| Negoci i objectiu | Què ven el client, a qui i quina acció ha de completar una visita | Evita dissenyar una web bonica que no ajuda a aconseguir el resultat esperat |
| Audiències i recorreguts | Qui hi arriba, què necessita trobar i què fa després | Defineix jerarquia, continguts, formularis i possibles àrees privades |
| Contingut | Quins textos, fotos, vídeos, idiomes i responsables existeixen | El contingut pendent sol moure dates i condiciona el gestor |
| Disseny i marca | Figma, guia d'estil, referents i decisions encara obertes | Un disseny visual no sempre defineix tots els estats, mides i comportaments |
| Funcionalitat | Formularis, cercador, reserves, pagaments, usuaris, integracions o automatitzacions | Cada flux té dades, errors, permisos i manteniment que cal estimar |
| SEO i migració | URLs actuals, pàgines que reben trànsit, idiomes i objectiu orgànic | Una migració sense inventari pot perdre senyals i pàgines útils |
| Operació | Qui publica, aprova, manté i respon incidències | Ajuda a escollir CMS, permisos, formació i suport |
| Termini i pressupost | Data que condiciona el projecte, pressupost orientatiu i què pot quedar per a una fase dos | Permet proposar una primera versió viable en lloc de prometre-ho tot |
Plantilla per preparar un projecte web amb el client
Pots copiar aquesta estructura a Notion, Google Docs o al document que facis servir amb els teus clients. No omplis buits amb suposicions: marca allò que encara s'ha de decidir i qui ho decideix.
- Projecte en una frase: quina empresa és, què canvia i per què es fa ara.
- Objectiu principal: una acció concreta que ha de completar la persona usuària, per exemple demanar una demo, reservar, comprar o contactar.
- Públic: a qui parla la web, quin problema té i quina informació necessita abans d'actuar.
- Oferta i missatges: serveis o productes prioritaris, diferenciadors demostrables i afirmacions que no s'han de fer.
- Estructura: seccions, tipus de pàgina i continguts imprescindibles. No cal tancar el mapa del lloc si encara s'ha de treballar.
- Disseny: enllaç a Figma, guia de marca, referents i què es vol prendre de cada referència. Indica quines pantalles no estan dissenyades.
- Funcionalitat: formularis i el seu destí, CRM, newsletter, analítica, pagaments, reserves, àrees privades, idiomes o qualsevol sistema existent.
- SEO i web actual: domini, CMS, URLs que s'han de mantenir, redireccions necessàries, contingut que es reutilitza i accessos disponibles.
- Persones i procés: qui aprova disseny, contingut i desenvolupament; com es recull el feedback i quin canal es fa servir cada dia.
- Termini, pressupost i fases: data rellevant, pressupost orientatiu, dependències i què es pot deixar fora de la primera entrega.
- Criteris d'acceptació: què ha de passar per considerar que cada part està llesta, inclòs el llançament i l'entrega d'accessos.
El que no cal definir per demanar una bona proposta
No has de decidir el framework, escriure una especificació tècnica completa ni dibuixar cada estat de cada pantalla. Tampoc cal jugar a endevinar si alguna cosa va amb React, WordPress o un tovalló. Són decisions que convé prendre amb qui construirà el projecte, amb el problema i les restriccions al davant.
Tampoc no ajuda fixar una data i demanar després que es descobreixi què hi cap. Si hi ha una campanya, un esdeveniment o un llançament que no es pot moure, inclou-lo com a condició. L'equip tècnic podrà proposar què ha d'entrar a la primera fase i què convé ajornar.
Un bon partner no hauria d'utilitzar la informació que falta per facturar sorpreses. Hauria d'assenyalar-la, separar allò confirmat d'allò pendent i explicar quin canvi d'abast suposaria cada decisió.
Quatre errors que encareixen un projecte web
- Confondre una referència visual amb una definició funcional. Una web pot semblar senzilla i tenir fluxos complexos al darrere.
- Deixar el contingut i els idiomes per al final. Decideixen navegació, components, espai, SEO i calendari.
- Tractar el formulari com un detall. No és decoració al final de la pàgina: cal saber quines dades demana, on arriben, qui les atén i què passa si falla.
- Parlar de SEO només al final. Si se substitueix una web existent, les URLs, els continguts i les redireccions es revisen abans de publicar.
Si el client ja té una web que genera trànsit, el desenvolupament ha de contemplar la migració des del principi. Google recomana planificar els canvis d'URL i mantenir redireccions per ajudar a traslladar els senyals de la web anterior.
Quan incorporar el partner tècnic
El millor moment és abans de presentar una proposta tancada al client. Amb la informació suficient, l'agència pot contrastar viabilitat, riscos i fases; després presenta una solució que pot complir sense diluir el seu paper estratègic.
NodraLabs treballa com a equip de desenvolupament extern per a agències de màrqueting i com a partner tècnic per a agències. L'agència manté la seva relació, estratègia i marca; nosaltres ajudem a convertir aquesta informació en una web que es pugui dissenyar, construir, mesurar i mantenir.
Si la teva agència treballa especialment amb identitat i disseny, també pots comptar amb desenvolupament que respecti aquesta part en projectes per a estudis de branding i disseny.
Preguntes freqüents
Quina informació necessita un equip de desenvolupament per pressupostar una web?
Necessita entendre el negoci, l'objectiu, el públic, el contingut, el disseny disponible, la funcionalitat, les integracions i qui decideix cada part. Amb aquesta informació pot proposar abast, fases, termini i pressupost.
Qui prepara la informació inicial d'una web?
L'agència la pot liderar perquè coneix el client, la marca i l'estratègia. El partner tècnic l'ha de revisar abans de pressupostar per completar riscos, dependències i decisions d'implementació.
Cal tenir el disseny a Figma abans de demanar pressupost?
No sempre. Un disseny ajuda a estimar, però un bon pressupost també pot incloure una fase d'UX/UI. Si ja existeix Figma, convé indicar quines pantalles estan tancades i quins comportaments o mides encara s'han de decidir.
Què cal preparar per migrar una web?
A més dels objectius i de la nova estructura, cal reunir el domini i CMS actuals, URLs rellevants, pàgines amb trànsit, contingut que es conserva, idiomes, integracions i accessos. Així es pot planificar la migració i les redireccions abans del llançament.
Què convé recordar
- La informació inicial ha de descriure el problema, el resultat i les decisions pendents; no ha d'imposar la tecnologia.
- Objectiu, públic, contingut, funcionalitat, SEO, responsables i criteris d'acceptació canvien l'abast d'una web.
- Marcar una incògnita és millor que omplir-la amb una suposició que es converteixi en sobrecost.
- Involucrar desenvolupament abans de tancar la proposta protegeix la relació de l'agència amb el seu client.
Fonts i referències
Enric Robert · Fundador de NodraLabs
Més de 6 anys creant software i productes digitals. Estratègia, UX/UI i desenvolupament, de principi a fi.
Perfil a LinkedIn