Desarrollo web y de aplicaciones

Web corporativa, aplicación de gestión y tienda: tres necesidades que la palabra «web» confunde

En resumen: Una web corporativa publica información, una aplicación hace avanzar un trabajo y una tienda cobra y gestiona todo lo que sigue al pedido. El número de páginas no dice nada sobre la dificultad: lo que cuenta es cuánto estado debe sostener el programa y cuántas reglas debe hacer respetar.

La palabra «web» designa indistintamente objetos cuyos puntos en común se reducen a una dirección y a un navegador. Se distinguen mal porque se comparan por su apariencia, mientras que lo que los separa no se ve. Una página que presenta una actividad se limita a mostrarse: dice lo mismo a todo el mundo y no retiene nada. Un formulario de reserva, en cambio, debe saber qué está ya ocupado, rechazar lo que ya no lo está, guardar constancia de lo decidido y comportarse correctamente cuando dos personas pulsan en el mismo instante. El segundo caso contiene un estado que cambia, y por tanto conflictos posibles, permisos de acceso, historial y reglas de coherencia. Ahí están el esfuerzo y los defectos, y no en el número de páginas ni en la riqueza del diseño gráfico.

La web corporativa publica. Su objeto es ser encontrada, comprendida y hacer posible un contacto; no modifica casi nada y su valor reside en la claridad de lo que dice. Sus dificultades son, por tanto, editoriales antes que técnicas: formular qué se ofrece, a quién y en qué se diferencia de otra cosa. Tres exigencias técnicas la acompañan, a menudo descuidadas porque no se aprecian en una maqueta. La rapidez de visualización en un dispositivo corriente y una conexión media, que decide cuánta gente se queda. La estructura del contenido, que permite a un buscador —y ahora a los sistemas que redactan respuestas a partir de páginas web— identificar de qué trata cada página y citarla correctamente. Y la capacidad de la empresa para modificar un texto sin depender de nadie: una web que nadie puede corregir envejece deprisa y acaba perjudicando a quien la encargó.

La aplicación de gestión no publica, hace trabajar. Contiene cuentas y funciones, datos que cambian de estado —un expediente pasa de recibido a tratado, una solicitud se aprueba y luego se cierra—, reglas que deciden qué está permitido y a quién, y un rastro de quién hizo qué. Su complejidad no se lee en las pantallas: reside en las excepciones del oficio, es decir, en los casos que el procedimiento oficial no describe y que hoy las personas resuelven de memoria. Una aplicación que trata bien el caso nominal y mal las excepciones se percibe como inservible, porque son precisamente las excepciones las que consumen el tiempo de quienes la utilizan. Es también la categoría en la que las cuestiones de acceso, confidencialidad y conservación se plantean de verdad, puesto que los datos manejados son los de la actividad y, a veces, los de terceros.

La tienda añade el dinero y, con él, una cadena de obligaciones que no termina en el pago. El catálogo, la cesta y el cobro son la parte visible; detrás vienen la disponibilidad real de los artículos, las reglas de envío y de impuestos que varían según la naturaleza del producto y la condición del comprador, la factura, la anulación, el reembolso, la devolución, la reclamación y la sincronización con aquello que lleva el inventario o la contabilidad. Una tienda es un programa de gestión de pedidos disfrazado de catálogo. La consecuencia práctica merece plantearse ya en el encuadre: se juzga tanto después de la venta como antes. Un recorrido de compra impecable que desemboca en un seguimiento de pedido aproximado genera trabajo adicional para la empresa y desconfianza en el comprador, lo que cuesta más de lo que aportó la puesta en línea.

