Decisiones clave
- Las tareas importantes están nombradas.
- Requisitos y supuestos se distinguen.
- Contenido y aprobación tienen responsables.
- Recursos pendientes y dependencias son visibles.
Empieza por la tarea del visitante
Elige entender un servicio, comparar opciones o enviar información necesaria. Nombra lector y siguiente paso. MDN aporta contexto para pensar antes del código; nuestra matriz organiza esa conversación. Una referencia estética sugiere dirección pero no define páginas o integraciones propias. No conviertas una función vista en otro sitio en requisito sin preguntar qué tarea resuelve para tu audiencia.
Asigna responsables de contenido
Para cada página importante identifica quién aporta hechos y quién aprueba. Marca textos, imágenes y traducciones como listos, pendientes o fuera de alcance. Guarda fuentes de afirmaciones materiales. Una descripción sin aprobar es dependencia de contenido, no solo tarea de diseño. Nombrar responsable permite detectar la decisión ausente antes del lanzamiento; distintas páginas pueden depender de personas y condiciones diferentes.
Separa requisitos de supuestos
Un requisito es comportamiento acordado; un supuesto necesita confirmación. Si el brief exige cuentas, pregunta qué tarea las necesita. GOV.UK aporta contexto para investigar necesidades mediante entrevistas. Mantén pregunta o prueba junto al supuesto en vez de presentar preferencias internas como demanda establecida. Lleva solicitudes nuevas a una lista separada para ver su efecto sobre el alcance ya decidido.
Conecta alcance y aceptación
Añade una prueba para requisitos importantes. Para descarga, indica archivo y origen del recorrido; para consulta, confirmación y destino revisados. La matriz no fija precio o plazo automáticamente: dependencias y operación aún necesitan conversación. El resultado permite describir alcance por escrito sin adivinar. Los puntos abiertos son válidos cuando se ven y se sabe quién debe resolverlos antes de implementar.
| Elemento | Evidencia necesaria | Decisión |
|---|---|---|
| Recorrido obligatorio | Tarea acordada y resultado esperado | Incluir y definir aceptación |
| Nueva idea opcional | Propósito, dependencias y esfuerzo por evaluar | Evaluar antes de ampliar el alcance |
| Integración desconocida | Documentación actual y ensayo limitado | Mantener abierta hasta resolver la evidencia |
Matriz ilustrativa de planificación; el acuerdo real define las condiciones del proyecto.
Haz el ejercicio
Crea una matriz para un curso ficticio bilingüe: tres tareas, responsables de contenido y un supuesto que necesite investigación antes de implementar.
Resultado esperado
Un brief con tareas, responsables, dependencias y pruebas. No establece presupuesto ni compromiso de entrega.
Tu lista de evidencias
Marca solo lo que hayas comprobado. Registra tu progreso, no una auditoría independiente ni una predicción. No hay guardado automático; descarga la nota si quieres conservarla.
0 / 6 comprobados
Preguntas y respuestas
¿Las referencias visuales sustituyen al brief?
Expresan una preferencia estética, pero no definen tareas, contenido ni aceptación. Añade una matriz pequeña para conectar apariencia y comportamiento. Así el equipo puede discutir lo que la web debe proporcionar en lugar de interpretar imágenes como requisitos completos.
¿Todo debe estar decidido antes de conversar?
No. Un buen brief hace visibles pendientes y responsables, orientando la conversación hacia hechos y compensaciones necesarios. Ocultar incertidumbre detrás de una lista larga dificulta entender cambios posteriores y no convierte un supuesto en una decisión acordada.
Siguiente paso
Un brief útil hace claras las tareas, las responsabilidades y los supuestos todavía pendientes.
Fuentes y comprobación
- MDN — Thinking before coding ↗
Comprobado:
- GOV.UK — In-depth research interviews ↗
Comprobado: