Product Design: decisiones que importan

El trabajo real del product designer

Diseñar productos digitales tiene poco que ver con pixel perfecto y mucho con entender qué problema estás resolviendo. La diferencia entre un buen diseñador y uno que solo empuja archivos de Figma está en la capacidad de tomar decisiones informadas, defender esas decisiones con datos y criterio, y saber cuándo ceder.

El product design vive en la intersección de tres fuerzas: las necesidades del usuario, los objetivos del negocio y las posibilidades técnicas. Cualquier diseño que ignore una de estas tres patas termina siendo teoría bonita que nunca se implementa o se implementa mal.

Diseño centrado en el usuario (de verdad)

Hablar de diseño centrado en el usuario se volvió lugar común. Todos dicen que lo hacen, pocos lo practican con rigor. Centrar el diseño en el usuario no significa preguntarle qué quiere y construir exactamente eso. Significa observar cómo trabaja, dónde se traba, qué frustraciones tiene y diseñar soluciones que resuelvan esos problemas de forma elegante.

Research que sirve

El research no es una etapa opcional que se hace "si hay tiempo". Es la base de cualquier decisión de diseño que valga la pena. Algunas técnicas concretas:

• Entrevistas de usuario: conversaciones estructuradas con usuarios reales para entender contexto, motivaciones y problemas. No ventas disfrazadas, conversaciones reales.
• Testing de usabilidad: poner un prototipo o producto frente a usuarios y observar cómo lo usan. Las mejores insights vienen del silencio mientras alguien se traba en algo que para vos era obvio.
• Analytics cualitativos: mirar grabaciones de sesiones, heatmaps, flujos de abandono. Los números te dicen qué pasa, las sesiones te muestran por qué.

El error frecuente es hacer research y después ignorarlo porque "el stakeholder quiere otra cosa". Si el research contradice la intuición del negocio, esa tensión es información valiosa que hay que navegar, no esconder.

Tradeoffs y decisiones de diseño

Todo diseño es un tradeoff. Cada decisión que tomás abre una puerta y cierra otras. El diseñador que no entiende esto termina diseñando features que suenan bien en teoría pero que son imposibles de construir, mantener o escalar.

Ejemplos reales de tradeoffs

Flexibilidad vs simplicidad: podés darle al usuario mil opciones de configuración o podés elegir buenos defaults y ocultar complejidad. Slack eligió simplicidad, Jira eligió flexibilidad. Ninguno está mal, son apuestas diferentes para audiencias diferentes.

Velocidad vs completitud: ¿lanzás rápido con un MVP que resuelve el 80% del caso de uso o esperás hasta tener todas las features? Spotify lanza rápido e itera, Adobe históricamente lanzaba productos completos. De nuevo, diferentes estrategias para diferentes contextos.

Innovación vs convención: un patrón de UI nuevo puede diferenciarte o puede confundir. Instagram cambió el ícono de likes de estrella a corazón porque generaba más engagement. TikTok inventó una UI completamente nueva. Ambos casos fueron apuestas calculadas, no caprichos.

Cómo documentar decisiones

Las decisiones de diseño se olvidan. Tres meses después de lanzar una feature, nadie se acuerda por qué se hizo de determinada forma. Documentar el proceso y las razones te salva de discusiones circulares.

Un formato simple:

## Decisión: Modal vs página completa para checkout

**Contexto**: Los usuarios abandonan en el paso 2 del checkout (38% bounce rate)

**Opciones consideradas**:
- Modal overlay
- Página completa nueva
- Sidebar deslizable

**Decisión**: Modal overlay

**Razones**:
- Mantiene contexto visual del carrito
- Reduce clicks (no hay navegación back)
- Testing A/B interno mostró 12% más conversión

**Tradeoffs aceptados**:
- Menos espacio en mobile (mitigado con versión adaptativa)
- Complejidad técnica en manejo de estados

Este tipo de documentación te permite defender decisiones frente a stakeholders y también revisarlas cuando cambien las condiciones.

Colaboración con desarrollo

El diseño que no se implementa no existe. La relación entre diseñadores y developers define si un producto sale bien o sale a medias. Demasiados diseñadores tratan a los devs como "implementadores" que tienen que traducir una visión perfecta. Demasiados devs tratan al diseño como decoración que se agrega al final.

Conversaciones tempranas

Involucrar a desarrollo antes de tener todo definido es la movida. No después de haber hecho un prototipo con 47 interacciones complejas que son imposibles de implementar. Antes.

