Introducción
Esta guía te permite preparar y entregar a un desarrollador web (o agencia) toda la información necesaria: objetivos, usuarios, alcance, diseños, requisitos técnicos, criterios de aceptación, calendario y comunicación. Sigue la lista de prerrequisitos y completa los 9 pasos numerados; utiliza las plantillas y checklists al final para estructurar la reunión o el brief escrito.
Prerrequisitos antes de empezar
Reúne lo siguiente antes de contactar al equipo técnico:
- Información básica: nombre del proyecto, URL (si existe), público objetivo y objetivo comercial principal.
- Activos y accesos: logotipos, paleta, tipografías, contenido existente y accesos a hosting/dominio.
- Decisiones iniciales: presupuesto aproximado, fecha límite y stack preferido (si lo hay).
- Personas: stakeholders y la persona responsable de aprobaciones.
Tutorial paso a paso (9 pasos)
- Objetivo y métricas: define propósito claro y KPIs (ej.: +20% ventas, 300 leads/mes). Indica cómo medir (Google Analytics, GTM, eventos).
- Usuario y casos de uso: 3–5 user personas con escenarios concretos y flujos principales (búsqueda, registro, checkout).
- Alcance y prioridad (MVP): lista funcionalidades y clasifícalas en MUST/SHOULD/COULD.
- Contenido y estructura: sitemap propuesto, volumen de páginas/productos y responsables de entrega.
- Diseño y referencias: entrega wireframes/mockups (Figma) y ejemplos con comentarios.
- Requisitos técnicos: integraciones (CRM, pasarela), rendimiento objetivo, SEO y accesibilidad AA si aplica.
- Criterios de aceptación: usa formato Given/When/Then para cada funcionalidad clave.
- Plazos y presupuesto: milestones, entregables, rondas de revisión y límites de presupuesto.
- Comunicación y herramientas: canales (Slack/Teams), repo (GitHub), gestión (Jira/Trello), staging y roles.
«Prioriza el MVP: entregar lo imprescindible primero reduce riesgos y acelera aprendizaje.»
Plantillas prácticas y ejemplos
- One-pager del proyecto: objetivo, KPIs, público, MVP, tecnologías y presupuesto.
- Lista de user stories: «Como [usuario] quiero [acción] para [beneficio]» con criterios.
- Sitemap y wireframes anotados: comportamiento, validaciones y modales.
- Checklist de lanzamiento: SSL, analytics, pagos, backups, monitorización.
- Email/brief para el desarrollador: enlaces, accesos y contacto.
Criterios de aceptación: formato y ejemplo
Recomiendo usar Given / When / Then e incluir métricas concretas (tiempos, límites).
Ejemplo práctico:
Given: usuario con cuenta y 3 pedidos anteriores. When: inicia sesión desde móvil y accede a «Mis pedidos». Then: debe ver listado de pedidos en menos de 2s y poder filtrar por estado.
Comunicación y gestión de proyecto
| Propósito | Herramienta recomendada |
|---|---|
| Comunicación rápida | Slack / Teams |
| Control de versiones | GitHub / GitLab |
| Backlog y tareas | Jira / Trello / Notion |
| Prototipos | Figma |
Errores comunes y buenas prácticas
- Errores: usar términos vagos, entregar contenido incompleto, no priorizar el MVP.
- Buenas prácticas: documentar por escrito, mockups para pantallas críticas y un product owner único.
- Negociar cambios: pacta tarifas para extras y milestones para revisar alcance.
Checklist final antes de la reunión
- Objetivo, KPIs y público definidos.
- Sitemap, mockups y lista priorizada (MUST/SHOULD/COULD).
- Accesos (hosting, APIs), persona de contacto, presupuesto y fechas.
- Criterios de aceptación y plan de staging/despliegue.
Preguntas frecuentes
- ¿Qué entregar primero? One-pager + sitemap + accesos básicos.
- ¿Cómo priorizar con poco presupuesto? Define MUST estrictos y mueve resto a backlog.
- ¿Wireframes o mockups? Mockups para pantallas críticas; wireframes para resto.
- ¿Elegir stack antes? Solo si tienes restricción; si no, deja al desarrollador proponer.