Qué Reviso Primero Cuando una Empresa Me Pide Mejorar su Sitio Web

Cuando una empresa me pide mejorar su sitio web, lo primero que necesito entender no es el sitio: es el negocio.

En Hamaca Web Solutions, el diagnóstico empieza por aclarar el objetivo comercial, detectar dónde se está rompiendo el proceso y decidir si el sitio necesita ajustes, un rediseño o una nueva implementación. La tecnología viene después.

Después de más de 10 años trabajando en desarrollo web, he aprendido que lo que un cliente solicita inicialmente y el problema que realmente necesita resolver no siempre son lo mismo.

Un negocio puede llegar pidiendo un nuevo sitio web, un sistema de ventas, una plataforma de reservaciones o una infraestructura tecnológica completa. Mi trabajo no debería limitarse a preguntar qué características quiere y comenzar a desarrollar.

Antes necesito entender qué quiere conseguir y por qué cree que esa solución le ayudará a conseguirlo.

Primero necesito entender el negocio

Una de las primeras conversaciones que tengo con un cliente gira alrededor de su empresa.

Normalmente intento aclarar cinco cosas:

• A qué se dedica la empresa.
• Qué servicios ofrece.
• Cómo consigue actualmente clientes.
• Qué está intentando mejorar.
• Por qué está buscando este servicio precisamente ahora.

Estas preguntas parecen sencillas, pero las respuestas empiezan a mostrar un panorama que no se obtiene simplemente revisando los requerimientos técnicos de un proyecto.

Si una empresa me dice que necesita mejorar sus ventas, por ejemplo, necesito entender primero cómo funciona actualmente su proceso comercial.

¿Los prospectos llegan desde redes sociales? ¿Desde Google? ¿Por recomendaciones? ¿Desde su sitio web? ¿Tienen campañas publicitarias? ¿El problema es convertir las oportunidades que reciben o simplemente reciben muy pocas?

La diferencia es importante.

Lo que el cliente pide no siempre resuelve el problema que tiene

Supongamos que una empresa tiene pocas ventas y llega solicitando un sistema para administrarlas.

Podemos construirlo.

Pero antes de hacerlo hay una pregunta mucho más importante:

¿Realmente tienen suficientes oportunidades de venta que administrar?

Si prácticamente no están entrando clientes potenciales, implementar un sistema más sofisticado para gestionar ventas puede mejorar la organización, pero difícilmente resolverá el problema que llevó al cliente a buscar ayuda.

En ese escenario, probablemente deberíamos investigar primero por qué no están llegando prospectos.

Eso puede llevarnos hacia su presencia en Google, publicidad, redes sociales, sitio web, propuesta comercial o incluso hacia elementos de su proceso que inicialmente no tenían nada que ver con desarrollar software.

Por eso intento no comenzar una conversación tecnológica hablando de tecnología.

Primero necesito comprender el problema.

Cuando ya existe un sitio web, comienzo por lo que puede ver cualquier usuario

Una vez que entiendo mejor el negocio y sus objetivos, comienzo a revisar su presencia digital.

Si ya tienen un sitio web, mi primera evaluación no empieza abriendo el código.

Empieza navegándolo.

Una de las preguntas que intento responder constantemente es:

¿Qué queremos que el usuario vea y haga en esta página?

Esto cambia completamente la forma de evaluar un diseño.

Un sitio puede tener fotografías excelentes, animaciones, efectos y una apariencia moderna y aun así no dejar claro qué vende la empresa, por qué debería elegirla o qué debería hacer el visitante a continuación.

También ocurre lo contrario: sitios relativamente sencillos pueden funcionar correctamente porque comunican bien, generan confianza y llevan al usuario hacia una acción clara.

Durante esta primera revisión busco problemas evidentes de experiencia de usuario e interfaz.

¿La navegación se entiende? ¿Existe una jerarquía visual clara? ¿Hay llamadas a la acción? ¿El contenido ayuda a tomar una decisión o la página parece una enciclopedia? ¿La identidad del negocio se distingue de la competencia?

También reviso cómo se comporta el sitio en diferentes dispositivos.

Que una página simplemente quepa dentro de la pantalla de un teléfono no significa que tenga una buena experiencia móvil. La navegación, botones, formularios, tamaños de texto, jerarquía del contenido y acciones principales tienen que seguir funcionando correctamente en móvil, tablet y escritorio.

Después empiezo a profundizar

La revisión inicial me permite detectar muchos problemas, pero es solamente la primera capa.

Después comienzo a profundizar.

