Product Designer

Trato un design system como un producto con sus propios usuarios: los diseñadores y desarrolladores que lo usan cada día. Antes de añadir un componente nuevo, compruebo si un patrón existente puede resolver el problema con una pequeña variante. Cada componente se entrega con pautas de uso claras, notas de accesibilidad y una implementación coherente entre Figma y el código, para que ambos nunca se desincronicen. Organizo una sesión abierta cada dos semanas donde cualquier diseñador o desarrollador puede plantear un hueco que haya encontrado en el sistema, y mantengo un backlog de propuestas que se revisa mensualmente en lugar de añadirse sobre la marcha. Cuando un componente cambia, audito todas las pantallas que lo usan antes de publicar la actualización, porque un fallo silencioso en un componente compartido tiene un impacto mucho mayor que un bug puntual. También sigo la adopción: si un patrón nuevo queda sin usar tras un trimestre, me pregunto si resolvía una necesidad real o solo parecía buena práctica en su momento.

Empiezo escribiendo un número reducido de tareas concretas ligadas al flujo que estoy probando, normalmente entre tres y cinco, formuladas como objetivos en lugar de instrucciones para no condicionar al participante. Recluto entre cinco y ocho usuarios que encajen con el perfil objetivo en lugar de recurrir a compañeros disponibles, porque los testers internos ya saben demasiado sobre el producto. Durante la sesión pido a los participantes que piensen en voz alta y evito explicar o defender el diseño cuando tienen dificultades. Anoto los momentos de duda, no solo los fallos evidentes, porque la duda suele apuntar a la misma confusión a menor escala. Después agrupo los hallazgos por patrones entre sesiones en lugar de tratar cada comentario como un bug aislado, y separo la severidad de la frecuencia: un problema raro que bloquea una tarea clave pesa más que un problema frecuente que cuesta solo unos segundos. Llevo el clip del momento más revelador a la presentación de resultados, porque un vídeo corto cambia una conversación con stakeholders más rápido que una diapositiva de hallazgos.

Involucro a ambos antes de tener una solución, no después. Con el product manager busco una claridad compartida sobre el problema y la métrica de éxito antes de abrir Figma, para no negociar el alcance cuando el diseño ya existe. Con los desarrolladores comparto exploraciones deliberadamente poco pulidas en lugar de un mockup terminado, porque una versión en bruto invita a un feedback real sobre la viabilidad, mientras que una versión pulida solo invita a asentir en silencio. Pregunto directamente a los desarrolladores qué sería costoso de construir, y trato esa información como un input real de diseño en lugar de una restricción contra la que luchar. Durante la implementación mantengo un papel activo con una revisión de QA de diseño en el entorno de staging, comprobando espaciados, estados y casos límite como los estados vacíos o de error, que suelen quedar relegados bajo presión de plazos. Cuando las prioridades entran en conflicto, intento reconducir la conversación hacia el problema de usuario acordado al inicio, lo que normalmente devuelve el debate a la evidencia en lugar de a las preferencias personales.

La IA aparece en varios puntos de mi proceso actual. Al principio la uso para generar variaciones rápidas de una idea de layout, lo que me da más puntos de partida antes de comprometerme con una dirección, mucho más rápido que dibujar seis versiones a mano. Para la investigación, la uso para resumir respuestas abiertas de encuestas o notas de entrevistas en grandes temas, aunque siempre reviso el resumen contra las transcripciones originales, porque a veces suaviza una contradicción importante. Para el microcopy de las interfaces, la uso para generar opciones de texto para botones, estados vacíos y mensajes de error, y luego edito yo mismo el tono y la brevedad. Donde no la uso es en las decisiones de fondo: qué debe comunicar el diseño, qué compromiso importa más para este usuario concreto, y cómo debe sentirse un flujo. Esas decisiones necesitan un contexto sobre el producto y el usuario que la herramienta no tiene, así que trato la IA como una forma de llegar antes a un primer borrador, no como un sustituto del razonamiento que viene después.

Presenté un rediseño del proceso de pago en una revisión ante nuestra head of design y dos product designers senior, y el feedback fue mucho más duro de lo esperado: varias personas consideraban que el nuevo flujo añadía un paso a un problema que no lo necesitaba. Mi primer impulso fue explicar mi razonamiento, pero me detuve y en su lugar pregunté qué evidencia concreta cambiaría su opinión, porque defender el trabajo en la sala no iba a resolver nada. Acordamos una prueba rápida sin moderador con ocho usuarios comparando el flujo antiguo y el nuevo en tiempo de finalización y confusión reportada. La prueba mostró que mi versión era en realidad más rápida, pero peor valorada en confianza: la gente no estaba segura de que el pedido se hubiera completado. Usé ese hallazgo para mantener el cambio estructural y añadir un estado de confirmación más claro, que respondía a la preocupación real detrás de la crítica en lugar de a la crítica tal como se había expresado. La versión revisada se publicó y los tickets de confusión en el pago bajaron alrededor de un 18% al mes siguiente.

La dirección quería simplificar nuestra página de precios eliminando la tabla comparativa de funcionalidades, partiendo de la idea de que abrumaba a los visitantes. Realicé cinco sesiones moderadas antes de que el cambio se publicara y encontré lo contrario: los usuarios en fase de comparación se apoyaban precisamente en esa tabla para justificar la compra ante ellos mismos o ante un responsable, y quitarla los hacía sentir menos seguros, no más. En lugar de limitarme a decir que los datos contradecían la hipótesis, llevé clips de dos sesiones donde los participantes volvían explícitamente a la tabla después de leer los nombres de los planes, junto con un resumen de para qué decían necesitarla. Propuse un punto intermedio: mantener la tabla pero moverla más abajo en la página, y añadir arriba un resumen condensado de tres filas para quienes quisieran la versión corta. La dirección aceptó probar ambas versiones en producción. La versión con resumen condensado y tabla completa superó a la página simplificada en conversión, y fue la que mantuvimos.

Diseñé un centro de notificaciones con actualizaciones en tiempo real y animaciones de entrada suaves para cada elemento nuevo, que se veía muy bien en el prototipo. Ingeniería avisó de que la capa de tiempo real prevista introduciría un retraso notable bajo carga, y que el enfoque de animación que había elegido sería costoso de implementar de forma coherente entre nuestras bases web y nativa dentro del sprint disponible. En lugar de insistir en mantener la versión original, pregunté qué era viable sin el enfoque cargado de animaciones y cómo sería un patrón de actualización algo más lento pero fiable. Terminamos con actualizaciones por polling cada pocos segundos y un fundido más simple, menos espectacular pero entregado a tiempo y sin fallos. Aprendí a incorporar a ingeniería antes, en la fase de concepto en lugar de en la del mockup ya pulido, para que este tipo de compromisos surjan antes de que me encariñe con una ejecución concreta. La versión simplificada funcionó bien en las pruebas con usuarios, que valoraban más la fiabilidad que el acabado de las animaciones.

Normalmente empiezo una presentación de portfolio por el problema tal como lo entendía el equipo al inicio, incluyendo la restricción que lo hacía difícil, no solo las pantallas finales pulidas. Para un proyecto reciente, un flujo de registro en varios pasos con una tasa de abandono del 40%, explico cómo primero confirmamos dónde se iban realmente los usuarios usando grabaciones de sesión y datos de embudo, en lugar de asumirlo por la longitud del flujo. Repaso dos o tres direcciones iniciales, incluyendo una que descarté y por qué, porque mostrar un camino equivocado demuestra un razonamiento real en lugar de un diseñador que acertó a la primera. Muestro la ronda de pruebas de usabilidad que cambió la dirección del diseño final, luego la versión publicada, y después el resultado: el abandono bajó del 40% al 27% en el mes siguiente. Termino con lo que haría diferente, que suele ser la parte más reveladora de la presentación, porque muestra si un candidato sigue aprendiendo de su propio trabajo.

Por defecto uso lo que ya existe, y trato un componente nuevo como algo que tiene que ganarse su lugar, no al revés. Antes de proponer algo nuevo, compruebo si el problema se puede resolver con un componente existente más una variante, una disposición distinta o un cambio de contenido, porque la mayoría de los huecos aparentes resultan ser un problema de layout y no un componente que falta. Si existe un hueco real, valoro si es probable que se repita en el producto o si es realmente puntual: un caso puntual suele resolverse con una solución local en lugar de un nuevo componente del sistema, porque añadir componentes poco usados a una librería compartida aumenta el coste de mantenimiento para todos. Cuando sí propongo un componente nuevo, lo llevo al equipo de design system o a una sesión de trabajo conjunta en lugar de publicarlo en silencio dentro de una sola funcionalidad, porque una incorporación sin revisar tiende a fragmentar el sistema en pocos meses, cuando otros diseñadores lo copian sin entender por qué se creó.

Defino la métrica objetivo y cómo voy a medirla antes de que el diseño se publique, no después, porque construir el plan de medición a posteriori tiende a producir una métrica que favorece lo que ya ha pasado. Para un rediseño reciente del onboarding enfocado en la tasa de activación, acordé con el equipo de datos el evento de activación exacto, la ventana de comparación y qué segmento de usuarios contaba antes del lanzamiento. Cuando es posible, publico detrás de un test A/B en lugar de un despliegue completo, porque una simple comparación antes y después no puede separar el cambio de diseño de la estacionalidad o de una campaña de marketing sin relación lanzada esa misma semana. También vigilo una métrica secundaria que capte un coste no deseado, para un cambio de onboarding podría ser el tiempo de finalización, por si un rediseño que sube la activación también ralentiza el flujo para quienes llegan hasta el final. Cuando termina la ventana de la prueba, reviso el resultado junto con el feedback cualitativo de los tickets de soporte o las grabaciones de sesión, porque una métrica puede moverse por una razón distinta a la que había asumido.