En corto: Definir objetivos no consiste en reunir funcionalidades ni en aceptar como problema la primera solución solicitada. Esta etapa identifica qué situación debe cambiar, qué necesita lograr el usuario, qué tarea debe soportarse y cómo se evaluará el avance.
El resultado será un marco de decisión. Todavía no indicará cuántas pantallas existirán, pero establecerá qué información, tareas y resultados tendrán prioridad.
Una ruta con un destino explícito
Esta serie propone seis etapas para transformar decisiones de Arquitectura de la Información en una base para el Diseño Táctico de Interacción. No se plantea como la única manera de diseñar una arquitectura ni como una secuencia sin retrocesos.
La ruta parte del texto Arquitectura de la información: diseño e implementación, de Celso Gonzales Cam. Allí, definir la misión antecede a la organización del contenido.
Uxicans amplía esa base para mostrar cómo cada etapa condiciona decisiones de interacción e interfaz. El artículo Por qué la Arquitectura de la Información sí condiciona el espacio gráfico desarrolla esa relación.
Qué significa definir objetivos
Un proyecto puede comenzar con frases como “se necesita un dashboard”, “hay que rediseñar el menú” o “se quiere una aplicación más sencilla”. Estas expresiones describen una solución anticipada o una intención general, pero todavía no permiten tomar decisiones de arquitectura.
Para construir un objetivo utilizable se separan cuatro niveles:
| Nivel | Pregunta que responde | Ejemplo |
|---|---|---|
| Resultado del negocio | ¿Qué situación espera mejorar la organización? | Reducir el retrabajo causado por solicitudes incompletas |
| Resultado del usuario | ¿Qué necesita conseguir la persona? | Saber si una solicitud puede avanzar y qué debe corregirse |
| Tarea | ¿Qué debe hacer para alcanzar ese resultado? | Revisar datos, identificar bloqueos y decidir el siguiente paso |
| Criterio de éxito | ¿Qué evidencia permitirá evaluar la solución? | La persona identifica los bloqueos y elige una acción adecuada sin recurrir a otro sistema |
Esta separación evita diseñar para una palabra vaga como “eficiencia” o para una pieza previamente elegida. Las necesidades deben orientar decisiones sin imponer una funcionalidad. La guía de GOV.UK también distingue lo que las personas intentan lograr de las características que se construirán.
Qué información debe reunirse
La definición comienza con lo que ya se conoce y hace visibles los vacíos. Conviene reunir:
- Problema, personas afectadas y tareas actuales.
- Consecuencias de mantener la situación.
- Resultados esperados por usuarios y negocio.
- Evidencia existente: investigación, analítica, incidencias, soporte, observación o procesos.
- Restricciones técnicas, operativas, legales y de accesibilidad.
- Decisiones tomadas y preguntas abiertas.
ISO 9241-210 incluye la comprensión del contexto de uso y la especificación de requisitos entre las actividades del diseño centrado en las personas. Por ello, estos objetivos serán provisionales y se revisarán al aparecer nueva evidencia.
Método: del Brief al marco de decisión
1. Preparar la conversación
Antes de la sesión conviene revisar la documentación y enviar un pre-read con:
- Descripción inicial, evidencia localizada y alcance de la conversación.
- Preguntas que requieren participación del negocio.
- Supuestos que necesitan confirmarse.
Así, la conversación puede concentrarse en las decisiones abiertas.
2. Realizar el Brief
El Brief es una conversación estructurada para comprender la petición. Unos 45 minutos pueden funcionar como referencia, pero la duración dependerá de la complejidad y la información disponible.
Las preguntas deberán descubrir el problema y no solamente recopilar requisitos:
- ¿Qué ocurre, quién se ve afectado y qué consecuencias produce?
- ¿Qué evidencia demuestra que el problema existe?
- ¿Quién realiza la tarea principal y qué intenta conseguir?
- ¿Cómo la resuelve actualmente y qué información necesita?
- ¿Qué debería cambiar si el proyecto funciona?
- ¿Cómo se observará ese cambio y qué queda fuera del alcance?
- ¿Qué reglas, permisos, dependencias y sistemas deben respetarse?
- ¿Existen condiciones legales, de seguridad o accesibilidad?
Una afirmación respaldada por investigación no debe mezclarse con una opinión del equipo.
3. Separar evidencia, supuesto y decisión
Después de la sesión, cada afirmación relevante se clasificará como:
- Evidencia: información observada o documentada.
- Supuesto: explicación o expectativa todavía no comprobada.
- Decisión: acuerdo adoptado para avanzar.
- Pregunta pendiente: vacío que puede cambiar el alcance o la solución.
Así se evita convertir una interpretación en un hecho. El artículo Cómo convertir hallazgos de investigación en decisiones de interfaz profundiza en esta trazabilidad.
4. Elaborar el Contrabrief
El Contrabrief devuelve una interpretación estructurada de la petición y hace visibles desacuerdos, límites y riesgos.
Debe incluir:
- Problema, objetivos y tarea prioritaria.
- Evidencia disponible.
- Alcance y exclusiones.
- Restricciones y dependencias.
- Supuestos y preguntas pendientes.
- Entregables y siguiente actividad de investigación.
Su aprobación confirma un entendimiento compartido; no demuestra que las hipótesis sean verdaderas.
5. Establecer criterios de éxito
Los criterios deben describir resultados observables. “Que guste” o “que se vea moderno” no explican si una tarea se resolvió mejor.
Según el proyecto, podrán considerarse:
- Finalización correcta, tiempo y esfuerzo.
- Errores y necesidad de ayuda.
- Comprensión del estado y del siguiente paso.
- Reducción de retrabajo, abandono o incidencias.
- Satisfacción posterior a la tarea.
Primero debe definirse qué comportamiento representa éxito y qué información permite establecer una línea base.
Ejemplo: sistema interno de solicitudes
Para ilustrar la serie se utilizará un caso ficticio. Se supone que una organización necesita mejorar un sistema interno donde el personal revisa solicitudes antes de enviarlas a formalización.
La petición inicial podría ser: “Se necesita una pantalla nueva con todos los datos y varios botones”. Después del Brief y el Contrabrief, el planteamiento cambia:
| Elemento | Definición provisional |
|---|---|
| Problema | La información necesaria para revisar una solicitud está distribuida y los bloqueos no siempre son visibles |
| Objetivo del usuario | Determinar si la solicitud puede avanzar y conocer qué debe corregirse |
| Tarea prioritaria | Revisar datos, identificar bloqueos y seleccionar el siguiente paso |
| Objetivo del negocio | Reducir devoluciones y retrabajo durante la formalización |
| Evidencia disponible | Registros de incidencias, documentación del proceso y entrevistas todavía por analizar |
| Criterio de éxito | La revisión se completa con la información necesaria y la acción elegida corresponde al estado de la solicitud |
| Restricciones | Permisos por perfil, reglas de validación y dependencia de datos procedentes de otros sistemas |
| Preguntas pendientes | Qué bloqueos impiden avanzar, quién puede corregir cada dato y qué acciones necesitan confirmación |
Todavía no puede afirmarse que la solución requiera una sola pantalla, pestañas, un asistente paso a paso o un dashboard. Esas decisiones dependerán del contexto, las rutas, el lenguaje y las reglas que se descubran después.
Entregable: matriz de intención
La etapa concluye con esta matriz:
| Campo | Contenido esperado |
|---|---|
| Objetivo del negocio | Cambio que la organización espera conseguir |
| Objetivo del usuario | Resultado que necesita alcanzar la persona |
| Tarea prioritaria | Acción o conjunto de acciones observables |
| Evidencia | Información que respalda el planteamiento |
| Criterio de éxito | Señal que permitirá evaluar el resultado |
| Restricción | Condición que la solución deberá respetar |
| Supuesto | Idea todavía no comprobada |
| Pregunta pendiente | Incertidumbre que puede cambiar una decisión |
La matriz servirá para comprobar si las decisiones posteriores responden al problema inicial.
Qué deja resuelto para la interacción
Esta etapa determina:
- La tarea y el resultado prioritarios.
- La información que podría ser crítica.
- Las restricciones que deberán reflejarse en reglas o estados.
- Las dudas que impiden diseñar todavía.
No determina la navegación, los rótulos, la búsqueda ni la distribución espacial. Su función es proporcionar el criterio con el que esas decisiones serán evaluadas.
Ejercicio
Elegir un proyecto y responder estas ocho preguntas:
- ¿Qué situación concreta necesita cambiar?
- ¿Qué evidencia demuestra que existe?
- ¿Quién intenta resolverla?
- ¿Qué resultado necesita alcanzar esa persona?
- ¿Cuál es la tarea principal?
- ¿Qué espera obtener la organización?
- ¿Cómo se reconocerá una mejora?
- ¿Qué supuesto podría invalidar el planteamiento?
Después, redactar un Contrabrief de una página. Toda afirmación deberá marcarse como evidencia, supuesto, decisión o pregunta pendiente.
Conclusión
Definir objetivos no significa congelar el proyecto ni decidir anticipadamente su interfaz. Significa construir un marco común para investigar y diseñar con dirección.
Cuando se distingue el problema de la solución, se equilibran los resultados del negocio y del usuario, y se hacen visibles los supuestos, la Arquitectura de la Información deja de comenzar con categorías o pantallas. Comienza con una tarea y con la evidencia necesaria para comprenderla.
La siguiente etapa utilizará este marco para definir el contexto: quién realiza la tarea, bajo qué condiciones, con qué conocimientos, restricciones y consecuencias. Esas variables comenzarán a transformar los objetivos generales en condiciones concretas para la interacción.
Leave a Comment