Investigación aplicada
Entrevistas cortas con usuarios reales y revisión de lo que ya dice la analítica. Suficiente para decidir, no para escribir una tesis.
Inicio · Diseño UX/UI
Diseño UX/UI que quita pasos, no los añade
Para todo lo que tiene pantallas, formularios y gente intentando terminar algo. Empezamos por los flujos y los wireframes, montamos un prototipo navegable y lo probamos con personas reales antes de decidir un solo color.
Qué hacemos en un encargo de producto
Por orden, y sin saltarse el principio
Mapas de flujo
Cada tarea importante dibujada de principio a fin, con sus caminos alternativos y sus estados de error.
Wireframes
Estructura y jerarquía sin color ni tipografía, para que la conversación sea sobre el orden y no sobre el gusto.
Prototipo navegable
Un prototipo que se puede usar con el dedo, no un PDF con flechas. Es lo que se lleva a las pruebas.
Pruebas de uso
Cinco o seis sesiones grabadas, guion corto y un informe con lo que hay que cambiar ordenado por gravedad.
Sistema de componentes
La interfaz final como sistema: componentes con todos sus estados, tokens y reglas de composición documentadas.
Antes de rediseñar
La mayoría de los problemas de interfaz son de contenido
Cuando una pantalla no se entiende, casi nunca es porque el botón esté en el sitio equivocado. Es porque pide datos que el usuario no tiene a mano, porque el nombre del campo usa una palabra interna de la empresa o porque hace en un solo paso algo que la gente vive en tres momentos distintos.
- Cada campo tiene que ganarse su sitio Si un dato se puede deducir, calcular o pedir después, no se pide aquí.
- Las palabras son parte del diseño Etiquetas, mensajes de error y textos de ayuda se escriben en el wireframe, no al final.
- El error es una pantalla más Qué ve alguien cuando algo falla decide si vuelve a intentarlo o abandona.
Cómo se ordena
De la pregunta al componente
1
Encuadre
Qué tarea hay que resolver, para quién y cómo sabremos si ha mejorado.
2
Flujos
El recorrido completo dibujado, con caminos alternativos y estados de error.
3
Wireframes
Estructura y textos reales, sin color todavía, para discutir el orden.
4
Prototipo
Navegable en el dispositivo real, listo para ponerlo delante de alguien.
5
Pruebas
Seis sesiones, informe de problemas por gravedad y correcciones aplicadas.
6
Sistema
Interfaz final como componentes documentados y entregados al equipo técnico.
Dudas frecuentes
Sobre el diseño de producto
¿Seis personas son suficientes para una prueba de uso?
Para detectar problemas de usabilidad, sí: a partir de la quinta o sexta sesión los hallazgos se repiten. Seis sesiones no sirven para medir preferencias ni para validar una hipótesis de negocio, y no las usamos para eso. Sirven para ver dónde se atasca la gente, que es exactamente lo que hay que arreglar antes de construir.
¿Y si no tengo usuarios a los que preguntar todavía?
Se prueba con personas del perfil aunque no sean clientes: la mayoría de los problemas de interfaz no dependen de conocer tu producto. Cuando ni siquiera eso es posible, hacemos una revisión heurística documentada y lo decimos claramente, sin vender una investigación que no ha existido.
¿Trabajáis sobre un producto que ya está en marcha?
Sí, y suele ser el encargo más rentable. Auditamos los flujos críticos, revisamos lo que dice la analítica sobre dónde se cae la gente y proponemos una lista corta de cambios ordenada por impacto y por coste de implementación.
¿El sistema de componentes sirve para mi equipo técnico?
Está hecho para eso. Se entrega con tokens, estados, comportamientos en cada punto de ruptura y notas de implementación. Si tu equipo trabaja con una librería concreta, lo adaptamos a su nomenclatura para que no haya que traducir nada.
¿Hay una pantalla en la que se cae todo el mundo?
Cuéntanos cuál y qué debería pasar en ella. Con eso ya podemos decirte si esto se arregla con un ajuste o si hace falta rehacer el flujo entero.