"Quiero una web moderna, que se vea profesional y que me traiga clientes". Es la frase con la que empiezan muchísimos proyectos, y no tiene nada de malo. Quien dirige una panadería, una clínica o un despacho sabe mucho de su negocio y casi nada de páginas de aterrizaje, estructuras de navegación o formularios. No tiene por qué saberlo: para eso contrata a alguien.
El problema aparece cuando nadie lo dice en voz alta. El cliente cree que el desarrollador entiende lo que quiere, el desarrollador cree que el cliente ya lo ha decidido, y a mitad de proyecto descubren que imaginaban webs distintas. Lo que sigue es un resumen de cómo lo abordo para que eso no pase.
No saber qué quieres no es el problema
Lo que un cliente suele tener no es una especificación, sino un problema: "la gente no me encuentra", "mi web actual da vergüenza", "pierdo tiempo contestando siempre lo mismo por teléfono". Y eso es mejor punto de partida de lo que parece, porque un problema se puede resolver de varias maneras y una lista de funcionalidades cerrada de antemano, no.
Por eso, la primera reunión no sirve para decidir páginas ni colores. Sirve para entender qué tiene que cambiar en el negocio cuando la web esté publicada.
Las preguntas que hago antes de tocar nada
Ninguna es técnica, y casi todas incomodan un poco al principio:
- ¿Qué debería hacer una persona al entrar en tu web? Llamar, escribir, reservar, comprar, leer. Si hay cinco respuestas, hay que elegir una principal.
- ¿Quién es esa persona y cómo te encuentra hoy? Casi siempre sorprende lo poco que se había pensado.
- ¿Qué webs te gustan y qué te gusta de ellas? Y, sobre todo, cuáles no te gustan. Las referencias negativas aclaran más que las positivas.
- ¿Qué pasaría si la web no existiera? Es la forma más rápida de saber cuánto pesa realmente el proyecto.
- ¿Quién va a darle contenido y con qué frecuencia? Una web sin textos ni fotografías es un cascarón, y esta pregunta suele revelar la mayor fuente de retrasos.
- ¿Quién decide? Si hay tres socios con tres opiniones, mejor saberlo desde el primer día.
Enseñar antes de debatir
Cuando alguien no sabe describir lo que quiere, casi siempre sabe reconocerlo al verlo. Por eso prefiero poner algo delante cuanto antes: un esquema de páginas en una hoja, un boceto en baja fidelidad, una maqueta de una sola pantalla. No tiene que estar bonito; tiene que ser lo bastante concreto como para que alguien diga "esto no" o "esto sí, pero…".
Reaccionar ante algo tangible cuesta mucho menos que imaginar en abstracto, y cada "esto no" es una decisión que ya no hay que adivinar.
Cómo digo que no (o "ahora no")
Los cambios de alcance rara vez llegan como una gran petición. Llegan en forma de "ya que estamos, ¿podríamos añadir…?". Una sección, un buscador, un área privada, un chatbot. Cada una parece pequeña; juntas son otro proyecto.
Lo que me funciona:
- No responder "no" sin más, sino con el coste. "Se puede, supone dos semanas más y este importe" es una respuesta que deja la decisión en manos del cliente, en vez de en las mías.
- Tener un sitio donde aparcar ideas. Una lista de "fase dos". La mayoría de las ideas que parecían imprescindibles pierden urgencia al cabo de unas semanas, y las que no, son las que de verdad merecen la pena.
- Recordar el objetivo del principio. Si la web debía conseguir que te reserven cita, ¿esta funcionalidad ayuda a eso? Si la respuesta es que no, la conversación se simplifica sola.
- Decirlo pronto. Un "esto cambia el plazo" dicho el martes es una conversación; dicho la víspera del lanzamiento es un conflicto.
Qué dejo por escrito
No por desconfianza, sino por memoria. Después de cada reunión, un correo breve con lo que se ha decidido, lo que queda pendiente y quién tiene que hacer qué. Cuando alguien dice "yo pensaba que esto estaba incluido", se puede mirar sin que nadie tenga que acordarse de lo que se dijo hace seis semanas.
Y en el presupuesto, el alcance, las rondas de revisión y lo que queda fuera. Si te interesa ese lado, lo conté en cómo leer un presupuesto de desarrollo web.
Lo que pido al cliente
Esto también es una relación de dos. Lo que más ayuda es poco y concreto:
- Un interlocutor único que pueda decidir.
- Contenidos a tiempo, aunque sean imperfectos: es más fácil corregir un texto que esperar a que exista.
- Opiniones sobre el objetivo, no sobre el píxel. "No me transmite confianza" es útil; "mueve el logo tres milímetros" lo es mucho menos en una primera ronda.
- Honestidad cuando algo no convence. Un "no me gusta, pero no sé por qué" es información valiosa.
Un cliente que no sabe qué quiere no es un obstáculo: es el punto de partida habitual. El trabajo del desarrollador no consiste solo en construir lo que se le pide, sino en ayudar a descubrir qué conviene pedir. Cuando eso se hace bien, el proyecto termina siendo de las dos partes, y casi siempre sale mejor que cualquiera de las ideas con las que empezó.
