Cómo redactar un briefing para una web: ocho puntos en vez de cuarenta páginas

Para qué un briefing si el desarrollador ya lo entendió

De palabra, al empezar un proyecto todo el mundo está de acuerdo. La discrepancia aparece en la entrega, cuando resulta que catálogo significaba veinte fichas para una parte y veinte con filtros, comparador y exportación de existencias para la otra.

Un briefing no está para atar de manos al desarrollador. Está para que ambas partes entiendan a la vez qué se construye, y para que tres meses después haya con qué contrastar aparte de la memoria.

Un buen briefing es más corto de lo que se cree. Ocupa unas páginas y no cuarenta, y se compone casi enteramente de decisiones y no de descripciones.

Abajo va qué contiene, en qué orden, y los tres sitios donde más se descuadran los plazos. Escrito desde el lado del cliente: es un documento que haces tú, no uno que te llega para firmar.

Qué no debe aparecer en un briefing

Empecemos por lo que suele ocupar la mitad del documento sin aportar nada.

La elección de tecnología. Si no eres desarrollador, exigir un framework concreto reduce el número de proveedores sin mejorar el resultado. Una sola excepción: ya tienes un equipo que lo va a mantener.

Describir el diseño con palabras. Moderno, con estilo, que enganche no se puede ni ejecutar ni comprobar. En su lugar, tres o cuatro enlaces a webs que te gusten y una línea sobre qué te gusta de cada una.

Listas de funciones copiadas de una plantilla. Expresiones como navegación intuitiva o diseño adaptable no concretan nada: son el mínimo, no un requisito, y en un briefing solo diluyen lo que de verdad importa.

Todo lo que no estés dispuesto a comprobar en la entrega. Un punto sobre el que no puedas decir hecho o no hecho no funciona en un briefing.

Por dónde empieza: el objetivo, no la lista de páginas

La primera página del briefing no es la estructura de la web. Es la respuesta a qué debe cambiar en el negocio después del lanzamiento.

La formulación tiene que poder comprobarse. No aumentar la notoriedad, sino recibir solicitudes de presupuesto desde la web, que ahora solo llegan por teléfono. No estar en internet, sino enseñar el catálogo que hoy mandamos como archivo.

Después, quiénes son esas personas. Uno o dos tipos de visitante, y de cada uno: con qué pregunta llega, qué debe hacer y qué se lo impide hoy.

Esta sección ocupa media página y determina todo lo demás. Una lista de páginas hecha sin ella sale siempre o más larga de lo necesario o apuntando a otro sitio.

La comprobación es sencilla: si de la primera página del briefing no se deduce para qué sirve cada página listada después, vuelve a ella.

La lista de páginas y cómo saber que está completa

Ahora la estructura. Enumera las páginas, una línea cada una, y al lado para qué sirve.

Marca aparte las páginas que existirán en cantidad con la misma construcción: fichas de producto, servicios, artículos. Describe una: el resto se hacen según ese patrón, y sale bastante más barato que veinte diseños individuales.

No olvides las páginas de servicio: la de error, la de formulario enviado, la política de datos. Casi siempre se pasan por alto y luego se hacen con prisas.

La integridad se comprueba al revés: recorre la lista de objetivos de la primera sección y confirma que cada uno tiene una página donde se resuelve. Y a la inversa: que cada página tiene un objetivo.

Si una página no está ligada a ningún objetivo, o sobra, o has encontrado un objetivo que olvidaste anotar.

Los datos: la sección que más se salta

Aquí es donde más divergen las expectativas y el precio, porque la sección parece aburrida y se escribe la última.

Todo lo que en una web existe en plural vive en una tabla: productos, servicios, inmuebles, profesionales, artículos. Cada uno de esos conjuntos necesita tres cosas.

Cuántos hay ahora y cuántos habrá dentro de un año. La diferencia entre cien y mil es una diferencia de planteamiento, no de volumen de trabajo.

Qué campos tiene cada registro. Escríbelos uno a uno: nombre, precio, fotografías, características, disponibilidad. Esa lista determina los filtros, el aspecto de la ficha y la complejidad.

Y de dónde salen los datos: se introducen a mano, se exportan de un sistema de gestión o llegan del proveedor como archivo. Un a mano para mil artículos significa que hace falta un importador, y conviene saberlo antes y no después.

Integraciones: nómbralas

La lista de sistemas externos con los que la web debe hablar. No integración con un CRM, sino el nombre del CRM.

De cada uno, qué debe pasar y en qué dirección. La solicitud va al CRM. Las existencias llegan del sistema de gestión cada hora. El pago pasa por un banco concreto. El aviso llega a una app de mensajería.

Marca aparte a qué ya tienes acceso y qué hay que dar de alta. Esperar accesos es la causa más frecuente de parón a mitad de proyecto, y no depende del desarrollador.

Y una pregunta que conviene hacer pronto: qué debe pasar si el sistema externo no responde. Una solicitud perdida por el silencio de un servidor ajeno tiene para el cliente exactamente el mismo aspecto que una que nunca se envió.

Qué pasa con la web antigua

Esta sección la necesita todo el que ya tiene web, y casi todos se la saltan.

Las direcciones antiguas no desaparecen con la web antigua. El buscador las recuerda durante años, hay páginas ajenas que enlazan a ellas y están en los marcadores de alguien. Tras el lanzamiento, cada una de esas direcciones o lleva a algún sitio con sentido o devuelve un error.

En nuestra propia mudanza desde la plataforma anterior resultaron ser 673 direcciones. Hubo que repasarlas una a una, porque la decisión sobre cada una es de contenido: ¿hay en la web nueva una página que responda a lo mismo?

Por eso el briefing necesita un punto: exportar la lista de direcciones de la web antigua y dibujar el mapa antes de empezar el desarrollo. La lista se saca de dos sitios, el sistema antiguo y la consola de búsqueda, porque no coincidirán.

Cuesta unos días de trabajo y ahorra meses de recuperación de posiciones.

Quién aporta qué

Una tabla corta que evita más discusiones que todo el resto del documento junto.

Textos: los escribe el cliente, el desarrollador o un redactor aparte. Si es el cliente, pon fecha, porque los textos casi siempre llegan los últimos y retienen el lanzamiento.

Fotografías: hay propias, hace falta sesión o se tiran de banco de imágenes. Cada opción tiene su coste y su plazo.

Accesos: dominio, alojamiento, correo, analítica, sistema de gestión. Reúnelos pronto y comprueba que funcionan: la contraseña de un dominio registrado hace siete años a nombre de un exempleado tarda en aparecer.

Mantenimiento tras el lanzamiento: quién da de alta productos y escribe noticias. Una web que nadie tiene asignada envejece en un trimestre, esté hecha como esté.

Cómo se acepta el trabajo

La sección que menos se escribe, y la que decide cómo termina el proyecto.

Los criterios de aceptación deben poder comprobarse con las dos partes delante. La web funciona correctamente no es un criterio. La solicitud del formulario llega al correo indicado y al CRM en menos de un minuto sí lo es.

Acordad de antemano sobre qué se comprueba. Una lista de dispositivos y navegadores, y dos o tres tareas reales que un visitante deba completar de principio a fin.

Aparte: qué cuenta como fallo y qué como cambio. Un fallo se corrige dentro del trabajo acordado; un cambio se presupuesta aparte. Sin esa línea, cualquier desacuerdo se convierte en una negociación de dinero.

Y fija el plazo durante el cual se corrigen fallos tras el lanzamiento. Un mes es razonable; el soporte gratuito de por vida no existe y simplemente va en el precio.

Tres sitios donde se descuadran los plazos

En la práctica casi todos los retrasos ocurren donde no se esperan.

Los textos. Se escriben los últimos y lo retienen todo. La solución es escribirlos en paralelo al desarrollo y entregarlos por páginas, no de golpe.

Los accesos. Se consiguen más tarde de lo que parece, sobre todo los bancarios y los de gestión. Hay que empezar a reunirlos el día de la firma.

La aprobación dentro del cliente. Si deciden tres personas y se reúnen cada dos semanas, cada corrección cuesta dos semanas. Nombra a una persona cuya palabra sea la última: es la medida de aceleración más barata que existe.

Una plantilla de una página

Si prefieres no escribir un documento desde cero, este es el mínimo que cubre la mayor parte del riesgo.

El objetivo de negocio y uno o dos tipos de visitante. La lista de páginas con la finalidad de cada una. Los conjuntos de datos con sus campos y su volumen. Los sistemas externos por su nombre y la dirección del intercambio. El destino de las direcciones antiguas. Quién aporta qué y para cuándo. Los criterios de aceptación. La línea entre fallo y cambio.

Ocho puntos, tres o cuatro páginas. Basta para recibir propuestas comparables de distintos proveedores y para que tres meses después la conversación vaya del trabajo y no de qué quiso decir cada uno.

Y una última cosa: un briefing escrito por el cliente es casi siempre mejor que uno enviado por el desarrollador, no porque el cliente sepa más, sino porque solo él sabe para qué es todo esto.