¿Cómo abordas la creación y el mantenimiento de un design system en varios productos?

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.

Explícame cómo llevas a cabo una prueba de usabilidad.

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.

¿Cómo colaboras con los product managers y los desarrolladores a lo largo del proceso de diseño?

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.

¿Cómo usas la IA en tu trabajo de diseño?

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.

Cuéntame sobre una vez en la que tu diseño recibió críticas duras en una revisión. ¿Cómo lo gestionaste?

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.

Describe una situación en la que la investigación de usuarios contradecía una decisión de diseño tomada por la dirección.

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.

Dame un ejemplo de una vez que tuviste que rebajar tu visión de diseño por restricciones técnicas.

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.

Guíame por tu proceso de portfolio para un proyecto reciente, desde el problema hasta el diseño publicado.

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.

¿Cómo decides cuándo usar un componente existente del design system y cuándo crear uno nuevo?

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ó.

¿Cómo verificas que una decisión de diseño mejoró realmente la métrica que buscaba mejorar?

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.

Product Designer

Las entrevistas para Product Designer evalúan tu capacidad para equilibrar las necesidades de los usuarios con las restricciones de negocio y técnicas a lo largo de todo el proceso de diseño. Los entrevistadores buscan dominio de los design systems, evidencia de que las pruebas de usabilidad han influido de verdad en tus decisiones, y un portfolio que puedas presentar con seguridad. Esta guía cubre las preguntas más frecuentes y las respuestas que consiguen ofertas.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Product Designer

Preguntas conductuales para puestos de Product Designer

Preguntas técnicas para candidatos a Product Designer

Lo que buscan los reclutadores en las entrevistas para Product Designer

Lo que los responsables de selección buscan realmente en los candidatos a Product Designer:

Un portfolio que puedas explicar en profundidad, no solo mostrar. Prepárate para preguntas de seguimiento sobre cualquier proyecto, incluidas las partes que no funcionaron.
Evidencia de que la investigación y las pruebas cambiaron de verdad una decisión, no solo validaron una ya tomada.
Soltura para trabajar dentro de un design system en lugar de tratar las restricciones como algo que combatir.
Comunicación clara con ingeniería sobre los compromisos, respaldada por ejemplos concretos y no por afirmaciones generales sobre saber trabajar en equipo.
Honestidad sobre un proyecto que se quedó corto y lo que cambió en tu proceso a raíz de ello.

Preguntas que puedes hacer al entrevistador

→¿Qué nivel de madurez tiene el design system aquí, y quién dirige su roadmap?
→¿Cómo es la relación entre diseño e ingeniería en el día a día?
→¿Cómo está organizada la investigación de usuarios: hay un investigador dedicado, o los diseñadores llevan sus propios estudios?
→¿Cómo se define el éxito para este puesto en los primeros 90 días?
→¿Cómo se validan las decisiones de diseño después del lanzamiento: qué métricas sigue realmente el equipo?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

Disponible en otros idiomas

English Français