Rediseñar una web: cuándo merece la pena

Hay webs que necesitan rehacerse. Otras necesitan que alguien arregle el formulario.

Desde dentro del negocio, las dos situaciones pueden sentirse igual: la página se ha quedado atrás y no ayuda como debería. Pero llevan a proyectos muy diferentes. Antes de pedir un rediseño, merece la pena averiguar qué falla, qué sigue siendo útil y qué cambio permitiría al cliente completar mejor una tarea.

Empezaría por ahí, con la web abierta en un móvil.

Empieza por intentar usarla

Busca un servicio, intenta entender qué incluye y envía una consulta de prueba. Comprueba después que ha llegado a quien debe atenderla.

Anota los puntos donde dudas o necesitas ayuda. Un botón puede verse bien y dirigir a un formulario que no envía nada. Una sección puede tener un título atractivo y dejar sin explicar lo que se contrata. Son problemas diferentes y conviene nombrarlos por separado. Pide también a alguien ajeno al proyecto que complete esas tareas. La observación no sustituye a los datos de uso, pero ayuda a detectar fallos antes de tener mucho tráfico.

Qué falla y qué creemos que falla

«La web no funciona» todavía es una descripción demasiado amplia.

Escribe primero qué observas y después una posible explicación. Por ejemplo: «Recibimos muchas preguntas sobre un servicio que ya no ofrecemos» es una observación; «la página antigua sigue creando esa expectativa» es una hipótesis que puedes comprobar revisando el contenido y preguntando cómo llegaron esas personas. Otro ejemplo: «No llegan consultas» no demuestra por sí solo que el aspecto visual sea el problema. Antes hay que comprobar que existe tráfico relevante y que el contacto funciona. Si no tienes esos datos, el primer trabajo puede consistir en preparar medición y probar el recorrido.

Deja constancia del recorrido

Selecciona tres tareas importantes para tus clientes y prueba a completarlas sin utilizar el conocimiento interno del negocio. Elige tareas concretas: encontrar un servicio, entender qué incluye y solicitar una propuesta, por ejemplo. Para cada tarea, anota el punto de partida, lo que esperabas encontrar, lo que ocurrió y la dificultad observada. Si grabas o compartes el ejercicio, utiliza datos ficticios y evita incluir información privada.

Revisa cuatro aspectos:

1. Comprensión. ¿Se entiende qué se ofrece y para quién es?
2. Orientación. ¿Los nombres de enlaces y secciones ayudan a elegir el camino?
3. Acción. ¿Se puede completar el siguiente paso y se confirma lo que ha ocurrido?
4. Mantenimiento. ¿El equipo puede mantener actualizada la información que sostiene ese recorrido?

Una preferencia estética y una tarea que no se puede completar merecen conversaciones distintas. Describe qué le impide hacer cada problema al visitante.

Una decisión en tres niveles

Puedes ordenar el encargo en reparación, reorganización o reconstrucción. La reparación aborda fallos delimitados: un enlace roto, un dato incorrecto o un mensaje de contacto confuso. La reorganización cambia la forma de presentar la oferta aprovechando buena parte de la base existente. La reconstrucción replantea estructura y funcionamiento porque la solución actual no sostiene las necesidades del negocio.

Estas categorías sirven para conversar, no para asignar una etiqueta rígida. Una web puede necesitar una reparación urgente mientras se estudia una reorganización más amplia. No conviene esperar a terminar una reflexión de marca para corregir un correo equivocado. Del mismo modo, arreglar ese correo no significa que la arquitectura existente sea suficiente para una nueva línea de servicios.

Para elegir, relaciona cada dificultad con su causa probable y con la parte del sistema que hay que tocar. Si todas las consultas confunden dos servicios, investiga cómo se presentan. Si la misma plantilla impide explicarlos de forma diferente, el problema puede estar en la estructura. Si la estructura lo permite pero faltan textos, cambiar de tecnología no prepara automáticamente esos contenidos.

Pide al proveedor que señale sus incertidumbres. Una propuesta responsable puede reservar una comprobación antes de confirmar una migración. Es preferible conocer esa dependencia que recibir una recomendación absoluta basada en una captura. Para estudiar el alcance puede hacer falta revisar accesos, edición, integraciones y contenido que no se ve desde la portada.

Una reparación pequeña puede ser suficiente

Si el contenido principal sigue representando el negocio y la estructura resulta comprensible, quizá baste con corregir un formulario, mejorar un texto, actualizar proyectos o simplificar un paso. Una empresa que recibe consultas adecuadas pero tiene un error concreto de contacto no necesita justificar un rediseño completo para resolverlo. Corregir primero ese error también permite comprobar si el problema comercial era realmente ese.

Si el fallo está localizado, arréglalo y comprueba el resultado antes de ampliar el encargo.

Cuando el problema afecta a varias piezas

• La oferta ha cambiado y las páginas siguen explicando servicios que ya no son prioritarios.
• Varias rutas importantes obligan a repetir información o dejan al visitante sin un siguiente paso claro.
• La experiencia móvil presenta dificultades generalizadas que no se resuelven en una pantalla aislada.
• Actualizar contenido esencial exige un trabajo desproporcionado para el equipo.
• Las integraciones necesarias no encajan con la solución actual y hay que revisar el funcionamiento conjunto.

Cuando varias de estas dificultades dependen de la misma estructura, tiene sentido estudiar un cambio más profundo.

Imagina una empresa ficticia que empezó ofreciendo un servicio general y ahora se ha especializado en dos líneas. Su web sigue presentando una lista larga de trabajos que ya no quiere priorizar. Recibe consultas, pero muchas se refieren a esa oferta antigua. La primera hipótesis podría ser que el contenido no refleja la especialización actual. Antes de cambiar toda la tecnología, convendría revisar la presentación, las páginas de servicio, los ejemplos y las llamadas a contactar. Si la estructura permite reorganizar esas piezas de forma clara, puede bastar una revisión de contenido y diseño. Si todo está unido en una navegación que no admite explicar bien las dos líneas, quizá haga falta replantear la arquitectura.

La edad de la web no decide el alcance.

Después del cambio, el equipo debería observar el tipo de consultas que recibe, además de su cantidad. Que haya menos contactos no es necesariamente un resultado peor si dejan de llegar solicitudes que no corresponden a la oferta; habría que valorar el conjunto de datos y su volumen.

Qué atender primero

Una vez reunidas las dificultades, valora cuáles impiden una tarea esencial, cuáles generan confusión y cuáles son mejoras deseables. Empieza por aquellas que afectan directamente al recorrido comercial y cuyo problema está comprobado. Un formulario que no entrega solicitudes tiene una consecuencia clara. Un texto que induce a pensar que prestas otro servicio también puede requerir atención temprana. Un cambio decorativo puede esperar si todavía no has resuelto esas dificultades.

No hace falta asignar una puntuación a todo.

Después estima con el equipo qué exige cada solución. Algunas necesitan modificar un texto o una interacción; otras dependen de la estructura o de una herramienta que afecta a toda la web. Esa dependencia importa: arreglar repetidamente un problema estructural puede justificar un replanteamiento más amplio.

Puedes dejar tres grupos en la mesa: lo que hay que corregir, lo que requiere investigar y lo que puede esperar. Cada decisión debe tener una razón y una persona responsable.

Inventariar lo que merece conservarse

La conservación empieza por el contenido, pero también incluye decisiones de funcionamiento. Quizá una página responde bien a una pregunta frecuente. Quizá el equipo domina una herramienta de edición. Quizá una dirección aparece en documentos que seguirán circulando durante años. El nuevo proyecto debe conocer esas piezas para decidir si las mantiene, las mejora o las sustituye con una transición clara.

Reúne las páginas actuales en una hoja y añade su función. A continuación, señala si la oferta sigue vigente, si el material tiene permisos de publicación y quién puede confirmar los datos. Una página antigua puede contener una explicación valiosa junto a precios desactualizados. No hace falta conservarla intacta ni eliminarla entera: se puede separar lo útil de lo que debe cambiar.

Añade los recursos descargables. Los documentos también reciben enlaces y pueden contener información de contacto antigua. Si actualizas la web pero mantienes un dossier contradictorio, el cliente seguirá encontrando versiones distintas. Decide qué documento será vigente, cómo se identificará y quién retirará las copias accesibles que ya no corresponden a la oferta.

Las imágenes necesitan una revisión parecida. Una fotografía puede seguir siendo adecuada, aunque su tamaño de archivo resulte excesivo para el uso previsto. Otra puede estar técnicamente optimizada y mostrar instalaciones que ya no existen. Calidad visual, vigencia y preparación técnica son decisiones diferentes. Conviene registrar las tres cuando el material tiene un papel importante en la compra.

Por último, anota lo que el equipo necesita aprender. Si cambia la edición, una entrega sin práctica puede reducir temporalmente la capacidad de actualizar la web. Planifica una tarea de prueba con quien vaya a utilizarla: publicar un proyecto, cambiar una descripción o sustituir una imagen. Esa observación permite detectar necesidades de formación antes del lanzamiento.

Separar un cambio de identidad de un cambio de web

Renovar la web no obliga a cambiar el nombre o el logo. Si la identidad sigue representando el negocio y cuenta con recursos suficientes, puede aplicarse a una estructura nueva. En cambio, si la oferta ha evolucionado y la presentación visual transmite otra actividad, conviene estudiar la identidad antes de desarrollar todas las pantallas.

Imagina una empresa ficticia que comenzó como profesional independiente y ahora trabaja con un equipo. Su web todavía habla siempre en primera persona y muestra una única especialidad. Tal vez el primer cambio necesario sea explicar responsabilidades, servicios y forma de trabajo. Un logo nuevo no resolvería por sí solo esas contradicciones. La revisión de marca puede resultar pertinente, pero necesita un problema propio que justificar.

Cuando ambos trabajos se coordinan, concreta qué decisiones deben llegar primero. La dirección visual, las tipografías y los usos básicos del logo afectan al diseño de la web. Las plantillas de contenido y las funciones del sitio pueden desarrollarse con cierta independencia. Identificar esas relaciones permite organizar el calendario sin esperar a tener cada detalle cerrado ni construir pantallas sobre decisiones que aún van a cambiar.

La guía sobre identidad visual para negocios de servicios desarrolla cómo distinguir el símbolo de la presentación completa. Úsala si la conversación sobre rediseño está mezclando problemas de comunicación, marca y funcionamiento sin precisar qué necesita cada uno.

Antes de mover una sola página

Un inventario reúne las direcciones actuales y explica qué función tiene cada página. Puedes añadir qué contenido se conserva, qué se actualiza y qué relación tendrá con la nueva estructura. No te limites a las páginas que aparecen en el menú. Revisa también enlaces compartidos en publicaciones, documentos y campañas. Si un cliente utiliza una dirección guardada, interesa saber qué ocurrirá con ella después del cambio.

Para cada página que vaya a desaparecer o moverse, define el destino adecuado con el equipo técnico. No des por hecho que mandar todas las direcciones antiguas a la portada será útil: la persona debería encontrar una respuesta coherente con lo que buscaba.

Guarda este mapa como parte del proyecto y úsalo en las pruebas de lanzamiento. La documentación de Google sobre cambios de URL detalla la preparación y el seguimiento de estas migraciones. La parte importante para el cliente es saber que mover contenido requiere un plan, no solo publicar pantallas nuevas.

No elimines una página solo porque encaja peor en el nuevo diseño. Revisa primero si su contenido sigue resolviendo una necesidad y dónde debe quedar.

Preparar una transición que pueda revisarse

Antes del lanzamiento, crea una copia de referencia del estado anterior y acuerda qué se necesita para recuperar el servicio si aparece un fallo relevante. El procedimiento dependerá de la plataforma y de las herramientas conectadas. Lo importante para el negocio es conocer quién toma la decisión, qué información debe conservarse y cómo se comprobará la recuperación.