Muchos proyectos reales combinan los tres a la vez: una web corporativa con área de clientes, una tienda apoyada en una herramienta interna de preparación de pedidos. Nada impide esa mezcla, siempre que se sepa qué parte corresponde a qué, porque cada una impone su propia disciplina. La pregunta útil desde el principio no es, por tanto, «cuántas páginas», sino «qué cambia cuando alguien la usa». Nada en absoluto, y estamos en la publicación. Algo queda registrado y habrá que recuperarlo, corregirlo o discutirlo, y estamos en el terreno de la aplicación. Esa respuesta gobierna todo lo demás: la forma de encuadrar, la forma de comprobar antes de publicar, el alojamiento necesario, la carga de mantenimiento prevista y la cuestión de si un producto existente ya sirve. Se decide antes de cualquier conversación sobre tecnologías, que no son más que un medio para obtener lo que allí se haya decidido.

Front-end, back-end, alojamiento y base de datos: qué significa cada palabra

En resumen: El front-end se ejecuta en el equipo del usuario y nunca puede darse por fiable; el back-end decide y registra; la base de datos sobrevive al código; el alojamiento es el lugar donde todo eso funciona y, sobre todo, la cuestión de quién lo mantiene.

El front-end es lo que se ejecuta en el navegador de quien consulta. Tres lenguajes se reparten allí el trabajo: un lenguaje de estructura, que declara qué son los elementos (un título, una lista, un campo, un botón); un lenguaje de presentación, que decide la apariencia y la adaptación a los tamaños de pantalla; y un lenguaje de programación, que añade comportamientos. Ese reparto no es una convención estética. Es la estructura, y solo ella, la que permite a una tecnología de apoyo anunciar que un elemento es un botón, a un buscador comprender la jerarquía de una página y al navegador hacer la interfaz utilizable con el teclado sin que haya que programar nada. Un botón fabricado a partir de un elemento cualquiera se parece a un botón sin serlo, y es una fuente habitual de defectos de accesibilidad. Conviene retener dos propiedades del front-end: se ejecuta en un dispositivo que usted no elige, lo que convierte la diversidad de navegadores, pantallas y conexiones en una restricción real; y es enteramente visible y modificable por quien lo muestra.

El back-end se ejecuta en una máquina que usted controla. Es él quien comprueba la identidad del usuario, decide qué tiene derecho a ver y a hacer, aplica las reglas del negocio, registra y vuelve a leer los datos. La segunda propiedad del front-end enunciada más arriba tiene aquí una consecuencia que ningún proyecto serio ignora: un control efectuado únicamente en el navegador no es un control, puesto que basta con no pasar por la interfaz para sortearlo. Toda comprobación que comprometa algo —un precio aplicado, un permiso de acceso, una cantidad disponible, la pertenencia de un documento a quien lo pide— debe rehacerse en el servidor, aunque ya se haga en el navegador por comodidad. Las dos mitades se comunican mediante una interfaz de programación, llamada a menudo API: un conjunto de direcciones que aceptan peticiones precisas y devuelven respuestas en un formato convenido. Esa frontera tiene una virtud duradera: permite rehacer la interfaz sin tocar las reglas, o alimentar más adelante otra herramienta con los mismos datos.

La base de datos es el lugar donde la información persiste. Allí se describe primero una estructura: qué entidades existen, qué atributos tienen, cómo se relacionan y qué restricciones deben seguir siendo ciertas pase lo que pase —un pedido pertenece a un cliente existente, una misma dirección no aparece repetida, una cantidad no se vuelve negativa—. Confiar esas garantías a la base y no solo al código se paga en tranquilidad, porque la base las hace respetar incluso cuando una parte del programa se equivoca. Se encuentran dos familias: las bases relacionales, organizadas en tablas relacionadas entre sí, adecuadas cuando los datos tienen una forma regular y vínculos fuertes; y las bases documentales, más flexibles en cuanto a la forma, adecuadas cuando cada registro difiere de sus vecinos. Dos puntos importan más que esa elección. La migración, primero: la estructura evolucionará, y hacerla evolucionar cuando ya contiene datos es un ejercicio que se prepara en lugar de improvisarse. La restauración, después: una copia de seguridad de la que nunca se ha comprobado que se restaura no es una copia de seguridad. Los datos sobreviven al código: se reescribe una aplicación, no se reinventa el historial de pedidos.

El alojamiento es el lugar donde el programa se ejecuta y desde donde se sirven los archivos. Las fórmulas se distinguen menos por su nombre comercial que por el reparto de responsabilidades: quién actualiza el sistema operativo, quién vigila el servicio, quién interviene cuando el tráfico sube de golpe, quién restaura tras un incidente. Un servidor compartido delega mucho en el proveedor y deja poco margen; una máquina virtual da el control completo y la obligación que lo acompaña; una plataforma gestionada asume la ejecución y el despliegue imponiendo sus convenciones; un sitio compuesto de archivos ya calculados, completado con unas pocas funciones invocadas a demanda, reduce mucho la superficie que hay que mantener cuando la necesidad lo permite. Tres elementos acompañan al alojamiento y, cuando se olvidan, provocan interrupciones sin que ninguna línea de código haya cambiado: el nombre de dominio, que es un registro que hay que renovar; la configuración que asocia ese nombre a un servidor; y el certificado que autoriza la conexión cifrada. Por último, un proyecto serio dispone de entornos separados —uno para desarrollar, otro para comprobar y otro de producción—, sin los cuales toda corrección se intenta delante de los usuarios.

Queda lo que une esas capas y no aparece en ninguna maqueta. El código fuente vive en un repositorio con control de versiones, que conserva el historial de las modificaciones, permite volver a un estado anterior y hace posible el trabajo entre varias personas sin que una sobrescriba a otra. El despliegue es el procedimiento que convierte ese código en un sitio publicado; automatizado, se vuelve reproducible y deja de depender de la memoria de una persona. Los registros de actividad recogen lo que el programa hizo y son el único medio de comprender un incidente a posteriori; la supervisión avisa de que un servicio ha dejado de responder antes de que lo señale un cliente. Estos elementos pasan por comodidad de quien programa; en realidad deciden la capacidad de reparar. Una web se reduce finalmente a tres cosas que hay que poseer juntas para ser dueño de ella: el código, los datos y la configuración, incluidas las credenciales de acceso a los servicios de terceros. Tener dos de las tres no basta.

Cómo transcurre un proyecto, del encuadre al mantenimiento

En resumen: Describir los recorridos reales antes de dibujar, dibujar antes de programar, entregar por porciones utilizables, hacer comprobar el resultado por quienes lo usarán, preparar la publicación como una operación en sí misma y después cuidar lo construido.

El encuadre funcional describe qué debe permitir el programa, para quién y en qué se reconocerá que ha salido bien. Una lista de funcionalidades no basta, porque enumera medios sin decir para qué sirven. Lo que se describe son recorridos: una persona llega con una intención, encadena acciones y obtiene un resultado. Tres elementos se olvidan sistemáticamente y salen caros sistemáticamente. Los casos anómalos: qué ocurre cuando falta un dato, cuando un pago falla, cuando un archivo adjunto es ilegible, cuando la misma operación se intenta dos veces. Las reglas de negocio puestas por escrito: quién tiene derecho a ver qué, qué pasa al anular, qué se conserva y para qué uso. Y lo que queda fuera del alcance, enunciado explícitamente, que protege a ambas partes mucho mejor que una lista de inclusiones. El encuadre sirve además para separar lo que debe existir en la apertura de lo que puede venir después: un alcance ordenado se construye por porciones, un alcance desordenado se construye entero o no se construye.

