QUÉ VAS A CONSEGUIR
Al terminar tendrás un brief inicial: para qué existe la web, quién la usará, qué información necesita y qué partes del proyecto todavía deben definirse.
Qué necesitas: una descripción de tu oferta, el material existente y una persona que pueda tomar decisiones. No necesitas saber programar.
01. Elige una función principal.
Empieza completando esta frase: “La web debe ayudar a que una persona pueda…”. Por ejemplo: entender un servicio y solicitar una conversación. Intenta describir una acción, no una aspiración como “tener presencia”.
Después separa lo principal de lo secundario. Presentar el equipo, compartir recursos y explicar el método pueden acompañar el objetivo sin competir por el mismo lugar.
EJEMPLO FICTICIO
Una consultora de operaciones quiere que responsables de empresas comprendan su servicio de diagnóstico y soliciten una reunión. La web no necesita vender un curso ni publicar novedades diarias para cumplir esa función.
02. Describe a la persona que llega.
En lugar de escribir “nuestro público es todo el mundo”, elige una situación: qué necesita resolver, qué sabe del problema y qué información le falta para conversar contigo.
Anota tres preguntas que esa persona podría hacer antes de contactar. En nuestro ejemplo: ¿qué revisa el diagnóstico?, ¿qué recibe la empresa? y ¿qué necesita preparar?
Estas preguntas se convierten en contenido y ayudan a elegir qué mostrar primero.
03. Revisa lo que ya tienes.
Prepara un inventario simple: servicios, textos, imágenes, identidad visual, formularios, materiales descargables y contenidos del sitio actual. Marca cada elemento como disponible, por revisar o por producir.
No es necesario escribir toda la web para pedir una propuesta. Sí conviene distinguir qué se puede reutilizar y qué trabajo adicional estás solicitando.
Cuando exista una web, incluye su dirección y quién administra el dominio, el hosting y los accesos. No envíes contraseñas dentro del brief.
04. Separa necesidades de preferencias.
Una necesidad podría ser editar las páginas de servicio sin pedir un cambio de código. Una preferencia podría ser usar una animación que viste en otra web. Ambas pueden conversar, pero no tienen la misma prioridad.
Identifica también integraciones y dependencias: agenda, CRM, idiomas, venta online, área privada o conexión con otra herramienta. Anota quién tomará decisiones y quién revisará los contenidos.
Si existe una fecha objetivo, explica por qué importa. Diferencia el lanzamiento de una campaña de una fecha deseada que todavía puede revisarse.
05. Comprueba que el brief se entiende.
Compártelo con alguien que no participó en su redacción. Pídele que explique, con sus propias palabras, qué debe hacer la web, para quién y qué elementos son imprescindibles.
Si no puede responder, el brief todavía necesita claridad. Si interpreta un proyecto muy distinto del que imaginabas, revisa las frases ambiguas antes de comparar propuestas.
El resultado no es un alcance cerrado. Es una base para conversar. Diseño, tecnología, calendario y presupuesto se completan al revisar el proyecto con el equipo responsable.
06. Convierte el brief en criterios de entrega.
Para comparar propuestas necesitas algo más que una lista de páginas. Escribe qué debería poder hacer una persona y cómo lo vas a comprobar. No se trata de definir toda la tecnología por adelantado, sino de evitar interpretaciones distintas del resultado.
- Una persona encuentra el servicio que necesita desde el menú y entiende qué incluye.
- El formulario confirma la recepción del envío y la consulta llega al destinatario previsto durante una prueba.
- Tu equipo puede corregir un texto y cambiar una imagen sin tocar código, en las partes acordadas.
- Las pantallas se revisan en móvil y escritorio, con enlaces y estados de error funcionales.
Estos criterios son ejemplos de aceptación del proyecto, no garantías automáticas de ventas ni de posicionamiento. Ajusta la lista a lo que realmente necesitas y acuerda qué pruebas se harán antes de entregar.
07. Separa el lanzamiento de la continuidad.
Una web puede estar entregada y seguir necesitando mantenimiento, nuevas páginas y revisión de contenidos. Pide que la propuesta distinga desarrollo inicial, producción de materiales, licencias, hosting, soporte y servicios recurrentes. Anota qué partidas son únicas y cuáles continúan después del lanzamiento.
También conviene especificar cuántas rondas de revisión incluye cada etapa y quién consolida los comentarios. Si varias personas aprueban por separado, registra cómo se resolverán sus diferencias antes de avanzar.
EJEMPLO FICTICIO / PARA PRACTICAR
La consultora del ejemplo necesita cinco páginas comerciales y un formulario. La integración con su CRM puede esperar. Separar esas etapas le permite evaluar un lanzamiento acotado sin asumir que el CRM está incluido en el mismo presupuesto.
08. Completa tu brief inicial.
Nombre y descripción del negocio: Objetivo principal de la web: Persona y necesidad que queremos atender: Acción principal que debería poder realizar: Servicios o contenidos imprescindibles: Material disponible y material por producir: Sitio actual, plataforma y responsables (sin claves): Integraciones o idiomas necesarios: Fecha objetivo y motivo: Responsable de decisiones y revisiones: Dudas que queremos resolver con la agencia:
Descargar plantilla de brief ↓
Archivo de texto vacío. No solicita datos ni requiere registro.
DEL BRIEF AL PROYECTO
¿Necesitas darle forma a tu web?
Podemos revisar el contexto y preparar un alcance de arquitectura, diseño y desarrollo.
Cómo usar la plantilla
Copia el archivo, responde con información real y marca las dudas como pendientes. Compártelo con las personas que aprobarán el proyecto antes de enviarlo a proveedores. Compara propuestas por alcance, responsabilidades y criterios de entrega, no solamente por el importe final.
Esta guía describe un método de preparación de Kizashi. No existe una extensión obligatoria de brief: lo importante es que el documento permita entender el proyecto y reduzca las decisiones implícitas.