Crea una pàgina web: checklist per a prendre decisions abans de llançar

Tenir clar que necessites una web no resol les decisions que determinen si després la podràs utilitzar amb tranquil·litat: què ha d'explicar, quina acció ha de facilitar, qui actualitzarà els continguts o què passa quan falla un formulari.

Aquesta checklist per a crear una pàgina web t'ajuda a ordenar aquestes decisions abans d'encarregar el projecte, durant el seu desenvolupament o just abans de publicar- el. En acabar sabrà si pots avançar amb un abast definit, si necessites concretar punts importants o si el projecte requereix una revisió més profunda.

Usa-la marcant cada comprovació com a feta, pendent o no aplicable. No es tracta d'acumular pàgines o funcions: es tracta que el web respongui a un objectiu concret i pugui mantenir-se després del llançament.

Objectiu de la revisió

Abans de triar un disseny, una plantilla o una tecnologia, separa tres decisions:

Per exemple, una empresa pot voler rebre sol·licituds de servei. Aquest és l'objectiu. Les pàgines de serveis, els casos que es puguin publicar, un formulari i una manera d'atendre els contactes formen part de l'abast. El gestor de continguts, el disseny i les integracions són decisions de solució.

Comença per aquesta separació redueix un problema habitual: decidir l'eina abans de saber què heu de resoldre. Si l'objectiu encara s'expressa amb termes vagós com a "teniu presència", convertiu- el en una acció observable, com explicar serveis, rebre consultes, mostrar un catàleg o donar accés a informació per a clients.

Checklist prèvia

Completa aquest bloc abans de demanar una proposta o de començar a construir. Les respostes no han de ser definitives en tots els detalls, però els dubtes que afectin l'abast han de quedar visibles.

• [ ]He definit l'objectiu principal. Puc explicar què ha de facilitar la web: consultes, reserves, sol·licituds, presentació de serveis, venda online o una altra acció concreta.
• [ ]He identificat a les persones que la faran servir. Distingeix, almenys, entre qui visita la web i qui la gestionarà dins de l'empresa.
• [ ]He escollit una acció principal per recorregut. Sé què hauria de poder fer una persona després de llegir una pàgina rellevant: contactar, demanar informació, consultar un servei o iniciar un altre procés.
• [ ]He llistat les pàgines necessàries. No només una pàgina d'inici: també serveis, contacte, informació corporativa, àrees privades, catàleg o altres seccions si apliquen.
• [ ]He revisat els continguts disponibles. Sé quins textos, imatges, documents, productes o dades existeixen i quins s'ha de preparar.
• [ ]He assignat responsables. Cada contingut rellevant té una persona que el prepara, revisa i aprova.
• [ ]He separat l'imprescindible del desitjable. Les funcions o pàgines que poden esperar no es presenten com a necessàries per a la primera versió.
• [ ]He identificat restriccions. Dates rellevants, eines ja utilitzades, idiomes, dependències externes, requisits interns o necessitats de migració estan anotats.

Una pàgina web pot semblar senzilla fins que es concreta què ha de contenir. Per exemple, «incloeix un formulari» no defineix els seus camps, el destinatari dels missatges, la confirmació que veurà la persona ni què ha de succeir si l'enviament falla. Aquests detalls són part de l'abast, no un ajust menor.

Checklist funcional

Aquest bloc comprova que el web serveix per realitzar les accions previstes. Reviseu- el amb exemples reals d'ús, no només mirant una maqueta.

• [ ]La proposta de cada pàgina s'entén ràpid. El títol i els primers continguts expliquen què oferies o què pot trobar la persona.
• [ ]La navegació permet arribar a l'important. Les seccions principals són localitzables i els noms del menú no depenen de termes interns o ambigus.
• [ ]Cada pàgina rellevant té un següent pas clar. No totes necessiten el mateix, però cap hauria de deixar a la persona sense saber com continuar.
• [ ]Les dades de contacte són correctes i estan actualitzades. Revisa telèfons, correus, adreces, horaris i enllaços externs si n'hi hagués.
• [ ]Els formularis recullen només la informació necessària. Cada camp té una finalitat i l'equip sap qui rebrà i atendrà les sol·licituds.
• [ ]El formulari confirma el resultat. Després d'un enviament correcte, la persona rep una confirmació visible; si hi ha un error, entén què ha de corregir o quina alternativa té.
• [ ]Els continguts comercials responen a dubtes concrets. expliquen serveis, condicions operatives o processos amb la precisió que necessita qui està valorant contactar.
• [ ]La gestió interna està prevista. Saps quins continguts podreu editar, qui tindrà accés i quins canvis requeriran suport tècnic.

Si incorporeu reserves, pagaments, comptes de client, pressupostos configurables o regles específiques, convé descriure cada flux passa a pas. Indica què introdueix la persona, quines validacions existeixen, quins missatges rep i què succeeix en les excepcions. Una funció nomenada sense aquest recorregut encara no està prou definida.

