Antes de diseñar una web conviene definir qué tiene que resolver, para quién y con qué recursos se va a sostener. Figma sirve para representar decisiones; no reemplaza la definición del problema. Empezar por pantallas cuando esas preguntas siguen abiertas puede producir una propuesta visual convincente que después no encaja con el contenido ni con la operación del negocio.
No hace falta convertir cada sitio en un proyecto de investigación enorme. Sí hace falta distinguir lo que sabemos, lo que estamos suponiendo y lo que necesitamos comprobar. Un brief inicial permite tener esa conversación sin esconder las dudas detrás de una referencia estética.
Un objetivo que describa una acción
“Tener presencia” puede ser una motivación, pero deja demasiadas decisiones abiertas. Es más útil definir si la web debe recibir consultas, explicar un producto, permitir una compra o ayudar a encontrar información. Una acción principal no impide que existan otras: establece qué recorrido necesita mayor claridad y qué contenido lo sostiene.
También conviene acordar qué significa una consulta relevante. No alcanza con sumar envíos si todos preguntan por un servicio que no se ofrece. La definición puede incluir el tipo de necesidad, la información mínima para responder y quién continúa la conversación. Eso no garantiza resultados; permite evaluar si el sitio representa bien la propuesta.
Personas, situaciones y tareas
Describir al público como “empresas” no explica qué necesita quien llega a una página. Una persona puede estar comparando proveedores, buscando una respuesta puntual o revisando si una recomendación le sirve. Cada situación cambia la información que debería aparecer primero y la profundidad que necesita antes de actuar.
Cuando no hay evidencia, se pueden registrar escenarios como supuestos del brief. Por ejemplo: “Suponemos que quien consulta necesita entender el alcance antes de hablar”. La siguiente pregunta es cómo comprobarlo, no cómo convertir esa frase en una conclusión. Analítica disponible, consultas recibidas y pruebas de tareas pueden aportar información, con límites distintos.
El contenido disponible también define el diseño
Un inventario simple evita diseñar secciones que después nadie puede completar. Conviene reunir descripciones de servicios, imágenes propias, documentación, datos de contacto y ejemplos que se puedan publicar. Si falta material, hay que decidir quién lo produce y cuándo, en lugar de resolverlo con frases genéricas que no ayudan a elegir.
Ese inventario debe incluir restricciones. Un caso no puede presentarse como un encargo real si es una propuesta independiente. Una fotografía puede necesitar autorización. Un servicio puede tener condiciones que no entran en una card. Diseñar con contenido representativo permite detectar esos problemas antes de aprobar una composición.
Ordenar páginas y recorridos antes de los detalles
La arquitectura relaciona preguntas con lugares donde responderlas. Una home suele introducir la oferta; una página de servicio puede explicar alcance y condiciones; una consulta permite describir una necesidad. No todas las dudas necesitan una página nueva. Algunas pertenecen a una sección y otras requieren un enlace a contenido relacionado.
Un mapa del sitio y un flujo breve ayudan a revisar ese orden. Importa comprobar si se entiende cómo llegar a cada contenido, cómo volver y qué pasa después de la acción principal. Es distinto evaluar esa estructura que discutir el tamaño de una imagen. Ambas decisiones importan, pero resuelven problemas diferentes.
Ejemplo hipotético: consultas por servicios
Imaginemos una empresa de mantenimiento que recibe mensajes poco específicos. El objetivo del sitio sería ayudar a explicar la necesidad antes del contacto. No podemos concluir que el formulario actual es la causa: quizá la oferta está mal descrita o el tráfico llega buscando otra cosa. El brief registraría esas posibilidades por separado.
Una propuesta inicial podría agrupar servicios por problemas reconocibles, explicar qué incluye cada uno y mantener el servicio elegido al abrir la consulta. El formulario pediría ubicación y una descripción breve, solo si esos datos sirven para responder. La revisión comprobaría si una persona puede identificar el servicio y explicar su situación, no si le gusta un color.
Restricciones que conviene conocer temprano
La web seguirá cambiando después de publicarse. ¿Quién edita los textos? ¿Qué contenido cambia con frecuencia? ¿Hay integraciones necesarias? ¿Quién responde si un formulario falla? Esas respuestas afectan componentes, plataforma y alcance. Un diseño que exige intervención técnica para cada cambio puede ser inadecuado para el equipo que lo mantiene.
También hay límites de tiempo y material. Se puede priorizar un recorrido inicial y dejar funciones posteriores fuera del alcance, con una decisión explícita. Postergar una función no es lo mismo que dibujarla y suponer que ya está incluida. Esa distinción permite comparar propuestas y evitar sorpresas durante la implementación.
Preguntas para un brief útil
- ¿Qué acción principal debería poder completar quien visita el sitio?
- ¿Qué necesita entender antes de hacerla y qué dudas aparecen hoy?
- ¿Qué páginas, textos e imágenes existen y quién puede aprobarlos?
- ¿Qué funciones son necesarias y cuáles podrían quedar para otra etapa?
- ¿Quién recibe las consultas y qué información necesita para responder?
- ¿Quién actualizará la web y qué conocimientos tiene?
- ¿Qué evidencia tenemos y qué supuestos deberíamos validar?
El siguiente paso es transformar esas respuestas en alcance y recorridos. Podés revisar qué definir antes de contratar, distinguir posibles obstáculos en una web con visitas pero sin consultas y acordar los entregables de UX/UI. Si necesitás ordenar ese punto de partida, podemos trabajar la estructura y el diseño antes de elegir cómo se verá cada pantalla.