Las maquetas sirven para discutir sobre un dibujo en lugar de sobre un programa, porque un dibujo se tira sin pena. Conviene distinguir los esquemas funcionales, deliberadamente grises y sin estilo, que deciden qué se muestra, en qué orden y en qué lugar, de las maquetas gráficas que fijan después la apariencia. Mezclar ambas hace discutir de colores cuando habría que discutir de organización, y los comentarios recaen entonces sobre lo que se cambia con facilidad y no sobre lo que cuesta caro. Dos exigencias vuelven útil esta etapa en vez de decorativa. Trabajar con contenido real, primero: los títulos reales, los nombres reales, las fotografías reales y los volúmenes efectivos, porque una maqueta llena de texto de relleno y de tres artículos bien escogidos miente sobre lo que será la pantalla una vez llena. Dibujar los estados incómodos, después: la lista vacía del primer día, el mensaje de error, la espera durante un procesamiento, el texto que desborda, la conexión perdida. Esos estados representan una parte considerable del trabajo de desarrollo y casi nunca aparecen en una presentación. El comportamiento en pantalla pequeña se decide en ese mismo momento, y se decide al principio en vez de al final: la restricción de una pantalla estrecha obliga a jerarquizar la información, algo de lo que la versión ancha se beneficia después.

El desarrollo avanza mejor por porciones verticales que por capas sucesivas. Una porción vertical es una funcionalidad completa, desde la pantalla hasta la base de datos: funciona, luego se muestra, luego se discute. Construir primero toda la base, después todo el back-end y después todas las pantallas aplaza hasta el final el momento en que alguien ve algo, es decir, el momento en que salen a la luz los malentendidos. Cada iteración termina con una demostración ante personas del oficio, y esa demostración corrige el encuadre: el uso hace aparecer casos que nadie supo formular en frío. Dos prácticas hacen sostenible ese ritmo. La revisión del código por otra persona, que detecta defectos pero sobre todo reparte el conocimiento, de modo que el proyecto no dependa de una sola cabeza. Y las pruebas automatizadas, dedicadas con prioridad a las reglas cuya ruptura saldría cara —los cálculos, los permisos de acceso, los encadenamientos de estados—, porque permiten después modificar el programa sin temer romper en silencio lo que funcionaba.

La aceptación es la comprobación, por parte de quien encargó el trabajo, de que lo entregado hace lo que se había pedido. No se confunde con las pruebas de quien programa, que verifican que el programa hace lo que su autor cree haber escrito; nadie revisa con provecho su propio trabajo con los ojos que lo produjeron. Exige tres condiciones: un entorno distinto del de producción, datos realistas en vez de ejemplos escogidos y escenarios escritos de antemano, idealmente los del encuadre, lo que otorga a este una segunda utilidad. Se busca lo que se rompe, no lo que funciona. Las anomalías detectadas se clasifican después según su gravedad y, sobre todo, según una distinción que el proyecto debe establecer antes de necesitarla: lo que no funciona es una corrección, lo que funciona de otro modo del esperado es una evolución. Confundir ambas cosas es una fuente de conflicto al final de un proyecto. La aceptación termina con una decisión explícita y escrita sobre lo que se acepta, lo que queda por corregir y lo que se aplaza.

La puesta en línea es una operación en sí misma y no el accionamiento de un interruptor. Comprende etapas que nada tienen que ver con el código: la migración de los datos existentes, con la decisión, para cada conjunto, de qué pasa a la nueva herramienta, qué queda solo como archivo consultable y qué desaparece; la redirección de las direcciones antiguas hacia las nuevas cuando un sitio sustituye a otro, sin la cual los enlaces acumulados y las páginas ya conocidas por los buscadores dejan de llevar a ninguna parte; el cambio del nombre de dominio y la verificación del certificado; la retirada de las instrucciones que impedían la indexación durante la fabricación, olvido tan clásico que merece una línea en el procedimiento; la puesta en servicio de la medición de audiencia y de la recogida del consentimiento. También se prevé qué hacer si algo va mal: volver al estado anterior debe ser una operación conocida y ensayada, no una improvisación bajo presión. Por último, las personas que responderán a las preguntas de los usuarios se avisan antes que los propios usuarios.