Checklist tècnica

La revisió tècnica no exigeix que coneguis la implementació, però sí que puguis demanar comprovacions comprensibles i acordar qui es fa càrrec de cada aspecte.

• [ ]La web es revisa en mòbil, tauleta i ordinador. El contingut continua sent llegible, els botons es poden utilitzar i els formularis es completen sense obstacles evidents.
• [ ]Les pàgines importants carreguen i mostren el seu contingut correctament. Comprova especialment imatges, documents, vídeos, formularis i elements que depenguin de serveis externs.
• [ ]Els enllaços interns i externs funcionen. No porten a pàgines inexistents, destinacions incorrectes ni documents que ja no estan disponibles.
• [ ]Els accessos estan controlats. Els comptes de domini, allotjament, gestor de continguts i serveis connectats tenen un titular identificat i accessos recuperables.
• [ ]S'han definit còpies de seguretat. ha d'estar clar què es guarda, amb quina freqüència i com es recuperaria la web davant d'un incident.
• [ ]Les actualitzacions tenen responsable. El sistema, els seus components i les integracions requereixen una forma de revisar canvis i corregir incompatibilitats.
• [ ]Les dades enviades per formularis tenen un recorregut definit. Saps on arriben, qui pot consultar-les i què fer si el destí deixa de funcionar.
• [ ]S'han revisat els requisits aplicables als teus continguts i dades. Si el web recull dades personals, ven productes o presta serveis subjectes a obligacions específiques, valida els textos i processos amb la persona professional competent.

També convé acordar criteris d'acceptació. En comptes d'aprovar "el formulari funciona", useu una comprovació concreta: en completar els camps obligatoris amb dades vàlides, apareix un missatge de confirmació i la sol·licitud arriba al destinatari definit. Si manca una dada obligatòria, s'indica quina és sense esborrar la resta de la informació introduïda.

Checklist de manteniment

Pública no tanca el treball. Una web perd utilitat quan els continguts, accessos o dependències es queden sense responsable. Aquest bloc serveix per preparar l'operació posterior.

• [ ]Hi ha una persona responsable de revisar el web. té accés als comptes necessaris o sap com sol·licitar-ho.
• [ ]Existe una rutina per actualitzar continguts. Serveis, dades de contacte, equip, documents, productes i avisos es revisen quan canvien.
• [ ]S'ha decidit com atendre incidències. Està definit què es considera una incidència, a qui es comunica i quina informació convé aportar.
• [ ]S'han de controlar renovacions i serveis externs. Domini, allotjament, llicències o eines connectades tenen un responsable i una via d'avís.
• [ ]Els canvis futurs es registren per prioritat. Distingides entre correccions urgents, millores desitjables i funcionalitats per a una fase posterior.
• [ ]La documentació mínima està disponible. Accessos, titularitat de comptes, forma d'actualitzar continguts i dependències rellevants no queden només en la memòria d'una persona.

No tots els projectes requereixen el mateix nivell de manteniment. Una web informativa amb contingut estable tindrà necessitats diferents d'una botiga, un portal per a clients o una web connectada a eines de gestió. La decisió útil és deixar clar què necessites conservar, revisar i evolucionar, i qui ho farà.

Com interpretar el resultat

Compta les comprovacions marcades com a fetes. Si un punt no aplica de veritat, exclueix- lo del total en comptes de marcar- el com a complert. Després interpreta el resultat juntament amb la naturalesa dels pendents.

• La majoria està feta i no hi ha pendents crítics: pots avançar cap al llançament o la definició tècnica. Documenta les decisions preses perquè no es perdin en converses soltes.
• Hi ha diversos pendents de contingut, objectiu o responsables: encara no convé tancar l'abast. Resol primer què ha d'explicar la web, qui aportarà la informació i quina acció ha de completar cada visitant.
• Hi ha pendents funcionals o tècnics crítics: aturin la publicació fins a revisar-los. Un formulari sense destinatari, accessos sense titular clar, enllaços trencats o manca de còpies de seguretat són exemples d'assumptes que requereixen solució abans de dependre de la web.
• Han aparegut regles, usuaris, dades o integracions no previstes: probablement el projecte ha deixat de ser una web merament informativa. Divideix l'abast, prioritza una primera versió i vàlida si necessites una solució més personalitzada.

La checklist no substitueix una revisió tècnica, legal o de negoci quan el teu cas la requereix. la seva funció és que arribis a aquesta conversa amb les preguntes adequades i amb decisions que es puguin comprovar.

Si, en completar la llista, segueixes sense tenir clar quin abast necessita el teu projecte o com encaixar una funció concreta, pots explicar el teu projecte de desenvolupament web a AVSISTEC per valorar les necessitats abans de decidir la solució.