Un proyecto UX/UI puede incluir mucho más que pantallas terminadas: definición del problema, recorridos, arquitectura, componentes, estados y documentación para construir. El alcance depende de la necesidad. No todas las propuestas requieren los mismos entregables, y una lista extensa no garantiza que las decisiones estén bien fundamentadas.
Conviene revisar para qué sirve cada pieza y qué pregunta permite responder. Una pantalla explica parte de la interfaz; un flujo muestra continuidad; un prototipo permite explorar comportamientos. Investigación y validación requieren trabajo específico y no deberían darse por hechas porque un archivo incluye una sección llamada “usuarios”.
Definir el problema y sus límites
El punto de partida debería identificar una situación, una necesidad y las restricciones conocidas. También tiene que separar evidencia de supuestos. “La gente no encuentra los filtros” puede ser una hipótesis del equipo o una observación documentada; no son lo mismo. El proyecto necesita saber qué información respalda la decisión y qué falta comprobar.
Definir límites ayuda a evitar que cada conversación amplíe el trabajo sin una decisión. Si se diseña búsqueda y consulta, un sistema de pagos no queda incluido porque aparece como posibilidad en una reunión. El alcance debería nombrar recorridos, roles y exclusiones, y revisarse cuando cambia la necesidad.
Flujos y arquitectura
Un flujo explica cómo comienza, continúa y termina una tarea, incluyendo retornos y alternativas. Puede mostrar qué pasa cuando falta un dato o cuando una acción falla. La arquitectura organiza contenidos y accesos. Ambos ayudan a revisar el recorrido antes de discutir detalles visuales, pero no sustituyen la observación de uso.
Para revisarlos, conviene elegir una tarea realista y seguirla paso a paso. ¿Se entiende desde dónde empieza? ¿Hay decisiones sin salida? ¿El sistema conserva información cuando se vuelve? Un diagrama muy completo puede esconder problemas si nadie lo contrasta con una situación concreta y con las reglas del producto.
Wireframes para discutir jerarquía
Un wireframe permite revisar contenido, orden y acciones sin comprometerse todavía con todos los detalles visuales. Su nivel de definición depende de la pregunta. Puede ser suficiente para acordar la estructura de una ficha, pero necesitar más precisión si se discute una interacción o una combinación de estados.
No conviene tratarlo como un trámite que siempre hay que producir por separado. A veces el proyecto necesita esa etapa; otras, una estructura ya definida permite avanzar directamente a una propuesta de interfaz. Lo importante es no perder la discusión sobre prioridades porque el archivo tiene colores y parece terminado.
Interfaz, componentes y estados
La interfaz establece jerarquía, tipografía, contraste, controles y relación entre contenidos. Los componentes ayudan a mantener esa lógica entre pantallas. Para que sean útiles, deben incluir variantes necesarias y no solamente una colección de elementos aislados. Un botón, un campo o una card se evalúan dentro de un recorrido.
Los estados forman parte del diseño: vacío, carga, error, selección, éxito y permisos pueden cambiar la experiencia. Si solo se muestra el camino correcto, quien implementa deberá inventar respuestas para todo lo demás. También hay que revisar foco, teclado y alternativas al hover, según las interacciones que usa el producto.
Qué revisar en una entrega
| Pieza | Criterio útil |
|---|---|
| Definición | ¿Problema, supuestos y límites quedan diferenciados? |
| Flujos | ¿Incluyen tareas, retornos y fallas relevantes? |
| Arquitectura | ¿Cada contenido tiene un lugar y un acceso reconocible? |
| Interfaz | ¿Jerarquía y controles responden al recorrido? |
| Componentes | ¿Variantes y estados son consistentes entre pantallas? |
| Prototipo | ¿Se explica qué simula y qué permite evaluar? |
| Handoff | ¿Reglas, recursos y dudas pendientes permiten construir sin adivinar? |
Esta lista permite revisar calidad y cobertura, no exigir todos los archivos en cualquier proyecto. Un alcance pequeño puede tener menos piezas. Lo que no conviene omitir es la explicación de qué se decidió, por qué y qué queda pendiente antes de implementar.
Ejemplo hipotético: buscar y consultar un equipo
Un catálogo profesional necesita que una persona encuentre un equipo, compare características y consulte por una opción. El flujo identifica búsqueda, ficha, comparación y contacto. La arquitectura ordena categorías y especificaciones. Los wireframes permiten revisar qué información aparece antes de la consulta, sin suponer que todos conocen los nombres técnicos.
La interfaz define componentes de resultado y comparación; los estados incluyen información no disponible y una búsqueda vacía. El prototipo simula la elección de dos equipos y el retorno a una ficha. No demuestra que el producto resuelva todas las necesidades técnicas. Una validación tendría que definir participantes, tareas y criterios adecuados para esa situación.
Prototipo y documentación para construir
El handoff debería comunicar comportamiento, contenido, recursos y reglas responsive. También conviene registrar dudas abiertas: una integración sin definir no se vuelve concreta por estar dibujada. Quien implementa necesita saber qué puede editarse, qué datos llegan de otro sistema y cómo se representa una falla.
La revisión con desarrollo puede detectar dependencias antes de cerrar el diseño. No se trata de reducir toda decisión a lo que ya existe, sino de entender costo, riesgo y alternativas. Una especificación útil permite discutir esas condiciones; una colección de capturas obliga a interpretarlas individualmente.
Para definir un proyecto, empezá por el problema y el brief, acordá responsabilidades y alcance y revisá un recorrido específico, como la búsqueda con filtros. Si necesitás diseñar un producto, podemos delimitar el trabajo UX/UI según esas tareas, sin confundir pantallas entregadas con validación realizada.
