Las preguntas antes del código

La mayoría de los proyectos web malos fallan en la fase de briefing, no en el desarrollo. Alguien tuvo apuro en arrancar y no pasó suficiente tiempo entendiendo qué estaba tratando de resolver.

Cómo se ve la fase de descubrimiento

Empezamos haciendo preguntas que pueden parecer obvias: quién usa el sitio hoy, qué está tratando de hacer, qué se lo impide. Preguntamos cómo se ve el éxito dentro de doce meses, no cómo debería verse el sitio.

Las respuestas generalmente revelan algo diferente al pedido inicial. Un cliente llega queriendo un rediseño. Recibe tráfico pero la gente no convierte. Eso no es un problema de diseño. Es un problema de contenido o estructura. El rediseño hubiera sido caro y equivocado.

Por qué cuestionamos los pedidos iniciales

No somos escépticos de lo que piden los clientes. Estamos tratando de entender qué necesitan realmente. A veces es lo mismo. Frecuentemente no.

Cuando un cliente dice que necesita un sitio nuevo, preguntamos: qué no está funcionando del actual. Cuando dice que necesita más funciones, preguntamos: qué usuarios necesitan esas funciones y qué harían con ellas. Cuando dice que quiere posicionar mejor en búsquedas, preguntamos: qué quieres que pase después de que alguien te encuentre.

Las preguntas llevan tiempo. Valen la pena.

Qué se construye como resultado

Alcance más claro. Menos retrabajos. Sitios que hacen lo que tienen que hacer.

No empezamos a diseñar ni a construir hasta entender el problema. No es proceso por el proceso. Es cómo evitamos construir lo que no corresponde.

Cuéntanos qué estás tratando de resolver.