Lo que se llama mantenimiento abarca tres actividades que conviene nombrar por separado, porque no obedecen a la misma lógica. La corrección trata lo que no funciona. La evolución añade lo que el uso ha revelado, y es señal de que una herramienta está viva más que confesión de un encuadre fallido. La conservación en estado operativo es la menos visible y la más descuidada: actualizar los componentes de los que depende el sitio cuando se publica una vulnerabilidad en ellos, seguir las versiones del lenguaje y del sistema, renovar los certificados, comprobar que las copias de seguridad se restauran realmente y controlar que los servicios de terceros utilizados no han cambiado sus interfaces. Un programa que no se toca no permanece idéntico: su entorno se mueve a su alrededor, y la inmovilidad produce una avería diferida. Tres preguntas se resuelven, por tanto, antes del final del proyecto y no después: quién tiene las credenciales, dónde está escrito el procedimiento de despliegue y a quién se recurre cuando algo se rompe.

Los errores que salen más caros en un proyecto web

En resumen: Comprometerse antes de haber descrito, entregar sin hacer comprobar, depender de un proveedor por no poseer la propia herramienta, tratar el rendimiento y la accesibilidad como un acabado, y descubrir el día de la publicación que el contenido no existe.

El primer error consiste en invertir el orden del compromiso y de la descripción. Un acuerdo cerrado sobre un alcance resumido en unas líneas no hace desaparecer la incertidumbre, la desplaza: las zonas dejadas en vago habrá que decidirlas igualmente, y se decidirán más tarde, bajo presión, por aquella de las dos partes que más tenga que perder si se detiene. El proyecto termina entonces con funciones recortadas en el último momento o con una sucesión de discusiones sobre qué estaba y qué no estaba incluido. Una fórmula que se oye en todas partes ilustra el problema: pedir «lo mismo que tal sitio» describe una apariencia, no unas reglas, y dos sitios de aspecto parecido pueden diferir por completo en lo que hacen con la información que reciben. El remedio no es congelarlo todo, cosa imposible en un proyecto vivo, sino situar la descripción de la necesidad antes del compromiso y nombrar explícitamente lo que queda fuera. Un alcance se sostiene mejor cuanto más enuncia sus exclusiones; es también lo que permite discutir con calma una petición añadida, como añadido y no como algo debido.

El segundo consiste en considerar la entrega como el final del trabajo. Sin aceptación, el primer uso real ocurre en producción, con datos reales y con personas que no se pueden permitir fallar. Los defectos que la aceptación detecta son siempre los mismos y jamás aparecen en una demostración: los acentos y los apóstrofos en los nombres propios, los campos dejados vacíos, los textos más largos de lo que la pantalla preveía, los archivos rechazados sin explicación, dos personas que modifican el mismo registro en el mismo instante, el botón de retroceso del navegador, la sesión caducada en mitad de un formulario, el pedido enviado por duplicado. Se encuentran intentando romper, no intentando lucir. El punto decisivo es que la aceptación se prepara durante el encuadre y no la víspera de la entrega: escribir de antemano qué valdrá como prueba de buen funcionamiento obliga a precisar la necesidad, y el mismo documento sirve una vez para especificar y otra para comprobar.

El tercero es la dependencia involuntaria de un proveedor. Casi nunca se instala por mala intención, sino por omisión, porque nadie planteó la pregunta al principio. El nombre de dominio está registrado a nombre del proveedor, el repositorio de código está en su casa, el alojamiento está abierto en su cuenta, el procedimiento de despliegue solo existe en su memoria, la base de datos jamás se ha exportado, las credenciales de los servicios de terceros son suyas. Tomado por separado, cada uno de esos puntos parece inocuo; reunidos, hacen que una empresa ya no pueda cambiar de socio, ni continuar sola, ni a veces siquiera corregir una línea de texto. Las preguntas que hay que plantear antes de empezar no son una muestra de desconfianza, son preguntas de explotación: quién posee el nombre de dominio, dónde vive el código fuente y en qué condiciones puede usarse, cómo se obtiene una copia completa de los datos y en qué formato, quién puede desplegar, qué haría falta para que otro equipo retomara el trabajo. Una señal práctica vale por un inventario: si modificar una frase obliga a escribir a alguien, la dependencia ya está instalada.