Una prueba de transición puede recorrer las direcciones que más utiliza el equipo. Abre enlaces desde una firma de correo, un presupuesto, una publicación y un documento. Comprueba si llegan al contenido esperado y si la persona puede continuar. No limites la revisión a navegar por el menú nuevo: precisamente los enlaces externos pueden seguir apuntando a rutas anteriores.

Registra también los cambios que no se ven en pantalla. El destino de un formulario, las cuentas que reciben avisos o el proveedor de correo pueden modificarse durante el proyecto. Si nadie los documenta, un problema posterior será más difícil de localizar. Un breve registro de fecha, cambio, responsable y prueba realizada puede ahorrar conversaciones ambiguas.

Para cambios de URL, acuerda la correspondencia entre el contenido anterior y el nuevo, comprueba las redirecciones y revisa los enlaces internos. Google recomienda planificar y supervisar estas migraciones; no debe prometerse ausencia total de fluctuaciones. Un mapa bien preparado reduce errores evitables, pero no permite fijar cómo responderán las búsquedas ni en qué plazo exacto.

Leer una propuesta de rediseño

Pide a cada proveedor que relacione su propuesta con los problemas observados. Una explicación útil indica qué cambiaría, qué conservaría y qué necesita investigar antes de cerrar el alcance. Comprueba si incluye revisar el contenido existente, preparar material nuevo, gestionar cambios de URL y probar el recorrido comercial. Aclara también quién se ocupa de las herramientas conectadas y qué información debe conservarse.

Una propuesta puede centrarse en apariencia, otra en contenido y otra en reconstrucción técnica. No son intercambiables aunque todas utilicen la palabra «rediseño». Si no entiendes la diferencia, pide un ejemplo de una tarea que el cliente podrá completar mejor al terminar.

Pregunta además cómo se evitará trabajar indefinidamente sobre revisiones abiertas. Conviene acordar qué se revisa en cada fase, qué material necesitas aportar y qué criterio permite pasar a la siguiente. Esto ayuda a que las decisiones importantes se tomen antes de desarrollar una solución completa.

Los criterios de aceptación caben en situaciones concretas

En lugar de «la web debe ser intuitiva», escribe una tarea observable: «Una persona que necesita mantenimiento encuentra el servicio, comprende si incluye visitas y sabe cómo pedir una propuesta». Esa formulación revela qué contenido debe existir y qué enlaces lo conectan. También permite pedir una prueba sin convertir la revisión en una discusión puramente estética.

Para un portfolio, la tarea podría ser localizar un proyecto semejante y entender qué hizo el estudio. Para una empresa de viajes, explicar unas preferencias sin creer que está confirmando una reserva. Para un espacio de eventos, consultar posibilidades y solicitar disponibilidad sin recibir una promesa automática. Los escenarios deben parecerse a los clientes del negocio, no a una lista universal de pantallas.

Incluye situaciones de error. Una persona puede perder la conexión, omitir un dato o volver atrás para corregir una respuesta. No todas las incidencias se pueden prevenir, pero el diseño debe ayudar a comprender lo que ha ocurrido. Comprueba especialmente que una confirmación no afirme un envío que el sistema todavía no ha completado.

La revisión editorial también tiene criterios: servicios vigentes, nombres correctos, ejemplos autorizados, condiciones coherentes y contacto actualizado. Si una página depende de la confirmación de un responsable, resuelve esa confirmación antes de presentarla como definitiva. Publicar una afirmación dudosa para cumplir una fecha traslada el problema al visitante.

La entrega se prueba

Prepara una lista de recorridos con datos ficticios. Abre la página desde un móvil, entra en un servicio, sigue sus enlaces y envía una consulta. Comprueba tanto el mensaje al visitante como la recepción por el equipo. Revisa también situaciones que no son el camino ideal: dejar un campo necesario vacío, introducir información con un formato incorrecto o intentar continuar después de un error. El usuario debe poder entender qué necesita corregir.

Si hay edición de contenido, pide que una persona del negocio realice una actualización habitual. Así puedes comprobar si las instrucciones y permisos corresponden a la forma en que vais a trabajar.

Antes del lanzamiento, acuerda pruebas de navegación, contacto, accesibilidad básica y carga. Los Web Vitals ayudan a organizar la evaluación de experiencia, pero una prueba local y la experiencia de visitantes reales son mediciones distintas.

Después del lanzamiento

Antes de publicar, registra qué cambia y qué esperas observar. Si modificas oferta, campañas, contenido y contacto al mismo tiempo, resultará difícil separar el efecto de cada intervención.

Cuando haya datos suficientes, compara periodos con la misma definición de consulta y una cobertura similar. Revisa también si cambió el origen del tráfico, la temporada o el tipo de servicio que se promociona. Esos factores pueden influir en el resultado aunque la web sea la misma. Complementa los números con información del equipo: dudas que han dejado de repetirse, errores detectados, consultas con mejor contexto o dificultades nuevas. Esa observación no demuestra causalidad, pero ayuda a formular hipótesis para la siguiente mejora.

Con poco tráfico, quizá toque esperar. Conserva la versión, registra los problemas comprobados y sigue reuniendo datos antes de encadenar otra reconstrucción.

Cuando los datos parecen empeorar después del cambio

Una caída aparente puede reflejar un cambio de medición. Quizá antes se contaban clics como consultas y ahora solo se registran envíos recibidos. Quizá una herramienta anterior duplicaba eventos. Antes de concluir que el rediseño perjudicó el negocio, comprueba que las definiciones y la cobertura de los periodos comparados sean equivalentes.

Después revisa los recorridos de entrada. Si desaparece tráfico hacia una página concreta, comprueba su estado, contenido y dirección. Si el tráfico se mantiene pero el contacto cambia, prueba el formulario y revisa la procedencia de las visitas. Si las consultas llegan pero no continúan, pregunta al equipo qué objeciones aparecen. Cada síntoma lleva a una investigación distinta.

Conserva un registro de incidencias desde el lanzamiento. Una fecha precisa permite relacionar una modificación con un problema sin depender de recuerdos. Añade capturas cuando ayuden y evita incluir datos personales. La utilidad del registro está en describir qué ocurrió y cómo se reprodujo, no en acumular documentos que nadie consulta.

No reviertas toda la web por una oscilación aislada si no hay un fallo demostrado. Tampoco esperes semanas para reparar una función central que has comprobado que no funciona. La decisión debe combinar gravedad, evidencia y capacidad de recuperación. Es posible corregir un problema concreto mientras se reúne información sobre el rendimiento general.

Una reunión final que deje responsables claros

La entrega no termina con una lista de accesos. Conviene repasar qué se ha publicado, qué tareas quedan bajo responsabilidad del negocio y qué servicio posterior existe. Si hay mantenimiento, especifica cómo se comunica una incidencia. Si las actualizaciones se solicitan por separado, explica cómo se presupuestan y quién puede autorizarlas.

Reserva una revisión del contenido después de un periodo de uso suficiente para reunir observaciones. No necesitas prometer una mejora numérica. Puedes comprobar si siguen apareciendo las confusiones que motivaron el encargo, si el equipo logra actualizar la información y si los clientes completan los recorridos previstos. Eso devuelve la conversación a los problemas originales.

Guarda el inventario de páginas, el mapa de cambios y las instrucciones en un lugar accesible para las personas responsables. Cuando la siguiente actualización llegue, esos materiales permitirán trabajar desde una base conocida. El rediseño habrá producido algo más que una apariencia nueva: una forma más clara de sostener la web y decidir sus próximos cambios.

El encargo que puedes preparar hoy

Completa este resumen en lenguaje sencillo: «Nuestra web debería ayudar a…; hoy observamos que…; creemos que puede deberse a…; queremos conservar…; necesitaremos comprobar…».

Añade enlaces a las páginas relevantes y dos o tres ejemplos del problema. Si no tienes medición, indícalo. Si hay una fecha importante o una dependencia con otra herramienta, inclúyela también.

Ese resumen da al proveedor algo que investigar y a ti algo que comprobar cuando el trabajo termine.

Consulta el servicio de diseño y desarrollo web de TRAMA y cuéntanos qué está fallando. Si la revisión lleva a pedir presupuesto, esta guía te ayuda a comparar qué incluye cada propuesta.