Auditoría de la interfaz
Recorremos la aplicación entera y catalogamos lo que hay: cuántos botones distintos, cuántos tipos de tabla, cuántas formas de decir «guardar». La lista suele sorprender.
Diseño de producto para equipos de software
Cuando una aplicación crece, cada función nueva se añade donde cabe y no donde debería. Al año siguiente el equipo de soporte responde siempre las mismas cinco preguntas y nadie sabe cuál de las tres formas de hacer lo mismo es la buena. Ahí es donde entramos: ordenar lo que ya existe y dejar un sistema con el que lo siguiente se pueda diseñar sin volver a empezar.
- Sin rediseños de golpe
- Trabajo por flujos
- Entrega en Figma
Empezamos por los tres flujos que más soporte generan. Se rediseñan enteros, se prueban con usuarios reales y se implementan antes de tocar nada más. Un rediseño total de una aplicación en producción rara vez sale bien: se tarda demasiado en ver si funciona y, cuando falla, no hay forma de saber qué parte falló.
- Flujos primero
- Cambios medibles
- Sin big bang
Qué hacemos dentro de un producto
y en qué orden lo hacemos
Investigación con usuarios
Entre cinco y ocho entrevistas con clientes reales, más una lectura de los tickets de soporte de los últimos meses. Los tickets son investigación gratis y casi nadie los usa.
Rediseño de flujos
Alta, configuración inicial, la tarea que se repite cada día y la que se hace una vez al mes y siempre se olvida. Se rediseñan enteros, con sus estados y sus errores.
Sistema de componentes
Una biblioteca en Figma alineada con lo que el equipo puede construir de verdad, no con lo que sería bonito si el equipo tuviera el triple de tiempo.
Especificación
Cada pantalla se entrega con sus estados, sus mensajes y su comportamiento en móvil descritos, para que la implementación no tenga que improvisar.
Medición del cambio
Antes de tocar un flujo dejamos por escrito qué métrica debería moverse. Si no se mueve, lo revisamos en lugar de dar el rediseño por bueno.
Entregables
Lo que queda en tu equipo cuando terminamos
Todo se entrega en herramientas que ya usáis, con permisos vuestros y sin dependencias del estudio.
Biblioteca de componentes
Con variantes, estados y tokens enlazados. Cambiar un token repinta toda la biblioteca.
Flujos rediseñados
Pantalla a pantalla, con los caminos alternativos y los errores dibujados.
Especificación de implementación
Medidas, comportamientos, transiciones y textos de interfaz, listos para maquetar.
Guía de textos de interfaz
Cómo se nombran las acciones y cómo se escribe un error útil.
Prototipo navegable
Para probar con usuarios y para enseñar en una demo sin tener que construir nada antes.
Métricas de referencia
El estado de partida de cada flujo tocado, para saber después si el cambio funcionó.
Cómo entramos
Los tickets de soporte son el mejor documento de investigación
y ya los tienes escritos
Antes de la primera entrevista pedimos acceso a los tickets del último trimestre y los agrupamos por causa, no por fecha. Casi siempre aparece la misma imagen: un puñado de pantallas concentra la mayor parte de las preguntas, y suelen ser pantallas que nadie ha vuelto a mirar desde que se construyeron.
Eso da una lista de prioridades que no depende de la opinión de nadie. Y da algo aún más útil: una forma de comprobar si el rediseño ha servido, contando cuántos tickets de esa categoría llegan tres meses después.
Cómo salimos
Un sistema que el equipo puede usar sin nosotros
porque si no, dura lo que dura el contrato
Un sistema de diseño que solo entiende quien lo hizo no es un sistema, es una carpeta. Por eso la biblioteca se construye con las restricciones reales del equipo de desarrollo, se documenta con el criterio de uso —cuándo sí y cuándo no— y se traspasa en una sesión grabada con las personas que van a mantenerla.
A partir de ahí, cada pantalla nueva se compone. La responsabilidad del estudio no es dibujar todas las pantallas que existirán, es dejar el mecanismo con el que se dibujan.
Señales
Cuándo tiene sentido llamarnos
El soporte responde siempre lo mismo
Si cinco preguntas concentran la mitad de los tickets, no es un problema de documentación: es un problema de interfaz que se está pagando en horas de soporte todos los meses.
Hay tres formas de hacer lo mismo
Señal clásica de crecimiento sin sistema. Cada función se añadió donde cabía y ahora el usuario tiene que elegir un camino sin saber que hay otros dos.
Las demos se hacen siempre igual
Cuando el equipo comercial evita ciertas pantallas en las demostraciones, ya sabe cuáles son las que hay que arreglar. Solo hace falta preguntarle.
El alta pierde gente por el camino
Si entre el registro y el primer uso real se cae una parte significativa de los usuarios, el problema está en un flujo concreto y se puede aislar.
Diseño y desarrollo discuten cada semana
Casi siempre significa que falta un sistema compartido: no hay una fuente de verdad sobre qué componentes existen y qué se puede combinar con qué.
Nadie sabe qué pasa si falla
Cuando los estados de error no están diseñados, el usuario ve un mensaje del servidor. Es el momento en que más falta hace la interfaz y es el que casi nunca se dibuja.
Preguntas
Sobre el trabajo de producto
¿Trabajáis dentro de nuestro equipo o por vuestra cuenta?
Dentro. Nos incorporamos a vuestros canales y a vuestro ritmo de reuniones, con una demostración semanal de lo avanzado. Un estudio que desaparece un mes y vuelve con una presentación no funciona en producto.
¿Podéis también implementar el diseño?
La parte de web, sí. Dentro de una aplicación con sesión lo habitual es que implemente vuestro equipo, y nosotros entregamos la especificación y revisamos el resultado contra el diseño antes de que salga.
¿Cuánto dura un encargo típico?
Una auditoría con rediseño de dos o tres flujos y una primera versión del sistema de componentes suele ocupar entre seis y diez semanas. A partir de ahí, muchos equipos siguen con un acompañamiento mensual de menor intensidad.
¿Hace falta que tengamos usuarios para entrevistar?
Ayuda mucho, pero no es imprescindible. Si el producto es nuevo, trabajamos con entrevistas a personas del perfil objetivo y con pruebas de usabilidad sobre el prototipo, que sirven para lo mismo aunque den señales más débiles.
¿Y si lo que necesitamos es solo una web?
Entonces la página que te interesa es la de diseño web. El trabajo de producto tiene sentido cuando hay una aplicación con usuarios recurrentes; para un sitio corporativo es maquinaria de más.
Enséñanos la pantalla que más soporte genera
Con una captura y el contexto de qué intenta hacer ahí el usuario ya podemos decirte si el problema es de interfaz, de flujo o de expectativas.