Encargar una web empieza por una decisión sencilla de expresar: qué debe poder entender o hacer una persona cuando llegue. A partir de ahí se concretan los contenidos, las funciones, la forma de editarlos y las comprobaciones de entrega. Elegir una tecnología o aprobar una portada viene después.
Esta guía te lleva desde esa primera necesidad hasta una web que puedes revisar, publicar y mantener. Puedes traer un proyecto ya definido o necesitar ayuda para ordenar lo que falta. No hace falta convertirte en programador para dar un buen encargo; sí hace falta que las decisiones importantes sean visibles.
El recorrido que vas a completar
| Momento | Decisión que necesitas tomar | Resultado que debe quedar |
|---|---|---|
| Antes de pedir propuestas | Para quién es la web y qué tarea facilita | Propósito, destinatario y acción principal |
| Al definir el encargo | Qué contenidos y comportamientos incluye | Mapa de páginas, funciones y límites |
| Antes de elegir solución | Quién editará y qué necesita cambiar | Una tarea de edición probada y requisitos de continuidad |
| Al comparar presupuestos | Qué ofrece cada propuesta sobre el mismo alcance | Incluido, excluido, pendiente y coste desglosado |
| Durante la construcción | Qué revisar en cada avance | Recorridos, decisiones y correcciones concretas |
| Antes de publicar | Qué debe funcionar y quién se hace cargo | Pruebas, accesos, publicación y salida ante fallos |
| Después de lanzar | Qué observar y qué mantener | Responsables, copias, revisiones y datos interpretables |
Puedes seguir el orden completo o entrar por la decisión que tengas abierta. Al final encontrarás el constructor de briefing, dos ejemplos reutilizables y una web de servicios demostrativa que permite recorrer estas decisiones.
Empieza por la persona que llegará
Una web de servicios no se define por tener Inicio, Nosotros y Contacto. Se define por la información que una persona necesita antes de contactar y por lo que ocurrirá después.
Prueba a completar esta frase:
Una persona que está en [situación] necesita [comprender o hacer algo]. La web le ayudará mostrando [información o prueba] y permitiendo [acción].
No es una fórmula para redactar un eslogan. Es una forma de comprobar si el encargo tiene un propósito que se puede revisar. “Que se vea más moderna” puede ser una preferencia válida, pero no dice qué información falta ni qué debería funcionar mejor.
En esta guía usamos Estudio Ladera, un estudio de interiorismo ficticio. El ejemplo existe para aprender; sus propuestas visuales y su formulario son demostrativos, no trabajos ni contactos de un cliente real.
Su frase de partida es esta: una persona que prepara una reforma necesita distinguir entre asesoría de una estancia, proyecto de interiorismo y acompañamiento de ejecución. La web debe ayudarle a elegir qué consulta hacer, ver dos propuestas ilustrativas y explicar su necesidad.
Esta definición descarta decisiones innecesarias para la primera entrega: no hace falta una tienda, una zona de clientes ni un sistema de reservas para que ese recorrido funcione. Tampoco impide añadirlos más adelante si aparece una necesidad concreta.
Decide qué tipo de web resuelve ese trabajo
El tamaño de una web no se entiende contando pantallas. Una página con una agenda y pagos puede exigir más reglas y comprobaciones que diez páginas informativas.
Piensa en tres capas:
- Información: qué servicios, contenidos, productos o ejemplos se consultan.
- Acción: qué puede hacer la persona además de leer.
- Funcionamiento posterior: quién recibe, modifica, valida o utiliza el resultado.
En Ladera, la información son servicios y propuestas; la acción es preparar una consulta; el funcionamiento posterior de una web real sería entregar esa consulta a un responsable. En la demo se sustituye ese último paso por una confirmación local claramente rotulada.
Si la tarea principal consiste en trabajar repetidamente con datos, cuentas, permisos o reglas propias, quizá estás definiendo una aplicación. La diferencia cambia la especificación, las pruebas y el mantenimiento; no convierte a una opción en mejor que otra. El artículo sobre tipos de web y alcance compara varios encargos sobre el mismo negocio.
Separa contenido de funciones
Haz primero un mapa de contenidos. Para cada página anota la pregunta que responde, la información que necesita y quién puede aprobarla.
| Página del ejemplo Ladera | Pregunta del visitante | Material necesario |
|---|---|---|
| Inicio | ¿Qué puedo resolver aquí? | Presentación y acceso a servicios |
| Servicios y detalles | ¿Qué incluye esta forma de ayuda? | Alcance, aportaciones y límites de cada servicio |
| Propuestas ilustrativas | ¿Cómo se ve una decisión de diseño? | Dos ejercicios propios, contexto y alternativas |
| Cómo se trabaja | ¿Qué tendré que decidir y aportar? | Proceso de definición, revisión y entrega |
| Contacto | ¿Qué debo contar y qué ocurrirá? | Campos mínimos, destino y estados del formulario |
Después describe las funciones con un pequeño escenario. Por ejemplo: “Desde un servicio, la persona abre contacto; el servicio queda seleccionado; si falta el mensaje se explica qué corregir; si el envío real falla no se muestra una confirmación falsa”.
Esa descripción sirve para presupuestar y también para probar. “Formulario incluido” deja abiertas cuestiones como el destino, el correo de confirmación, el tratamiento de errores, el spam o la conservación de los datos.
No atribuyas por inercia textos, fotografías, traducciones, dominio o revisión legal al desarrollo. Escribe quién prepara y quién aprueba cada material. Una dependencia puede ser pequeña en el presupuesto y decisiva para la publicación.
Haz visibles las decisiones abiertas
Un briefing útil admite dudas. Puedes clasificar cada entrada de esta forma:
- Decidido: una condición que la propuesta debe respetar.
- Preferido: una dirección que puede cambiar si existe una razón mejor.
- Pendiente: una cuestión que necesita información o recomendación.
En Ladera está decidido que habrá tres servicios y un idioma. La dirección visual cálida es una preferencia. El gestor de contenidos queda pendiente hasta saber quién lo editará y con qué frecuencia.
No rellenes un pendiente con una tecnología que has oído nombrar. Formula la pregunta que permitirá resolverlo: “¿Podré añadir una propuesta ilustrativa sin depender de quien desarrolló la web?”. Esa pregunta es más útil para elegir un CMS que una lista de marcas.
El briefing cumplimentado de Ladera muestra cómo queda el documento completo. La plantilla reutilizable permite preparar el tuyo con la misma estructura.
Elige la plataforma haciendo una tarea de edición
La elección depende de qué habrá que cambiar después, quién lo hará y qué margen de error resulta aceptable.
Pide una pequeña demostración de edición con contenido representativo: corregir un servicio, sustituir una imagen y añadir una nueva propuesta. Observa qué puede cambiar la persona editora, qué está protegido y cómo se revierte un error.
Una web con cambios muy ocasionales puede funcionar con archivos y soporte de desarrollo. Una publicación frecuente suele necesitar una interfaz de edición. Un catálogo con campos y relaciones exige pensar en contenido estructurado. Un CMS desacoplado puede separar edición y presentación, pero también añade piezas que alguien debe operar.
Estas son decisiones de encaje, no una clasificación de herramientas buenas y malas. La comparación de plataformas y CMS incluye un guion para probar la edición y revisar continuidad.
Antes de cerrar, pregunta qué podrás exportar: textos, imágenes, estructura, datos y código no siempre tienen el mismo tratamiento. El acceso a una cuenta y los derechos sobre sus contenidos son asuntos distintos.
Compara una propuesta contra el encargo
Una propuesta debería explicar qué entrega, con qué límites y cómo se comprobará. El precio adquiere sentido cuando se conocen esas condiciones.
En el ejemplo Ladera, pide que se separen definición, diseño, contenido, desarrollo, migración si existe, pruebas y puesta en marcha. Añade alojamiento, dominio, licencias, mantenimiento y aportaciones del cliente como costes o responsabilidades diferenciados.
Comprueba cuatro preguntas especialmente útiles:
- ¿Qué información todavía puede cambiar la estimación?
- ¿Qué resultado concreto corresponde a cada partida?
- ¿Qué se considera corrección incluida y qué sería un cambio de alcance?
- ¿Qué quedará bajo mi control cuando termine el proyecto?
Una cifra menor puede corresponder a una solución más sencilla que te sirve. También puede dejar fuera contenido, migración o continuidad que sí necesitas. La comparación debe mostrar esa diferencia, no ocultarla dentro de una puntuación.
El artículo de presupuesto web explicado por partidas desarrolla un ejemplo de cálculo y enseña a distinguir coste inicial, recurrente e impuestos. El método sirve para preguntar mejor; los números ilustrativos no sustituyen una propuesta para tu proyecto.
Revisa recorridos durante la construcción
No esperes a que todo esté acabado para probar lo que importa. Tampoco conviertas cada avance en una revisión de píxeles sin propósito.
Para Ladera, una revisión intermedia puede empezar con tres tareas: encontrar el servicio adecuado; entender sus límites; preparar una consulta desde el móvil. Después se revisan estados que una captura no muestra: menú abierto, texto largo, formulario incompleto, mensaje de error y recuperación.
Cuando algo no funcione, describe el recorrido y el resultado:
En el detalle de asesoría, abro contacto desde el móvil. El servicio no aparece seleccionado y tengo que elegirlo otra vez. Esperaba conservar esa elección.
Esto permite localizar una discrepancia concreta. “La página no me convence” puede iniciar una conversación válida, pero necesita traducirse a una decisión de contenido, comportamiento o presentación.
Las pruebas automáticas ayudan a repetir comprobaciones; la revisión humana ayuda a valorar si la explicación se entiende. Ninguna de las dos se convierte, por sí sola, en una prueba de preferencia de usuarios reales.
Acuerda la calidad que vas a comprobar
Incluye accesibilidad, comportamiento móvil, rendimiento y buscadores en el encargo, con alcance y evidencias comprensibles.
Para un formulario, por ejemplo, revisa etiquetas, instrucciones, errores y confirmación, no solo su apariencia. El tutorial de formularios de W3C WAI, consultado el 10/09/2026, explica estos elementos y la necesidad de ayudar a corregir entradas.
Para buscadores, comprueba que las páginas relevantes tienen contenido accesible, enlaces y una identidad de URL coherente. La guía SEO de Google, consultada el 10/09/2026, orienta ese trabajo; no garantiza indexación, posiciones ni tráfico.
Si rediseñas una web existente, protege también lo que ya responde preguntas útiles. Conserva una referencia del contenido y un mapa de rutas antes de tocar la estructura. El recorrido de rediseño muestra un ejemplo.
Una comprobación técnica superada significa que se ha verificado una condición concreta. No demuestra que la web vaya a vender ni que una persona haya entendido todo el contenido.
Publica con responsables y una salida ante fallos
Antes de cambiar la web pública, revisa accesos, destino del formulario, copias, versión que se publica y forma de volver atrás. Haz una comprobación en la URL final: una vista previa correcta no confirma que el dominio público use esa versión.
En una web real, prueba la entrega del formulario con un destinatario autorizado y un mensaje identificado como prueba. Diferencia que el servidor acepte el envío de que el mensaje llegue al buzón esperado. No uses consultas ficticias como oportunidades comerciales.
La web demostrativa de Ladera permite revisar navegación y estados sin enviar nada. Su límite es deliberado: enseña una implementación y sus decisiones, no simula una empresa operativa.
La entrega debería permitir que otro profesional entienda el proyecto: cuentas y titularidad, origen de código cuando corresponda, instrucciones de edición, dependencias, copias, pruebas y decisiones pendientes. No guardes contraseñas dentro del briefing ni de una guía pública.
Después del lanzamiento
Decide quién revisará contenido, errores, actualizaciones y costes recurrentes. No hace falta un panel complejo para una web pequeña, pero sí una persona responsable y una forma de detectar problemas.
Separa lo que observas: una página disponible, una consulta entregada, una conversación pertinente y una venta son hechos distintos. Si mides finalización de una tarea, define qué cuenta como inicio y como resultado; las pruebas deben quedar fuera de la lectura de uso real.
Cuando una función resulte confusa, corrige el recorrido afectado. Cuando cambie un servicio, revisa su contenido. Cuando no haya suficientes datos, conserva la incertidumbre en vez de convertirla en una explicación convincente.
Empieza por preparar tu briefing. Puedes indicar lo que ya sabes, dejar preguntas abiertas y exportar un documento que otra persona pueda revisar contigo.