Del briefing a la puesta en línea: lo que de verdad implica un proyecto web

La decisión suele tomarse deprisa: la web antigua parece anclada en el pasado, la competencia luce visiblemente más moderna, hace falta una nueva presencia. Entre esa decisión y el día en que la nueva página entra en línea media, sin embargo, un proyecto de verdad — con fases, dependencias y decisiones que muchos clientes subestiman la primera vez. Quien conoce el proceso planifica de forma más realista, compara mejor las ofertas y se ahorra frustraciones en ambos lados.

Transparencia por adelantado: este artículo se publica como anuncio, y los ejemplos citados proceden de la práctica de proyectos de la agencia web BitBau de Osnabrück (en alemán). Los procesos descritos son, no obstante, habituales en el sector — valen en gran medida con independencia del proveedor con el que una empresa acabe trabajando.

Al principio no está el diseño, sino una conversación. En el briefing, una buena agencia aclara primero cuestiones que nada tienen que ver con colores y tipografías: ¿qué debe aportar la web a la empresa? ¿Quién debe visitarla, y qué deben hacer allí esas personas — llamar, rellenar un formulario, reservar una cita, comprar algo? ¿Con qué se medirá el éxito dentro de un año? Quien no tiene respuestas a estas preguntas acaba con una página bonita, pero sin rumbo.

Al briefing pertenece también un inventario sobrio: ¿qué contenidos existen ya, cuáles deben crearse de cero? ¿Qué sistemas hay que conectar — reserva de citas, boletín, gestión de mercancías? ¿Existen directrices del diseño corporativo? Y, no menos importante: ¿quién decide en la empresa, y quién aporta material? Esta última pregunta suena banal, pero decide más adelante semanas enteras del calendario.

Los clientes pueden prepararse de forma deliberada para esa primera conversación — y con ello se ahorran a menudo la primera ronda de correcciones. Ha dado buen resultado una carpeta sencilla: los datos de acceso al dominio y al hosting actual, el logotipo en calidad apta para imprenta, los textos, imágenes y folletos existentes, una lista de los principales competidores y tres ejemplos de webs que gustan — y, al menos igual de revelador, tres que no gustan, cada una con una breve justificación. Quien anota además por qué canales llegan hoy las consultas y cuáles de ellas se convierten en encargos da a la agencia una imagen realista de lo que la nueva página debe mejorar de verdad. Nada de esto es obligatorio; todo esto ahorra horas facturables.

Al briefing le sigue la fase de concepto. Aquí nacen la estructura de páginas, la lógica de navegación y los primeros esbozos de las páginas más importantes, los llamados wireframes — deliberadamente toscos, sin colores ni imágenes. Tiene su razón: sobre una estructura se puede discutir barato sobre el papel. Si el mismo error de planteamiento se descubre en el diseño terminado o incluso en el estado ya programado, la corrección cuesta varias veces más.

Solo después comienza el diseño propiamente dicho. El diseño orientado a la experiencia de uso no significa «hacerlo más bonito», sino tomar las decisiones de forma consecuente desde la perspectiva de los usuarios. ¿Qué información va arriba? ¿Cuántos clics separan la página de inicio del contacto? ¿Funciona la página en el smartphone con la misma naturalidad que en la pantalla grande? El buen diseño no llama la atención de los visitantes — el malo, al instante.

En esta fase se decide también con qué fluidez avanza el proyecto, y sorprendentemente a menudo del lado del cliente. Un feedback compuesto por cinco correos contradictorios de distintos departamentos cuesta rondas. Se ha acreditado una regla sencilla: una persona recoge internamente todas las observaciones, aclara las contradicciones y las transmite agrupadas. Los proyectos con una vía de decisión clara se terminan sensiblemente antes que los proyectos con comités.

Ayuda además tomarse en serio las aprobaciones. Un proyecto bien llevado trabaja con hitos: primero se aprueba la estructura, luego el diseño, luego la página implementada. Cada aprobación es un acuerdo — lo que una vez se ha dado por bueno no se vuelve a abrir de pasada en la fase siguiente. Naturalmente, los cambios tardíos siguen siendo posibles; solo que no son gratuitos, porque devalúan trabajo ya terminado. Los proveedores serios lo dicen abiertamente y ponen cifra a los cambios antes de ejecutarlos, en lugar de añadirlos en silencio a la factura final. A los clientes, por su parte, les va bien implicar antes de cada aprobación exactamente a las personas cuyas objeciones saldrían caras después — y sostener luego su decisión.

El desarrollo en sí es para los clientes la fase más invisible. De los borradores aprobados nacen componentes; de los componentes, páginas; en segundo plano surgen el sistema de redacción, el procesamiento de formularios y las interfaces. Que durante semanas aparentemente «no haya nada que ver» inquieta a algunos clientes. Los proveedores serios muestran por eso avances intermedios con regularidad en un entorno de pruebas, en lugar de presentar al final una gran sorpresa — para bien o para mal.

El cuello de botella más subestimado de un proyecto web no es, sin embargo, ninguna técnica, sino el contenido. Textos, fotos, retratos del equipo, datos de producto, traducciones: todo eso lo tiene que entregar alguien, y ese alguien es casi siempre el cliente. La experiencia enseña que los contenidos que faltan retrasan los proyectos con más frecuencia que cualquier obstáculo técnico. Quien se toma en serio la nueva web empieza con los textos el primer día — no en la última semana.

