Product Designer
Descripción de puesto, salario, sourcing, 15 preguntas de entrevista y plan 30/60/90 para contratar un·a Product Designer en pymes españolas.
Compilado por el equipo de Join a partir de datos públicos y de nuestra experiencia en contratación.
Actualizado
De un vistazo
- Salario mediano 44.000 € 36.000 € – 56.000 €
- Plazo de contratación 45–75 días
- Experiencia 3–6 años
Cómo contratar a un·a Product Designer para su pyme
Antes de redactar la oferta, plantéese tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan los errores frecuentes en pyme y scale-up española.
Pregunta 1: ¿Product Designer, UX Designer o UI Designer? El·la Product Designer cubre el ciclo completo (research, encuadre, diseño de interacción, UI, handoff a ingeniería, medición de impacto) y participa en decisiones de producto. El·la UX Designer se centra en research, flujos y wireframes; el·la UI Designer ejecuta pantallas pulidas a partir de un brief. Muchas pymes españolas escriben Product Designer en la oferta pero esperan en realidad un perfil UI Designer (briefs cerrados, pocas decisiones autónomas, sin research). El resultado: el perfil contratado se frustra en 6-9 meses o no se llega a contratar nadie senior. Encuadre el scope real desde la oferta y comuníquelo de forma explícita en la entrevista.
Pregunta 2: ¿Generalista o especialista? Un·a Product Designer generalista cubre research, diseño de interacción y UI con un nivel intermedio en cada eje. Los perfiles especialistas (UX Researcher puro, Design System Designer, Motion Designer) son más profundos en su dominio pero más estrechos. En pyme de menos de 5 personas de diseño, generalista es casi siempre la opción correcta: la especialización solo se justifica a partir de cierto volumen de equipo y de complejidad de producto. Si duda, opte por generalista con una orientación ligera (más bien research o más bien sistemas) según la necesidad del momento.
Pregunta 3: ¿Qué porcentaje del tiempo dedicará a discovery frente a delivery? En pyme early-stage (producto en busca de PMF, menos de 3 millones de euros de ARR), un·a Product Designer mid-level pasa una parte significativa del tiempo en discovery: entrevistas, prototipos, validación de hipótesis. En pyme establecida (PMF estabilizado, equipo de producto formado), pasa más tiempo en delivery: pantallas finales, design system, handoff a ingeniería. El perfil ideal cambia: autonomía y disciplina empírica en el primer caso, rigor visual y operación de diseño en el segundo. Encuadre esta dimensión desde la propia oferta.
Si las tres respuestas convergen hacia un·a Product Designer generalista a jornada completa (y no a un perfil especialista o a un·a UI Designer puro), pase al modelo de oferta a continuación.
Modelo de descripción de puesto
Product Designer (todos los géneros) pyme o scale-up SaaS
Misión. Diseñar y pilotar la experiencia de uso de un producto o de un perímetro de producto: research de usuario, encuadre de problemas, diseño de interacción, UI, handoff a ingeniería y seguimiento del impacto. Trabaja en estrecha colaboración con un equipo de [X] personas de producto, [X] de ingeniería y las funciones de ventas, customer success y marketing. Reporta a [Head of Design / Head of Product / CPO / CEO].
Responsabilidades.
- Conducir research de usuario de forma continua: entrevistas, sesiones de usabilidad, prototipos, observación de comportamientos, lectura de señales cuantitativas.
- Encuadrar problemas de producto antes de proponer soluciones: hipótesis explícitas, alternativas exploradas, kill criteria documentados.
- Diseñar pantallas y flujos de extremo a extremo: estados de error, vacío y carga, accesibilidad básica (contraste AA, foco visible, jerarquía semántica), microcopy.
- Contribuir al design system: documentar nuevos patrones, proponer componentes cuando aparezca uso recurrente, mantener coherencia entre pantallas.
- Acompañar a ingeniería en el handoff: anotaciones útiles, dev mode o equivalente, revisión de implementación antes de release.
- Medir el impacto de los diseños entregados sobre métricas de uso (adopción, tarea completada, retención) y ajustar la trayectoria.
- Dinamizar critique sessions, divulgar decisiones de diseño al equipo más amplio (producto, ingeniería, ventas, customer success).
Perfil requerido.
- Imprescindible: 3 a 6 años de experiencia profesional en Product Design o en un rol equivalente; portfolio con 2-3 casos de estudio detallados (problema, restricciones, alternativas, decisión, impacto); experiencia de puesta en producción con ingeniería; familiaridad con un design system (uso o contribución).
- Valorable: experiencia en SaaS B2B o en scale-up (alta autonomía); familiaridad con métricas de producto (Mixpanel, Amplitude o equivalente); contribuciones a comunidades de diseño o publicación de casos en abierto.
- Excluyente: portfolio compuesto solo de mockups bonitos sin contexto; rechazo a hacer research; rechazo a tocar UI por considerarlo demasiado táctico.
Condiciones.
- Retribución bruta anual fija: [36-56] mil euros según experiencia. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
- Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
- Beneficios: [seguro médico, ticket restaurante, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación y conferencias de diseño, licencias de herramientas].
- Stack y herramientas: [a completar: diseño (Figma, FigJam), research (Dovetail, Maze, Notion), analítica (Mixpanel, Amplitude), prototipado (Figma, ProtoPie), design system (Figma libraries, Storybook)].
Banda salarial
Salario fijo bruto anual
Salario bruto anual de referencia para un·a Product Designer de nivel intermedio (3 a 6 años de experiencia profesional) en pyme o scale-up española. Madrid y Barcelona en entorno SaaS o scale-up tiran hacia arriba (50-65 k€); resto del territorio y sectores tradicionales tiran hacia abajo (30-40 k€). Perfiles con experiencia en design systems, research operativo o productos data-intensive tiran hacia arriba; perfiles puramente UI o muy junior tiran hacia abajo. El puesto rara vez incluye retribución variable estructural; algunas scale-ups ofrecen phantom shares o stock options.
Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 2659, Diseñadores gráficos y multimedia) ; InfoJobs, Estado del Mercado Laboral 2025 ; Product Hackers y comunidad ProductDesign.es, informe salarial 2025
Dónde captar este perfil
-
LinkedIn
Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job SlotsCanal principal para perfiles de Product Design en España, especialmente en Madrid y Barcelona. El sourcing activo (Recruiter Lite más InMails personalizados que hagan referencia a un caso publicado en el portfolio) supera con creces al simple anuncio: las personas candidatas senior ya no miran el feed de empleo. Filtre con precisión por tipo de producto (B2B SaaS frente a B2C o marketplace) y por familiaridad con design systems antes de contactar. Expectativa: entre el 50 y el 70 por ciento de las candidaturas cualificadas vendrán por aquí si el sourcing es activo. Los mensajes plantilla obtienen tasas de respuesta inferiores al 5 por ciento; los personalizados con referencia clara al producto y al caso publicado suben al 15-25 por ciento.
-
InfoJobs
Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €El portal con mayor volumen de candidaturas activas en España, útil como canal complementario fuera de Madrid y Barcelona (Valencia, Sevilla, Zaragoza, Bilbao) y para pymes tradicionales que aún no son visibles en comunidades de producto. Genera volumen, no siempre señal: filtre con portfolio obligatorio y una pregunta de cribado sobre proceso de diseño para no perder tiempo. Menos eficaz para perfiles con 5 o más años de experiencia en scale-ups tecnológicas, que rara vez aplican vía InfoJobs.
-
Dribbble, Behance y comunidades de nicho
Dribbble Pro Business desde 16 $ al mes; Behance gratis; Welcome to the Jungle desde 890 € por ofertaAudiencia de diseño orientada a portfolio en bruto. Dribbble pesa más en perfiles UI y visual; Behance integra mejor casos de estudio largos con explicación de proceso. Útil sobre todo para alcanzar a perfiles que no buscan activamente trabajo pero exponen su trabajo. Complemente con comunidades de nicho españolas (Slack de UX España, Designers in Madrid, Product Design ES en Discord) y con Welcome to the Jungle para pymes modernas: el cruce entre estos canales y LinkedIn rinde mejor que cualquiera por separado. Para perfiles con responsabilidad de design system, busque señales en portfolios públicos: tokens documentados, componentes reusables, decisiones explicadas.
Manual de evaluación
El puesto de Product Designer se evalúa en cinco etapas. La presentación de portfolio (etapa 3) y la prueba de diseño en situación (etapa 4) son las más predictivas: alguien puede hablar de proceso durante una hora sin revelar si realmente sabe encuadrar un problema y arbitrar bajo incertidumbre. Ponga a la persona a trabajar sobre un caso concreto.
-
Etapa 1: Lectura del CV y del portfolio
Busque coherencia entre lo que dice el CV y lo que muestra el portfolio. Señales positivas: 2-3 casos de estudio con problema, restricciones, alternativas exploradas, decisiones explicadas y métrica de impacto cuando exista. Señales negativas: portfolio compuesto solo de mockups bonitos sin contexto, casos en los que la persona candidata habla solo de ella misma en plural (nosotros decidimos) sin nombrar su aportación concreta, o ausencia total de research. La titulación pesa menos que los últimos 3-5 años de trabajo real.
-
Etapa 2: Phone screen (30 min)
Solo tres preguntas: (1) describa el caso del portfolio del que se sienta más orgullosa u orgulloso y cuál fue su aportación exacta, (2) qué decisión de diseño reciente sigue cuestionando hoy (humildad y retrospección), (3) por qué un cambio justo ahora. Salida: go o no-go en 5 minutos de debrief. Evite preguntas sobre herramientas o frameworks en esta fase.
-
Etapa 3: Presentación de portfolio (60 min)
La persona candidata presenta 2 casos de estudio de su elección durante 30 minutos, seguidos de 30 minutos de preguntas y respuestas. Pida que detalle el problema inicial, las restricciones, las alternativas exploradas y por qué descartadas, la decisión final y cómo midió el impacto. Idealmente con 2 personas entrevistadoras (una de diseño, una de producto o ingeniería). Scoring independiente antes del debrief.
-
Etapa 4: Prueba de diseño en situación (90-120 min)
Caso concreto extraído de su producto o de un producto adyacente: aquí hay un problema de uso o una funcionalidad por diseñar; cómo lo encuadra, qué research haría, qué propondría en 2 semanas. La persona candidata recibe el brief 48 horas antes, prepara un documento corto (5-8 pantallas anotadas o un Figma con notas) y presenta en 45 minutos seguidos de 45 minutos de Q&A. Pondere mucho en la decisión final. Esta etapa revela el razonamiento bajo incertidumbre, no el dominio de Figma.
-
Etapa 5: Referencias (verificación estructurada)
Llame a dos referencias: una persona ex-responsable (head of design, product manager o CPO) y una ex-compañera o ex-compañero de ingeniería que haya trabajado a diario con la persona candidata. Plantee a ambas las mismas cuatro preguntas: en qué destaca más, para qué perfil complementario contrataría a continuación, si la o lo volvería a contratar mañana y por qué, un ejemplo concreto de decisión difícil de diseño tomada bajo incertidumbre. La cuarta pregunta entrega la señal real; la segunda revela los puntos ciegos.
Preguntas de entrevista estructuradas
-
Conductual Decisión bajo incertidumbre Describa una decisión de diseño difícil que tomó en su último puesto. ¿Por qué era difícil y cómo la resolvió?
Lo que revela una buena respuestaCapacidad 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.
-
Conductual Coachability y aprendizaje Cuénteme una vez en la que un test con personas usuarias contradijo su intuición de diseño. ¿Qué pasó y cómo reaccionó?
Lo que revela una buena respuestaApertura 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.
-
Conductual Comunicación transversal Describa un desacuerdo importante con una persona de producto o de ingeniería sobre una decisión de diseño. ¿Cómo lo resolvió?
Lo que revela una buena respuestaPostura 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.
-
Situacional Juicio de producto Una persona Product Manager le pide rediseñar una pantalla por una percepción subjetiva (no se ve moderna) sin datos que apoyen la necesidad. ¿Cómo reacciona?
Lo que revela una buena respuestaCapacidad 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.
-
Situacional Pragmatismo y priorización Su empresa no tiene design system. Le piden uno antes de fin de trimestre y tiene un sprint de producto en paralelo. ¿Cómo lo encuadra?
Lo que revela una buena respuestaReconocimiento 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.
-
Situacional Métricas y research Una funcionalidad que diseñó hace 3 meses tiene una tasa de adopción del 15 por ciento, muy por debajo de la previsión. ¿Cómo investiga?
Lo que revela una buena respuestaMé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.
-
Caso práctico Research y discovery Discovery: queremos añadir a nuestro producto B2B SaaS una funcionalidad de invitación de miembros del equipo con roles diferenciados. ¿Cómo encuadra la fase de discovery a 4 semanas?
Lo que revela una buena respuestaMé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).
-
Caso práctico Diseño de interacción Diseño: queremos añadir a nuestra aplicación un sistema de notificaciones in-app. ¿Cómo lo diseña?
Lo que revela una buena respuestaAclaraciones 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.
-
Caso práctico Diseño de interacción Accesibilidad: la auditoría WCAG de su producto revela 80 issues de nivel A y AA. Tiene un trimestre para llevar el producto a cumplimiento AA razonable. ¿Plan de acción?
Lo que revela una buena respuestaPriorizació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.
-
Técnica Operación de diseño ¿Cómo organiza su trabajo en Figma para que ingeniería pueda implementar sin volver hacia atrás cada media hora?
Lo que revela una buena respuestaEstructura 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.
-
Técnica Design system Explique la diferencia entre tokens, componentes y patrones en un design system. ¿Cuándo extrae un patrón a componente, y cuándo prefiere mantenerlo como receta?
Lo que revela una buena respuestaComprensió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).
-
Técnica Research y discovery ¿Cómo conduce una sesión de usability testing? Describa la última que hizo: cuántas personas, qué tareas, qué aprendió.
Lo que revela una buena respuestaMé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.
-
Valores Coachability y aprendizaje ¿Cómo recibe una crítica fuerte sobre un diseño del que estaba convencida o convencido?
Lo que revela una buena respuestaApertura: 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.
-
Valores Mentoría y transmisión ¿Qué papel juega en la transmisión de criterio de diseño a perfiles junior o a personas no diseñadoras del equipo?
Lo que revela una buena respuestaPostura 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.
-
Valores Juicio de producto ¿Cuál es su lectura del oficio de Product Designer en 2026? ¿Qué ha cambiado en los últimos años, en su opinión?
Lo que revela una buena respuestaReconocimiento 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.
Cómo reconocer a un·a excelente Sales Manager
| Competencia | Por debajo | En el nivel | Por encima |
|---|---|---|---|
| Juicio de producto y de diseño | Confunde gusto personal con buen diseño. Sigue modas visuales sin espíritu crítico. No sabe distinguir un diseño que sirve a la persona usuaria de uno que sirve al ego de quien lo hace. Aplica patrones sin entender por qué. | Distingue una buena experiencia de uso de una mala y sabe argumentar por qué. Aplica patrones conocidos con consciencia de sus límites. Sabe cuándo desviarse del estándar y cuándo respetarlo. | Juicio informado por uso personal de 5-10 productos al mes, por lectura de referencias del oficio y por reflexión propia. Articula con claridad por qué un diseño gana o pierde y aplica esos aprendizajes a su trabajo. Forma al equipo en criterio de producto. |
| Research y discovery | Realiza pocas o ninguna entrevista; decide por intuición o por feedback indirecto (ventas, soporte). Confunde opinión de la persona usuaria con su comportamiento observado. Encuestas como sustituto de la observación. | Cadencia regular de sesiones de research (3-5 al mes entre entrevistas y usability testing). Sabe formular preguntas abiertas orientadas a comportamiento pasado. Distingue lo que la persona usuaria dice querer de lo que realmente hace. | Research continua y estructurada: ritual semanal de sesiones, prototipos probados antes de construir, kill criteria explícitos antes de cada iniciativa importante. Forma al equipo en research operativo. Mantiene un repositorio de insights accesible al equipo. |
| Diseño de interacción y rigor visual | Pantallas bonitas pero incoherentes entre sí. Estados de error, vacío o carga descuidados. Accesibilidad ignorada (contraste, foco, jerarquía). Sin atención al detalle (alineación, espaciado, microcopy). | Coherencia entre pantallas mediante uso de componentes existentes y respeto de los tokens. Estados de error, vacío y carga tratados de forma explícita. Atención al detalle en alineación, espaciado y microcopy. Accesibilidad básica respetada (contraste AA, foco visible). | Rigor visual y de interacción del nivel de productos de referencia (Stripe, Linear, Notion). Anticipa edge cases (offline, conexión lenta, dato grande o vacío, copy largo). Accesibilidad considerada desde el inicio, no atornillada al final. Diseños que envejecen bien. |
| Design system y operación de diseño | Sin disciplina de archivo en Figma. Componentes locales redundantes en lugar de uso del sistema. Sin documentación de decisiones. Handoff a ingeniería desordenado. | Estructura de Figma legible, uso correcto de componentes y tokens del sistema, anotaciones útiles para ingeniería. Documenta decisiones importantes. Sabe usar dev mode o equivalente para el handoff. | Contribuye al design system o lo eleva: documenta nuevos patrones, propone componentes nuevos cuando aparece uso recurrente, audita el sistema en busca de inconsistencias. Convenciones de handoff acordadas con ingeniería y respetadas. |
| Comunicación transversal | Explica mal su trabajo a perfiles no diseñadores. Postura defensiva en critique sessions. Trabaja en silo, comparte poco contexto. Postura de oposición sistemática frente a producto o ingeniería. | Sabe explicar su trabajo a una persona PM o de dirección en lenguaje claro. Recibe la crítica de forma constructiva. Comparte contexto en revisiones de equipo y 1:1. Negocia plazos de forma transparente. | Puente entre diseño, producto e ingeniería. Modera critique sessions, divulga decisiones, sabe traducir intuiciones de diseño a argumentos comprensibles para producto e ingeniería. Construye confianza con las demás funciones por su claridad. |
| Autonomía y resolución | Se bloquea horas con un tema desconocido sin pedir ayuda, o pide ayuda a la mínima dificultad. Sin estrategia de resolución estructurada cuando aparece una restricción no prevista. | Sabe avanzar en autonomía sobre temas familiares; pide ayuda tras una investigación previa (resumen del problema, alternativas exploradas, hipótesis a validar). | Alta resolución sobre temas no familiares: lee referencias, prueba prototipos, instrumenta su propio proceso. Documenta los aprendizajes para el equipo. Sabe avanzar con un dato incompleto sin paralizarse esperando el dato perfecto. |
Plan de 30/60/90 días
Día 30
- Setup completo del entorno (Figma, herramientas de research, acceso a métricas) y primera contribución de diseño (mejora pequeña o iteración sobre flujo existente) revisada y mergeada
- Lectura completa de la documentación de producto y de diseño (specs recientes, decisiones, retros) y primeras 5-8 sesiones de usabilidad o entrevistas en shadowing
- 1:1 documentado con la persona responsable de diseño o producto sobre convenciones, deuda identificada y prioridades del trimestre
- Mapa de los 3-5 proyectos de producto más estratégicos del trimestre y conocimiento del estado de cada uno
Día 60
- Entrega de una funcionalidad completa de principio a fin (research más diseño más handoff a ingeniería) en autonomía sobre un perímetro de tamaño medio
- Primera critique session moderada o primer documento de research escrito y compartido al equipo
- Cadencia de research instalada (mínimo 5-8 sesiones al mes) con repositorio de insights accesible
- Primera contribución al design system o a la documentación de patrones, validada con la persona responsable de diseño
Día 90
- Entrega regular (1-2 funcionalidades de tamaño medio al mes) con calidad validada por el equipo de producto e ingeniería
- Primera decisión de diseño en autonomía sobre un tema ambiguo (refactor de flujo, propuesta de nueva pantalla, arbitraje de prioridades de design system)
- Mentoría informal a una persona junior o a una nueva incorporación, o transmisión de criterio de diseño a producto e ingeniería
- Balance formal con la persona responsable de diseño o producto: rampa validada, plan de progresión sobre 1-2 ejes prioritarios para el siguiente trimestre
Errores comunes al contratar para este puesto
-
Contratar por estética del portfolio en lugar de por proceso
Un portfolio con pantallas muy pulidas no garantiza buen Product Design. Lo predictivo es el proceso detrás: cómo encuadró el problema, qué alternativas exploró, por qué descartadas, qué medía el impacto. Una persona candidata que solo enseña pantallas finales sin contar el camino suele revelar postura de pixel pushing antes que de diseño de producto. Pondere la presentación de portfolio y la prueba en situación por encima del lustre visual del CV.
-
Confundir UI Designer y Product Designer
Una persona UI Designer ejecuta pantallas a partir de wireframes o briefs de producto. Una persona Product Designer participa en discovery, encuadra problemas, prioriza, arbitra y ejecuta. Muchas pymes españolas escriben Product Designer en la oferta pero esperan un perfil UI Designer (briefs cerrados, pocas decisiones autónomas, sin research). El resultado: el perfil contratado se frustra en 6-9 meses o no se llega a contratar nadie senior. Encuadre el scope de forma explícita desde la oferta.
-
Subestimar la familiaridad con design systems
Un·a Product Designer en pyme tech española sin familiaridad con design systems no llega lejos: el equipo termina escribiendo CSS one-off, las pantallas divergen, ingeniería pide componentes y nadie los entrega. Verifique de forma explícita la familiaridad con tokens, componentes y patrones en la entrevista técnica, incluso si la empresa aún no tiene un design system propio. Quien no haya tocado nunca uno necesitará 3-6 meses de adaptación.
-
Ignorar la accesibilidad como criterio de cribado
La accesibilidad sigue siendo el punto ciego de la mayoría de los portfolios en España. Si su producto se vende a empresas grandes, al sector público o a clientes europeos, la accesibilidad pasará pronto de buena práctica a requisito (European Accessibility Act, vigente desde junio de 2025 para muchos productos digitales B2C, y obligatoria para licitaciones públicas). Verifique en la entrevista técnica que la persona candidata maneja los fundamentos (contraste, foco visible, jerarquía semántica, alternativas textuales) y los integra en su flujo, no como tarea de última hora.
-
Contratar perfil de gran corporación para pyme early-stage
Una persona Product Designer con 6 años en una gran corporación (BBVA, Telefónica, Inditex) ha aprendido a operar en marco estructurado: research dedicado disponible, design system maduro, copywriter en plantilla, briefs definidos por producto. En pyme early-stage, ninguna de estas condiciones se cumple. El perfil llega con expectativa de estructura, le cuesta operar en el caos y se desmotiva en 3-6 meses. Busque en su lugar un perfil que ya haya pasado por scale-up o pyme moderna; sabrá navegar la incertidumbre y montar lo que falte por el camino.
Preguntas frecuentes
-
¿Cuál es el salario de un·a Product Designer en pyme o scale-up española?
La horquilla de referencia para un·a Product Designer de nivel intermedio (3 a 6 años de experiencia) en pyme o scale-up española se sitúa entre 36 y 56 mil euros brutos anuales (mediana en torno a 44 mil). Madrid y Barcelona en scale-ups tecnológicas tiran hacia arriba (50-65 mil); resto del territorio y sectores tradicionales tienden al rango inferior (30-40 mil). Perfiles con experiencia en design systems o en research operativo tiran hacia arriba; perfiles puramente UI o muy junior tiran hacia abajo. Este puesto rara vez incluye parte variable estructural en pyme; algunas scale-ups ofrecen phantom shares o stock options como complemento.
-
¿Cuál es la diferencia entre Product Designer, UX Designer, UI Designer y Product Owner?
El·la Product Designer cubre el ciclo completo (research, encuadre, diseño de interacción, UI, handoff a ingeniería, medición de impacto) y participa en decisiones de producto. El·la UX Designer se centra en research, flujos y wireframes, pasando la fase UI a otra persona. El·la UI Designer ejecuta pantallas pulidas a partir de wireframes o briefs. El·la Product Owner pertenece a producto, no a diseño: define backlog y prioriza historias de usuario. En pyme española la denominación Product Designer es la más usada cuando se busca un perfil de espectro amplio; verifique siempre el scope real del puesto, no solo el título.
-
¿Cuánto tiempo lleva contratar a un·a Product Designer en España?
Cuente con 45 a 75 días entre la publicación de la oferta y la firma para un perfil mid-level. Los plazos se alargan en agosto y en torno a las navidades, así como cuando hay procesos de varias etapas (presentación de portfolio más prueba en situación más referencias). Reducir el plazo por debajo de 45 días suele implicar sacrificar la prueba de diseño en situación, lo que degrada de forma significativa la calidad de la contratación (es la etapa más predictiva).
-
¿Es necesaria una titulación específica para contratar a un·a Product Designer?
No. El mercado de Product Design en España acepta ampliamente perfiles procedentes de bootcamps (Ironhack, Le Wagon, IronHack UX), de carreras adyacentes (Bellas Artes, Diseño Industrial, Ingeniería) o autodidactas con 3-5 años de trabajo sólido en producción. La titulación pesa menos que el portfolio y la presentación. Evalúe sobre el proceso de diseño, sobre el rigor de research y sobre la capacidad de articular decisiones, no sobre el pedigrí académico.
-
¿Qué obligaciones legales tiene una oferta de Product Designer en España?
Cuatro obligaciones principales: (1) denominación neutra de género o con mención inclusiva (Estatuto de los Trabajadores y Ley de Igualdad); (2) registro horario obligatorio de la jornada (art. 34.9 del Estatuto de los Trabajadores, vigente desde 2019); (3) banda salarial visible en la oferta o comunicada antes de la primera entrevista (Directiva UE 2023/970 sobre transparencia retributiva, transposición antes del 7 de junio de 2026); (4) transparencia sobre cualquier herramienta de IA usada para el cribado y supervisión humana garantizada (EU AI Act, aplicable desde el 2 de agosto de 2026). Se aplica además el convenio colectivo correspondiente al sector y, en empresas con más de 50 personas, la cuota de reserva del 2 por ciento para personal con discapacidad.
-
¿Hay que pedir prueba de diseño en situación siempre?
Sí, pero corta y realista. Una prueba bien diseñada de 4-6 horas (con 48 horas de plazo para hacerla) es el mejor predictor del desempeño futuro, por delante del portfolio y del CV. Evite las pruebas tipo concurso de agencia (rediseñe nuestra home, sin contexto, sin acceso a research): filtran a las personas candidatas serias que ya tienen otras opciones y favorecen a quienes pueden invertir 20 horas por amor al arte. Acote el tiempo esperado de forma explícita, dé contexto suficiente y acepte propuestas incompletas pero bien argumentadas.