Reviso rendimiento y tiempos de carga, estructura SEO, comportamiento responsive, funcionalidad, indexabilidad y diferentes elementos técnicos que pueden afectar tanto a buscadores tradicionales como a la forma en que otros sistemas pueden descubrir e interpretar el contenido. Si la velocidad aparece como una causa probable, profundizo en aspectos como los que explico en por qué una página web carga lento.

Para ello combino inspección y pruebas manuales con herramientas como Google PageSpeed Insights, Lighthouse, Chrome DevTools y Google Search Console, cuando tengo acceso a los datos correspondientes.

Las herramientas automatizadas son útiles, pero no sustituyen una revisión manual.

Una puntuación no puede decirme por sí sola si un usuario entiende la propuesta de valor de una empresa o si el recorrido para solicitar una cotización resulta confuso.

De la misma manera, un sitio visualmente atractivo puede esconder problemas de rendimiento, errores en consola, implementaciones incorrectas, problemas de indexación o una base de código difícil de mantener.

Por eso normalmente avanzo desde lo más visible hacia lo menos visible:

1. Experiencia.
2. Comportamiento.
3. Rendimiento.
4. Visibilidad.
5. Funcionalidad.
6. Implementación técnica.

Si es necesario, termino revisando directamente el código y los errores que está generando la aplicación.

También quiero saber qué ocurre fuera del sitio web

Cuando desarrollo o rediseño un sitio, hay preguntas que hago con frecuencia:

• ¿La empresa tiene redes sociales?
• ¿Mantiene la misma identidad entre ellas?
• ¿Qué servicios ofrece?
• ¿Cuál es su principal diferenciador?
• ¿A qué tipo de cliente intenta llegar?

Estas preguntas no son un requisito administrativo para llenar un brief. Las respuestas afectan directamente las decisiones que podemos tomar en el sitio.

Por ejemplo, unas redes sociales activas pueden mostrarnos que ya existe una comunidad alrededor del negocio.

También pueden ayudarnos a identificar cómo habla la empresa con sus clientes, qué elementos visuales utiliza, qué servicios generan más interés y qué características reconocen sus clientes.

Incluso los comentarios y opiniones pueden convertirse en elementos que aporten confianza y evidencia social al sitio.

Si el cliente no tiene completamente definido su público objetivo, la información recopilada durante estas conversaciones puede ayudarnos a construir una primera aproximación.

No significa que yo deba decidir unilateralmente quién es su cliente.

Presentamos nuestras observaciones y el propio cliente, que conoce su negocio mucho mejor que nosotros, ayuda a confirmarlas, corregirlas y enriquecerlas.

El desarrollo termina siendo un proceso colaborativo.

No siempre recomiendo hacer exactamente lo que me pidieron

Una parte importante de mi trabajo consiste en decir cuando creo que una decisión puede generar problemas.

Eso no significa que la decisión final me corresponda.

El cliente sigue siendo quien decide qué quiere construir.

Recuerdo un proyecto en el que recibí prácticamente terminado el diseño gráfico del sitio que debía desarrollar.

Visualmente podía considerarse atractivo, pero tenía demasiados elementos compitiendo simultáneamente por la atención. En la práctica, consideraba que podía resultar agotador para el usuario y dificultar la navegación.

Expliqué esos problemas, presenté los pros y contras y propuse algunos cambios.

El cliente aceptó algunas sugerencias, pero decidió conservar prácticamente intacta su propuesta original.

Y eso fue lo que desarrollé.

Parte de asesorar profesionalmente también consiste en explicar las consecuencias de una decisión y después respetar la decisión informada del cliente.

La tecnología tampoco debería elegirse porque “es la mejor”

Otro caso ocurrió trabajando con una empresa inmobiliaria.

Llegaron con ideas bastante concretas sobre las tecnologías que consideraban necesarias para su proyecto, incluyendo determinada infraestructura y servicios como servidores dedicados y AWS.

Cuando preguntamos por qué necesitaban específicamente esas tecnologías, la razón principal era que habían investigado y leído que eran algunas de las opciones recomendadas para construir un sitio exitoso.

El problema con esa lógica es que una tecnología no es automáticamente mejor por ser más sofisticada, más cara o utilizada por empresas grandes.

Las decisiones técnicas deberían responder a los requerimientos del proyecto.

Escalabilidad, tráfico esperado, funcionalidades, integraciones, presupuesto, mantenimiento y perspectivas de crecimiento importan mucho más que utilizar una determinada tecnología solamente porque tiene buena reputación.

En ese proyecto expliqué diferentes alternativas, qué podían resolver y qué posibilidades de crecimiento ofrecía cada una.

El cliente entendió el razonamiento y decidió adoptar buena parte de nuestras recomendaciones.

La pregunta correcta no era:

¿Cuál es la tecnología más potente?

Era:

¿Qué tecnología necesita realmente este proyecto?

A veces mi recomendación es construir menos

Uno de los ejemplos que mejor representa esta filosofía ocurrió durante una reunión con un cliente que llegó muy entusiasmado con una idea de negocio.

Quería construir una plataforma completa de generación de leads conectada directamente con proveedores, con registro de clientes, herramientas para administrar información y cálculos que permitieran generar proyecciones útiles para esos proveedores.

Era un proyecto considerable.

El problema no era necesariamente la idea.

El problema era que todavía no existían métricas suficientes para justificar la infraestructura que se quería construir.

No había un embudo probado con proveedores reales ni una base suficiente de clientes potenciales que demostrara que el mercado respondería como se esperaba.

Podía haber construido toda la plataforma.

Mi recomendación fue no hacerlo todavía.

Propuse comenzar con una solución mucho más ligera que permitiera probar el mercado y obtener información real antes de realizar una inversión considerable en infraestructura.

El cliente aceptó la recomendación y entendió que el entusiasmo por una idea no sustituye los datos necesarios para validar algunas de sus suposiciones.

Construir menos en ese momento no significaba renunciar al proyecto.

Significaba crear primero las condiciones necesarias para saber si tenía sentido construir más.

¿Cuándo recomiendo mejorar, rediseñar o empezar de nuevo?

Cuando una empresa ya tiene un sitio web, tampoco parto de la idea de que necesariamente necesita uno nuevo.

Primero intento entender qué tan aprovechable es lo que ya existe.

Hay sitios que tienen problemas concretos que pueden solucionarse mediante ajustes de diseño, experiencia de usuario, rendimiento, contenido, SEO o implementación.

En esos casos, reconstruir todo puede ser innecesario.

En otros proyectos, la tecnología utilizada, el estado del código y las decisiones acumuladas durante años hacen que solucionar cada problema individualmente termine siendo más difícil que replantear la base. En ese punto conviene evaluar con cuidado si ha llegado el momento de rediseñar el sitio en lugar de seguir acumulando correcciones aisladas.

Es lo que en desarrollo solemos relacionar con deuda técnica: decisiones que quizá resolvieron necesidades inmediatas, pero que con el tiempo hacen cada vez más difícil mantener, modificar o ampliar el sistema.

Por eso no existe una respuesta automática.

A veces recomiendo optimizar.

A veces rediseñar.

Y otras veces considero que una nueva implementación es técnicamente más razonable.

La decisión debería surgir del diagnóstico, no de asumir desde el principio que un proyecto nuevo siempre es mejor.

Entonces, ¿qué significa que un sitio web “funcione”?

No todos los sitios web tienen el mismo objetivo.

Algunos venden directamente. Otros generan reservaciones, solicitudes de cotización, llamadas o registros. También existen sitios cuyo propósito principal es informar, ofrecer soporte o proporcionar acceso a determinadas herramientas.

Pero para buena parte de las empresas con las que trabajo, el sitio forma parte de un proceso comercial.

En esos casos, una pregunta fundamental es:

¿El sitio está ayudando a generar oportunidades para el negocio?

No basta con que exista.

Tampoco basta con que se vea bien.

Credibilidad, oferta, diseño, experiencia de usuario, rendimiento, contenido y visibilidad trabajan juntos para conseguir que una persona adecuada llegue al sitio, entienda lo que ofrece la empresa, confíe en ella y tenga claro cuál es el siguiente paso.

Si eso no está ocurriendo, necesitamos averiguar dónde se está rompiendo el proceso.

Primero el problema, después la tecnología

Cuando una empresa me contacta para mejorar su sitio web, mi objetivo inicial no es decidir qué framework utilizar, qué diseño aplicar o cuánto código necesitamos escribir.

Primero quiero entender el negocio.

Después, el problema.

Luego podemos evaluar qué papel está jugando actualmente el sitio y qué está impidiendo que cumpla mejor su objetivo.

Solo entonces tiene sentido hablar de soluciones.

A veces la respuesta será un nuevo sitio web. Otras veces será mejorar el existente. Puede ser una optimización técnica, un cambio en la experiencia de usuario o incluso una solución distinta a la que originalmente se había considerado. Ese diagnóstico es el punto de partida de mi trabajo de desarrollo web.

Y en algunas ocasiones, la recomendación correcta puede ser no construir todavía.

Después de años trabajando en desarrollo web, esa es una de las ideas que considero más importantes:

la tecnología es una herramienta para resolver un problema, no el punto de partida para decidir cuál es el problema.

Hablemos sobre lo que realmente necesita tu sitio