Antes de la puesta en línea llega la fase de pruebas: distintos navegadores y dispositivos, cada formulario, cada redirección, tiempos de carga, accesibilidad básica. A ella pertenece también la parte poco espectacular — redirecciones limpias de las direcciones antiguas a las nuevas, para que la visibilidad en buscadores construida con esfuerzo no se pierda de la noche a la mañana. El lanzamiento en sí es entonces, en el mejor de los casos, una mañana tranquila. Las semanas anteriores deciden si lo sigue siendo.

Para los últimos días antes de la puesta en línea ha dado buen resultado una lista de comprobación sobria. ¿Están el Impressum (el aviso legal) y la declaración de privacidad al día con la nueva página? ¿Llegan las entradas de los formularios al buzón correcto — y hay alguien allí que responda? ¿Existe una página de error digna para las direcciones que ya no existen? ¿Está la web antigua completamente respaldada por si algo sale mal? ¿Y está claro quién pulsa el proverbial botón y cuándo, y quién permanece localizable en las horas siguientes? También forma parte un consejo poco espectacular pero acreditado: la puesta en línea corresponde a una mañana entre semana — no a un viernes por la tarde, tras el cual los problemas sin descubrir pueden desplegarse sin estorbo durante todo un fin de semana.

¿Y después? Una web no es una obra cerrada como un catálogo impreso. Actualizaciones de seguridad, pequeñas correcciones, contenidos nuevos, un vistazo a las cifras de visitantes: quien no regula la operación tiene en dos años otra vez una página anticuada. Al cierre del proyecto pertenece por eso una conversación honesta sobre quién se ocupará en adelante — el proveedor, el propio equipo o ambos juntos con un reparto claro de tareas.

También las primeras semanas tras el arranque merecen atención. Los buscadores tienen que evaluar de nuevo la página; las posiciones pueden oscilar temporalmente antes de asentarse — eso es normal y no una señal de alarma, mientras las redirecciones estén bien puestas. Lo valioso en esta fase son sobre todo las reacciones de usuarios reales: clientes que no encuentran algo, empleados que detectan incoherencias, consultas que llegan de forma distinta a la esperada. Una pequeña lista de correcciones en las primeras semanas no es, por eso, un defecto del proyecto, sino el momento en que las suposiciones se convierten en conocimiento práctico — y la web entregada, en una herramienta que se mide con el día a día.

¿Cuánto dura todo esto? Tres ejemplos de la práctica de BitBau muestran la horquilla realista. La web de la Praxis am Salzmarkt — una presencia para una consulta médica, íntegramente en tres idiomas — nació en doce semanas. ScanYou, una herramienta para pruebas visuales comparativas automatizadas de webs, necesitó dieciséis semanas. QR2GO, una plataforma de códigos QR con funciones de análisis, estuvo lista al cabo de veinticuatro semanas.

Las diferencias no se explican por la diligencia, sino por el alcance: una página de presentación con contenidos bien delimitados se termina antes que un producto de software con cuentas de usuario y evaluaciones. Como regla general para proyectos profesionales en la pequeña y mediana empresa, de doce a veinticuatro semanas son un marco honesto — según el alcance funcional, el número de rondas de feedback y la velocidad con que se entreguen los contenidos.

Las ofertas que prometen una «web profesional en una semana» no comprimen estas fases — las suprimen. Casi siempre desaparece el concepto, el diseño procede de una plantilla, apenas se prueba y los contenidos se trasladan sin examen desde la página antigua. Para ciertos fines eso puede bastar por completo. Solo que nadie debería esperar obtener con ello el mismo resultado que con un proyecto bien pensado.

De dinero se habla en textos como este rara vez en concreto, y con buena razón: los precios serios nacen del alcance, no al revés. La respuesta honesta a la pregunta «¿cuánto cuesta una web?» es: depende de lo que deba saber hacer. La desconfianza está más justificada ante precios cerrados que se dan sin una sola conversación sobre objetivos y contenidos — de algún sitio tiene que salir ese cálculo.

Los clientes pueden hacer mucho para que su proyecto se mantenga en plazo y presupuesto: entregar los contenidos pronto, agrupar el feedback, no aplazar las decisiones — y tener el valor de dejar fuera funciones para la primera puesta en línea. Una web que arranca con un núcleo limpio y crece después vence en la práctica casi siempre al proyecto mastodóntico que un año más tarde sigue sin estar en línea.

También la elección del proveedor se deja comprobar con unas pocas señales. ¿Hace la agencia en la primera conversación preguntas sobre el negocio — o solo habla de diseño? ¿Existe un proceso comprensible con avances intermedios en un entorno de pruebas? ¿A quién pertenecen al final el código, el dominio y los contenidos? ¿Qué ocurre tras la puesta en línea, y cuánto cuesta? Quien reciba respuestas evasivas a estas preguntas debería seguir buscando.

Que el proveedor esté a la vuelta de la esquina o en el otro extremo del espacio germanohablante es hoy sobre todo una cuestión de método de trabajo. BitBau, por ejemplo, atiende personalmente in situ a empresas en un radio de unos treinta kilómetros alrededor de Osnabrück y trabaja a distancia con clientes de Alemania, Austria y Suiza — con los mismos procesos, entornos de prueba y avances intermedios. Lo decisivo no es la distancia, sino si el proceso se sostiene.

Queda la conclusión más importante: un proyecto web es un proyecto de negocio normal. Necesita un objetivo, un responsable, un calendario realista y la disposición a tomar decisiones. Quien lo trata así — y elige un socio que explica abiertamente su forma de trabajar — no recibe al final una obra de arte, sino algo mejor: una herramienta que trabaja cada día para la empresa.