El cuarto consiste en tratar el rendimiento y la accesibilidad como un acabado. Ni uno ni otra son una opción que se active al final; ambos son consecuencia de decisiones tomadas pronto. La rapidez de visualización depende del peso de las imágenes y del formato en que se sirven, del número de archivos que hay que descargar antes de que la página resulte utilizable, del tiempo de respuesta del servidor y de las consultas hechas a la base, de la cantidad de código ejecutado en el navegador y de la elección de calcular las páginas por adelantado, a demanda en el servidor o en el equipo del usuario. Esas decisiones son estructurales: retomarlas después equivale a menudo a rehacer la obra. La accesibilidad obedece a la misma lógica. Consiste en emplear los elementos previstos para lo que hacen, en hacer cada interacción utilizable con el teclado, en asociar un rótulo a cada campo, en garantizar un contraste legible, en no transmitir nunca una información solo mediante el color, en dejar visible el elemento que tiene el foco y en no atrapar al usuario en una ventana de la que no puede salir. Retomada al final, obliga a reconstruir los componentes; integrada desde el diseño, apenas cambia la carga de trabajo. Dos argumentos se escuchan rara vez juntos y merecen escucharse: este trabajo sirve mucho más allá de las situaciones de discapacidad, ya que una conexión inestable, una pantalla a pleno sol o una mano ocupada crean las mismas necesidades; y, según la actividad y la condición de la organización, pueden aplicarse obligaciones de accesibilidad, lo que conviene verificar en el encuadre y no en la recepción.

El quinto es menos técnico y sin embargo bloquea muchos proyectos: el contenido no existe. Textos, fotografías, descripciones de productos, menciones obligatorias, traducciones: todo eso se produce, se revisa y se decide, y nada se fabrica solo mientras el desarrollo avanza. Un proyecto cuyo contenido no tiene responsable espera, y espera en el momento más caro, cuando todo lo demás está listo y la atención se ha dispersado. El mismo vacío aparece del lado de la decisión: cuando varias personas emiten opiniones contradictorias sin que ninguna decida, las idas y venidas se multiplican, la responsabilidad del retraso se vuelve imposible de desenredar y la calidad del resultado baja, porque una pantalla concebida para satisfacer a todo el mundo no sirve precisamente a nadie. Dos designaciones hechas al principio bastan para evitar ambos problemas: alguien que produce y valida el contenido y alguien que arbitra. Son funciones, no cargos, y nombrarlas cuesta una frase.

Cuándo un desarrollo a medida no es la respuesta adecuada

En resumen: Cuando un producto existente configurado ya sirve, cuando la necesidad no está estabilizada, cuando nadie podrá mantener el resultado, cuando el problema no es de software y cuando un rediseño no tiene más motivo que el cansancio.

El primer caso es el de la necesidad estándar. Publicar páginas, mantener un hilo de noticias, vender artículos de manera ordinaria, concertar citas, recoger inscripciones: esos problemas están resueltos desde hace tiempo por productos ampliamente difundidos que una comunidad o un editor mantienen de forma permanente. Elegir el desarrollo a medida en esas condiciones equivale a asumir un trabajo que otros ya hacen: corregir las vulnerabilidades publicadas, seguir la evolución de los navegadores, adaptarse cuando un servicio de pago modifica su interfaz, absorber los cambios en las reglas de facturación. Ese trabajo no se detiene nunca y permanece invisible mientras se hace. El desarrollo a medida se justifica cuando la forma de trabajar es en sí misma particular —un encadenamiento, un modo de cálculo, una restricción del oficio que ningún producto sabe expresar— o cuando adoptar un producto obligaría a deformar una actividad que funciona bien. Entre ambos extremos está la respuesta más veces acertada y menos espectacular: partir de una base existente y desarrollar específicamente solo el punto preciso en el que la organización se diferencia. Un desarrollo a medida es una ventaja cuando recae sobre lo que le distingue y un lastre cuando recae sobre lo que le hace igual a los demás.

