Product Designer

Capacidad de estructurar una decisión bajo incertidumbre: identificación de restricciones, compromisos explícitos, validación con personas usuarias o con datos, comunicación a producto e ingeniería. Bonus: la persona menciona haber cambiado de opinión durante el proceso o haber documentado la decisión para el equipo. Quienes describen una decisión obvia con perspectiva revelan que nunca llegaron a deliberar realmente.

Apertura al feedback contradictorio y disciplina empírica. Bonus: la persona cita la fuente concreta del cambio (una sesión de usabilidad, una métrica de tarea, un comentario recurrente) y el plazo entre la señal y la corrección. Quienes describen sus intuiciones como siempre validadas revelan una debilidad crítica de coachability para la función diseño.

Postura de partenariado frente a autoridad: capacidad de escuchar la visión de negocio o las restricciones técnicas antes de defender la propuesta, proponer un compromiso o un experimento, reconocer cuando la otra parte tenía razón. Quienes describen a producto o ingeniería como gente que no entiende el diseño revelan debilidad de juego transversal.

Capacidad de cuestionar el brief de forma constructiva antes de ejecutar: clarificar el problema percibido, proponer una observación o un test ligero antes de invertir en rediseño, distinguir gusto personal de problema de uso. Quienes ejecutan sin cuestionar revelan postura ejecutante de pixel pushing en lugar de Product Designer.

Reconocimiento de que un design system completo en un trimestre con sprint en paralelo es irrealista. Método esperado: empezar por un audit de patrones existentes, extraer los 10-15 componentes más usados, documentar tokens (color, espaciado, tipografía) antes que componentes, iterar al hilo de los proyectos en lugar de bloquear 3 meses. Bonus: la persona reconoce que el design system es un proyecto continuo, no un entregable de una vez.

Método estructurado: (1) verificar la instrumentación y la definición de adopción, (2) segmentar por cohorte, dispositivo y origen, (3) hipótesis ordenadas (problema de descubrimiento de la feature, problema de onboarding, problema de valor percibido, problema de uso real), (4) test de usabilidad con 5-8 personas para validar las hipótesis cualitativas. Quien salte directamente a rediseñemos sin diagnóstico revela sesgo de acción sin investigación.

Método de discovery: (1) hipótesis explícitas que validar (problema, fit, dispositivo de uso), (2) 5-8 entrevistas con personas usuarias actuales y prospects para entender los modelos mentales de rol y de equipo, (3) audit de patrones competidores y benchmark de tres a cinco referencias, (4) prototipo low-fi probado en 5-8 sesiones de usabilidad antes de pulir UI. Bonus: la persona menciona qué le haría decir no avanzamos por aquí (kill criteria explícitos).

Aclaraciones antes de proponer (volumen esperado, tipos de notificación, persistencia, criticidad por tipo, dispositivos soportados). Arquitectura coherente: jerarquía visual por criticidad, agrupación por tema o por origen, gestión de leídas y no leídas, comportamiento sin conexión, accesibilidad (lector de pantalla, contraste, foco). Bonus: la persona reconoce zonas de incertidumbre (validaría con un prototipo antes de comprometerme con la jerarquía final). Quienes se meten directamente en mockups sin aclarar restricciones revelan debilidad de diseño.

Priorización por impacto y por esfuerzo: (1) issues bloqueantes para personas usuarias con discapacidad (contraste insuficiente, falta de foco visible, errores de formulario no anunciados), (2) issues sistémicos que se solucionan en design system o en componentes compartidos antes que en pantallas aisladas, (3) issues puntuales en pantallas críticas (pago, alta, configuración). Bonus: la persona menciona que la accesibilidad no se arregla en una vez y propone un proceso recurrente (audit por iteración, checklist en code review). Quienes proponen arreglar todo a la vez sin priorizar revelan falta de pragmatismo.

Estructura de archivos clara: separación entre exploraciones, especificación final y design system; nomenclatura de componentes coherente; anotaciones de comportamiento (estados, transiciones, edge cases) cuando no son evidentes; documentación de tokens (color, espaciado, tipografía) cuando se aparta del sistema. Bonus: la persona menciona haber establecido convenciones con ingeniería sobre cómo entregar (handoff, dev mode, branches de Figma). Quienes responden Figma sin más matiz muestran inmadurez de proceso.

Comprensión de la jerarquía: tokens (valores atómicos: color, espaciado, radio, sombras), componentes (unidades reusables con interfaz definida: botón, input, modal), patrones (composiciones recurrentes: formulario de alta, cabecera de tabla con filtros). Criterio para promover a componente: uso en 3 o más sitios, interfaz estable, mantenimiento centralizado aporta más que copiar. Bonus: la persona menciona el riesgo de sobre-abstracción (componente muy parametrizado que termina menos legible que tres componentes simples).

Método estructurado: 5-8 personas participantes (rendimientos decrecientes a partir de 8), tareas realistas extraídas del producto y no descripciones genéricas, instrucciones cortas y abiertas (haga lo que haría normalmente en lugar de haga click aquí), observación silenciosa, debrief con preguntas abiertas. Bonus: la persona cita un aprendizaje que cambió la dirección del diseño. Quien no haya hecho una sesión de usability testing en los últimos 3 meses está desconectada o desconectado de sus personas usuarias.

Apertura: capacidad de separar el diseño del ego personal. Bonus: la persona cita una vez en que cambió de opinión gracias a una crítica recibida. Quienes describen haber explicado su intención a quien hacía la crítica en lugar de escucharla revelan una debilidad de coachability crítica para el trabajo en equipo.

Postura activa de divulgación: critique sessions estructuradas, pair design, documentación de decisiones, formación informal sobre buenas prácticas a producto e ingeniería. Quienes responden ayudo cuando me piden sin más concreción muestran una postura pasiva. En pyme con equipo de diseño reducido, la capacidad de elevar el criterio del resto del equipo es clave.

Reconocimiento de las evoluciones: subida de la IA generativa en herramientas de diseño y en flujos de research, fatiga de las modas visuales puras (neumorphism, glassmorphism), regreso a fundamentos de usabilidad y accesibilidad, presión creciente sobre la medición del impacto de negocio frente a la entrega de pantallas, papel ampliado del Product Designer en discovery cuando no hay research dedicado. Quien responde solo con herramientas o buzzwords revela postura superficial.