¿Por dónde empieza realmente un buen proyecto?
En las partes anteriores llegamos a una conclusión importante: no diseñamos una página solo porque la empresa necesita una “página nueva”.
Diseñamos una herramienta que debe resolver un problema concreto.
A veces el problema es la baja ventas. A veces es un número insuficiente de consultas. A veces los clientes no encuentran la información. En otras ocasiones los comerciales responden cada día las mismas preguntas porque la web no transmite la información básica. También ocurre que la empresa simplemente ha crecido y el sitio anterior dejó de ajustarse a su escala real.
Por eso la primera etapa no debería ser Photoshop, Figma ni la elección del framework.
La primera etapa debería ser una conversación.
Primero conocemos el negocio
Un buen diseñador de UX no necesita convertirse en experto de cada sector para el que diseña. Sin embargo, sí debe entender lo suficiente el negocio del cliente para saber qué problemas intenta resolver.
Por eso preguntamos cosas que al principio pueden parecer no relacionadas con el diseño;
- ¿De dónde vienen los clientes?
- ¿Por qué eligen precisamente esta empresa?
- ¿Por qué se van?
- ¿Qué preguntan con más frecuencia antes de comprar?
- ¿Cómo es el proceso de ventas?
- ¿Quién se encarga de gestionar las consultas?
- ¿Qué ocurre con el lead después de enviar el formulario?
- ¿Qué productos son los más importantes?
- ¿Qué servicios tienen mayor potencial?
- ¿La empresa quiere aumentar el número de consultas, el valor de los pedidos, la cantidad de clientes o sobre todo mejorar su imagen?
Solo las respuestas a esas preguntas permiten establecer qué deberíamos diseñar realmente.
Discovery - antes de que exista el primer boceto
En proyectos digitales se suele utilizar el término Discovery.
Es la etapa de conocer el problema, los usuarios, los objetivos de negocio, las limitaciones y las posibilidades tecnológicas antes de empezar el diseño y el desarrollo propiamente dichos.
No es una “pérdida de tiempo antes de empezar a trabajar”. En un proyecto bien gestionado, el Discovery pretende reducir el riesgo de construir algo que quede bonito pero que no resuelva el problema real.
Por ejemplo, podemos descubrir que el cliente en realidad no necesita una nueva web.
Puede necesitar una mejor arquitectura de la información.
O la simplificación del proceso de compra.
O la integración de la web con el CRM.
O la automatización de la gestión de consultas.
O una forma completamente distinta de presentar la oferta.
Y precisamente por eso a veces vale la pena detenerse antes de comenzar la producción.
El UX no empieza por la apariencia
UX, es decir User Experience, significa la experiencia del usuario al usar un producto o servicio.
En una página web abarca mucho más que la apariencia de la interfaz.
También es:
- la forma de moverse por la web,
- la facilidad para encontrar información,
- la claridad de los mensajes,
- el proceso de compra,
- los formularios,
- la jerarquía del contenido,
- la rapidez para realizar tareas,
- la reacción del sistema a las acciones del usuario,
- la accesibilidad,
- la sensación de seguridad y confianza.
Por eso el UX comienza incluso antes de que alguien dibuje la primera pantalla.
Primero hay que entender qué intenta lograr el usuario.
User Flow - ¿por dónde debe llegar el usuario al objetivo?
Una de las herramientas básicas del diseño UX es el User Flow. Es la descripción del recorrido que hace el usuario para completar una tarea determinada.
Por ejemplo, en una tienda puede verse así: publicidad → página de producto → elección de variante → carrito → entrega → pago → confirmación del pedido.
En una empresa de servicios: Google → página del servicio → trabajos realizados → referencias → formulario → contacto con el comercial.
En el caso de un fabricante: buscador → producto → especificaciones técnicas → documentación → solicitud de oferta.
Cada uno de esos recorridos requiere decisiones de diseño diferentes.
Si el objetivo principal del usuario es comprar, no podemos obligarle a leer docenas de pantallas de texto. Si, en cambio, el producto es caro, complejo y requiere consultoría, dirigirle demasiado rápido al formulario también puede ser una mala idea.
El UX consiste, entre otras cosas, en encontrar el nivel adecuado de guía al usuario.
Wireframe - antes de “embellecer”
El siguiente paso puede ser el wireframe, es decir, un esquema simplificado de la pantalla que muestra la disposición del contenido y las funciones.
El wireframe no tiene que ser bonito. Y eso está bien. En esta etapa no importa si el color del botón está bien elegido.
Se trata de responder a preguntas:
- ¿Qué verá el usuario primero?
- ¿Qué será lo más importante?
- ¿Qué debería ir más arriba?
- ¿Dónde pondremos la información adicional?
- ¿Cómo pasará el usuario al siguiente paso?
- ¿Qué ocurrirá al hacer clic?
Es algo parecido a diseñar una vivienda.
Primero decidimos dónde estarán las paredes, las puertas y las estancias. Solo después pensamos en el color de las paredes.
Design system - para que el proyecto no sea un conjunto de elementos aleatorios
En proyectos más grandes aparece otro elemento importante: el Design System.
Es un conjunto ordenado de normas, componentes y patrones que definen cómo construir la interfaz.
Puede incluir, entre otras cosas:
- colores,
- tipografía,
- botones,
- formularios,
- tarjetas,
- tablas,
- mensajes,
- iconos,
- espaciados,
- reglas de responsive,
- comportamiento de los componentes.
¿Para qué? — Para que la interfaz sea coherente.
Si en una subpágina un botón se comporta de una manera y en otra de forma totalmente distinta, el usuario tiene que reaprender la interfaz cada vez.
El Design System también ayuda al equipo de desarrollo. En lugar de construir cada componente desde cero, puede usar elementos previamente acordados.
Eso se traduce en mayor coherencia, desarrollo más sencillo y, a menudo, en menor coste de mantenimiento del proyecto.
¿Y la tecnología en todo esto?
La tecnología debe aparecer con la debida antelación, pero no debería dictar todo el proyecto. Es una distinción importante.
El diseñador puede imaginar una función excelente que tenga sentido desde el punto de vista del negocio. Sin embargo, el desarrollador puede observar que su implementación será muy costosa o generará problemas de rendimiento.
Por otro lado, el desarrollador puede proponer una solución tecnológica muy conveniente de implantar, pero que desde la perspectiva del usuario no resuelve suficientemente bien el problema.
Por eso los mejores proyectos surgen cuando UX, diseño, desarrollo y negocio dialogan desde el principio.
No bajo la fórmula: “Primero los diseñadores, luego los programadores”.
Sino: “Pensamos juntos cómo resolver mejor el problema”.
La tecnología no debería elegirse porque esté de moda
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, aplicación nativa, PWA... Se pueden enumerar muchas tecnologías.
Pero el cliente no compra tecnología. Compra una solución.
Por eso la pregunta: “¿Qué framework vamos a usar?”
a menudo es mucho menos relevante que: “¿Qué problemas debe resolver el sistema?” Solo después se puede elegir una arquitectura adecuada.
Una tecnología difiere para una web corporativa sencilla, otra para una tienda que maneje miles de pedidos y otra para una plataforma B2B con integraciones complejas y permisos de usuario individuales.
La tecnología debe derivar de los requisitos, no los requisitos de la tecnología.
Backend, frontend y el lugar que el usuario no ve
También vale recordar que una web no es solo lo que vemos en el navegador.
Frontend se encarga de la parte de la aplicación con la que el usuario interactúa directamente.
Backend se encarga de la lógica en el servidor: procesamiento de datos, comunicación con la base, gestión de procesos e integraciones.
Y entre ellos suelen existir bastantes elementos adicionales;
- CRM.
- ERP.
- Sistema de pagos.
- Plataforma de mailing.
- Sistema de inventario.
- API.
- Analítica.
- Automatizaciones.
- Sistema de atención al cliente.
Si diseñamos una nueva web sin tener en cuenta ese ecosistema, podemos crear un frontend bonito que funcione como una isla aislada.
Y el objetivo debería ser algo completamente distinto.
Una buena web puede hacer mucho más que “recoger formularios”
Una web moderna puede ser parte de un proceso de negocio mayor;
- El usuario envía una consulta.
- El sistema reconoce su tema.
- El lead llega al CRM.
- El comercial recibe una notificación.
- El cliente recibe una confirmación automática.
- Los datos se asignan a la categoría adecuada.
- El sistema puede comprobar la disponibilidad del producto.
- Puede preparar información para el comercial.
- Puede iniciar un workflow determinado.
En una tienda, el pedido puede pasar automáticamente por las siguientes etapas de realización. En B2B, el cliente puede tener acceso a precios individuales, documentos e historial de pedidos.
Entonces la web deja de ser solo una “tarjeta de visita”. Se convierte en parte de la infraestructura del negocio.
¿Y la IA?
La IA también puede formar parte de ese sistema. Pero, de nuevo, no debe añadirse solo porque “todos ahora tienen IA”.
Si un chatbot no resuelve ningún problema real, será solo otra ventana en la web.
Si, en cambio, gracias a la IA el usuario puede encontrar más rápido el producto adecuado, configurar un servicio, obtener respuesta a una pregunta o pasar por el proceso de selección, entonces la tecnología tiene justificación.
Lo mismo ocurre con la personalización.
Podemos mostrar contenidos distintos según el comportamiento del usuario, la fuente de entrada o la etapa del proceso de compra. Podemos analizar datos y predecir mejor las necesidades de los clientes.
Pero siempre deberíamos empezar por la pregunta: “¿Qué problema resolvemos?”
Y después: “¿Es la IA la mejor forma de resolverlo?”
Probamos no solo si funciona
Uno de los errores más comunes es probar la web solo al final. Entonces descubrimos que el formulario es demasiado largo, el proceso de compra no es intuitivo y el usuario no encuentra la información más importante.
Cuanto más tarde descubramos ese problema, más caro será arreglarlo.
Por eso vale la pena probar el proyecto por etapas. Podemos comprobar el prototipo. Podemos observar el comportamiento de los usuarios. Podemos realizar pruebas de usabilidad. Podemos analizar datos de Google Analytics u otras herramientas analíticas. Podemos usar grabaciones de sesión o mapas de calor, siempre que se implementen cumpliendo requisitos de privacidad. Y también podemos, simplemente, hablar con los comerciales.
Esto último a menudo está subestimado.
El comercial oye a diario las preguntas de los clientes; sabe qué no entienden, qué les preocupa y qué información debe darse antes de la compra.
Es un conocimiento enorme para el diseño.
MVP no significa cualquier cosa
En proyectos digitales aparece con frecuencia el concepto MVP - Minimum Viable Product.
Se trata de la primera versión del producto que contiene el conjunto mínimo de funciones necesarias para verificar hipótesis y aportar valor a los usuarios.
MVP no debería significar: “Hagamos algo a medias y ya veremos después”.
Un buen MVP debería responder a la pregunta: “¿Cuál es la versión más pequeña de la solución que nos permitirá comprobar si vamos en la dirección correcta?”
Esto es muy importante también para webs y aplicaciones.
En vez de construir de entrada treinta funciones, a veces es mejor lanzar cinco prioridades y ver cómo las usan los usuarios. Después se desarrolla el sistema con base en datos reales, no solo en suposiciones de la primera reunión.
La web no termina el día de la publicación
Otra cosa que a menudo olvidamos.
El momento de publicar la web es en realidad el inicio de su vida real. Es entonces cuando aparecen los usuarios reales. Es entonces cuando vemos qué contenidos funcionan. Es entonces cuando sabemos qué elementos son ignorados. Es entonces cuando podemos comprobar si aumentó el número de consultas, las ventas, el tiempo en la página u otros indicadores que acordamos antes.
Por eso el proyecto debería seguir desarrollándose;
- Análisis.
- Conclusiones.
- Cambio.
- Prueba.
- Nuevo análisis.
Es más parecido a un ciclo que a un evento único.
¿Qué debería medirse realmente?
Depende del objetivo del proyecto.
Para una tienda online podrían ser:
- tasa de conversión,
- valor medio del pedido,
- abandonos de carrito,
- ingresos,
- valor del cliente en el tiempo.
Para una empresa de servicios:
- número de leads valiosos,
- tasa de conversión del formulario,
- número de consultas agendadas,
- coste de adquisición del lead,
- calidad de las consultas.
Para un sitio informativo:
- capacidad de encontrar información determinada,
- engagement de los usuarios,
- número de retornos,
- descargas de materiales.
No todo hay que medir. Pero sí hay que saber qué es importante.
Porque si la empresa quiere aumentar el número de consultas valiosas, solo aumentar el tráfico no implica éxito. Podemos tener diez veces más visitas y ni un cliente adicional.
¿El mayor error? Diseñar sin responder a “¿para qué?”
Se puede crear un sitio visualmente espectacular.
Se puede usar un stack tecnológico moderno.
Se puede preparar animaciones perfectas.
Se puede cuidar cada píxel.
Y, sin embargo, el proyecto puede no aportar a la empresa los resultados esperados. — ¿Por qué?
Porque faltó la respuesta a la pregunta más importante: ¿Para qué hacemos todo esto?
Si la respuesta es: “Porque la web antigua es fea”,
es un poco insuficiente.
Si, en cambio, es: “Queremos aumentar el número de consultas de clientes B2B, acortar el tiempo para encontrar el servicio adecuado y liberar al equipo de ventas de responder preguntas repetitivas”,
de repente tenemos un problema concreto que resolver.
Y podemos diseñar una solución.
En Web24 no queremos solo entregar sitios
Es la diferencia entre ejecutar un encargo y colaborar tecnológicamente.
Que el cliente llegue con una idea concreta no significa que nuestra tarea sea realizarla sin reflexión.
Nuestra tarea es también decir: “Esto tiene sentido”.
O: “Se puede hacer mejor”.
O: “Técnicamente podemos construirlo, pero no vemos justificación de negocio”.
O: “Antes de hacerlo, comprobemos si los usuarios realmente lo necesitan”.
A veces la mejor decisión de diseño es añadir una función. A veces es eliminarla. A veces es cambiar por completo las suposiciones.
Y ahí radica la experiencia del equipo: no en que podamos construirlo todo, sino en que podemos reconocer qué merece la pena construir realmente.
No hay dos proyectos iguales
Volvemos al punto de partida.
Podemos tener dos clientes del mismo sector. Dos fabricantes. Dos tiendas. Dos despachos. Dos software houses.
Sus sitios pueden parecerse. Pero no deberían ser iguales solo porque operan en la misma categoría.
Porque los diferencias la gente. La estrategia. El proceso de ventas. La oferta. El presupuesto. La tecnología. Los clientes. Los objetivos.
Y por eso cada proyecto requiere decisiones propias.
No siempre espectaculares. No siempre revolucionarias. — Pero conscientes.
La web como herramienta, no como adorno
Una web bien diseñada debería ser para la empresa algo más que una tarjeta de visita digital.
Debería ayudar al usuario a tomar una decisión. Facilitar la venta. Responder preguntas. Generar confianza. Apoyar a los empleados. Integrarse con otros sistemas cuando tenga sentido.
Y, sobre todo, debería cumplir un objetivo de negocio concreto.
Por eso no hay una única respuesta a la pregunta: “¿Cómo debe ser una buena página web?”
Mejor pregunta es: “¿Cómo debe funcionar la web de esta empresa concreta para ayudarle a alcanzar sus objetivos?”
Y esa debería ser la pregunta con la que empiece todo buen proyecto.
Para terminar - la regla más importante
No diseñamos una web para que el cliente pueda decir: “¡Qué bonita!”.
La diseñamos para que, después de unos meses, el cliente pueda decir: “Esto realmente nos ayuda a llevar el negocio”.
Porque la diferencia entre una web bonita y un buen producto digital a menudo no se ve en la primera pantalla.
Se ve solo en los resultados.
Resumen de toda la serie
En esta serie hemos examinado por qué no diseñamos dos páginas web iguales.
Comenzamos con una premisa simple: mismo sector no significa mismo negocio.
Luego mostramos cómo la estrategia de la empresa, la forma de vender, el público objetivo y las necesidades de los usuarios influyen en el UX, la arquitectura de la información y las funcionalidades.
En la última parte recorrimos el proceso de diseño: desde Discovery y conocer el negocio, pasando por User Flow, wireframes y Design System, hasta tecnología, integraciones, pruebas, analítica y desarrollo continuado.
Porque un diseño a medida no significa simplemente “un aspecto diferente”.
Significa decisiones distintas derivadas de un problema distinto.
Y por eso cada empresa debería recibir una solución diseñada para ella, no para la “empresa media del sector”.