Una conversación útil:

"Estoy pensando en un sistema de filtros avanzados. Desde tu lado técnico, qué restricciones tenemos con la API actual? Qué sería fácil y qué sería complejo?"

Esto no es pedirle permiso al dev para diseñar. Es diseñar con información completa. Tal vez la solución más elegante desde UX sea una pesadilla de performance. Tal vez exista una alternativa que sea 80% tan buena y tome 20% del tiempo de desarrollo.

Hablar el mismo idioma

Entender conceptos básicos de frontend ayuda. No necesitás programar, pero saber qué es un componente, qué es estado, qué significa responsive te permite diseñar de forma realista.

Algunos conceptos que todo product designer debería manejar:

• Componentes: piezas reutilizables de UI (botones, inputs, cards)
• Estados: cómo se ve algo en diferentes situaciones (default, hover, active, disabled, loading, error)
• Breakpoints: anchos de pantalla donde el diseño cambia (mobile, tablet, desktop)
• Jerarquía de información: qué es importante visualmente y por qué

Esto no es responsabilidad del diseñador, es capacidad. Te hace mejor en tu trabajo.

Diseño orientado a negocio

El diseño existe para resolver problemas de negocio. Si eso suena mercenario, bueno, es la realidad. Un producto que es hermoso pero que no cumple objetivos de negocio no se sostiene.

Esto no significa sacrificar al usuario en el altar de las métricas. Significa entender que el diseño es una herramienta estratégica.

Métricas que importan

Diferentes productos tienen diferentes métricas clave. Saber cuál es la tuya cambia cómo diseñás:

• Conversión: e-commerce, SaaS, cualquier cosa que venda. Cada elemento de la UI debe facilitar la decisión de compra.
• Engagement: redes sociales, plataformas de contenido. El diseño busca tiempo en plataforma, interacciones, retención.
• Eficiencia: herramientas internas, software empresarial. El diseño debe reducir tiempo de tarea y errores.

Un diseñador que propone un rediseño completo del dashboard sin entender qué métrica está tratando de mover es un decorador, no un product designer.

Balancear corto y largo plazo

A veces la decisión que mejora una métrica hoy daña la marca a largo plazo. Dark patterns, notificaciones invasivas, fricción artificial en cancelaciones. Todo eso puede mejorar números trimestrales y destruir confianza.

El trabajo del product designer es señalar estos tradeoffs. No siempre vas a ganar esas discusiones, pero tu responsabilidad es plantearlas.

Sistema de diseño y escalabilidad

Cuando un producto crece, diseñar pantalla por pantalla deja de escalar. Ahí entra el sistema de diseño: un conjunto de componentes, patrones y reglas que permite crear interfaces consistentes de forma rápida.

Un sistema de diseño no es una biblioteca de Figma con botones bonitos. Es un lenguaje compartido entre diseño y desarrollo que acelera el trabajo de ambos.

Componentes base

Button
  - variants: primary, secondary, ghost
  - sizes: sm, md, lg
  - states: default, hover, active, disabled, loading

Input
  - types: text, email, password, number
  - states: empty, filled, error, disabled
  - helpers: label, hint, error message

Card
  - layouts: vertical, horizontal
  - elementos: image, title, description, actions

Cada componente tiene comportamiento definido, lo que reduce decisiones arbitrarias y acelera implementación.

Qué se espera de un product designer hoy

El mercado cambió. Ya no alcanza con saber usar Figma y tener buen gusto visual. Se espera que un product designer:

• Entienda el negocio y pueda hablar de impacto, no solo de experiencia
• Colabore con producto, desarrollo y marketing como par
• Conduzca research y base decisiones en datos
• Documente y comunique el razonamiento detrás de las decisiones
• Itere rápido y acepte feedback sin ponerse defensivo
• Conozca limitaciones técnicas y diseñe dentro de lo posible

El product design es una disciplina de resolución de problemas, no de autoexpresión artística. Los mejores diseñadores son los que pueden mostrar cómo una decisión de diseño movió una métrica, mejoró una experiencia y se implementó en tiempo.

Si te interesa el product design, empezá por resolver problemas reales de productos reales. El portfolio con conceptos de apps que no existen ya no impresiona. Lo que impresiona es mostrar proceso, decisiones, impacto y aprendizajes.

Diseñar productos es difícil, pero es de los trabajos más completos que hay: combina creatividad, estrategia, empatía y ejecución. Hacelo bien y vas a tener impacto tangible en cómo millones de personas usan tecnología todos los días.