El segundo caso es el de la necesidad que todavía no está estabilizada. Escribir un programa es congelar decisiones: cada regla codificada se convierte en una hipótesis vertida en la estructura, y cambiar de hipótesis cuesta tanto más cuanto que el resto del código se apoya en ella. Cuando una organización está inventando su forma de trabajar —un servicio nuevo, un proceso cuya forma cambia todavía en cada intento—, programar demasiado pronto fija un estado provisional y convierte el aprendizaje en trabajo de rehacer. Un procedimiento manual, una hoja de cálculo compartida o una herramienta configurada asumen muy bien ese papel transitorio: permiten probar, equivocarse y corregir sin romper nada, y producen además la descripción de la necesidad que el desarrollo reclamará más adelante. El desarrollo resulta pertinente cuando la forma de trabajar es conocida y repetida, y lo que cuesta ya no es definirla sino ejecutarla.

El tercer caso tiene que ver con lo que viene después de la entrega. Un programa a medida crea una obligación duradera: alguien deberá instalar las actualizaciones de seguridad de los componentes empleados, seguir la evolución del lenguaje y del alojamiento, responder a los usuarios, arbitrar las peticiones de evolución y financiar todo ello. Una organización que no tiene esa competencia internamente ni la intención de confiarla de forma duradera acabará con una herramienta que funciona al principio y se degrada después, y más deprisa que un producto comercial, no más despacio, porque nada se actualiza por sí solo y ningún editor se ocupa en su lugar. La pregunta que hay que hacerse antes de empezar no es, por tanto, solo «quién lo construye», sino «quién se ocupa luego y con qué medios». Cuando la respuesta honesta es «nadie», un producto configurado, menos ajustado a la necesidad pero mantenido por otros, es objetivamente la mejor elección; anunciarlo antes de comprometerse evita una herramienta abandonada tras poco uso.

El cuarto caso abarca las situaciones en las que el programa no es el culpable. Un sitio no aporta audiencia por sí mismo: transforma una visita en comprensión y luego en contacto, pero antes alguien tiene que llegar. Cuando las visitas son escasas, la causa está aguas arriba —visibilidad, notoriedad, canales empleados, claridad de la oferta— y rehacer la herramienta no la corrige. El caso simétrico también existe: cuando llegan solicitudes y se quedan sin respuesta o sin seguimiento, el problema es de organización interna, y un formulario mejor dibujado solo acelerará la llegada de solicitudes que quedarán pendientes. Distinguir esas situaciones supone mirar lo que ocurre antes y después del sitio en lugar del sitio mismo: de dónde vienen los visitantes, qué buscaban, qué pasa con los mensajes recibidos, quién los trata y en cuántos intercambios. Ese examen se realiza sin escribir una línea de código y a veces ahorra un proyecto entero.

El quinto caso es el del rediseño sin motivo identificado. Un sitio en funcionamiento, que sus usuarios conocen y que los buscadores han aprendido a situar, representa un valor acumulado que una reconstrucción pone en juego: las direcciones cambian, los hábitos se pierden, las páginas ya indexadas deben volver a encontrarse y defectos corregidos pacientemente reaparecen a veces por la ventana. Ese valor no se ve, lo que explica que se sacrifique con facilidad en nombre de una apariencia considerada anticuada. Cuando la molestia es identificable —una navegación que despista, un formulario abandonado a mitad de camino, una lentitud constatada, un contenido que ha dejado de ser cierto—, repararla se juzga mejor y se comprueba antes que una reconstrucción completa. El rediseño se justifica cuando los defectos son estructurales: una organización de la información que ya no corresponde a la actividad, una base técnica que ya no recibe correcciones de seguridad, la imposibilidad de añadir lo que la empresa necesita ahora. Un rediseño decidido por cansancio, en cambio, gasta lo acumulado a cambio de una impresión de novedad que se desgasta, mientras que una reparación concreta se constata.