Cómo tomar y validar decisiones de diseño de producto
Del problema a una solución que se pueda usar y sostener. Una guía para elegir qué investigar, qué prototipar y con qué evidencia decidir el siguiente paso.
Elegí una decisión concreta para empezar
Diseñar un producto implica dar forma a una solución considerando a las personas que la usarán, el contexto y las condiciones necesarias para producirla y sostenerla. Para que el trabajo avance, formulá una decisión acotada: qué tarea mejorar, para quién, en qué situación y con qué restricciones.
En lugar de “necesitamos un nuevo dashboard”, describí el problema: “el responsable de operaciones tarda demasiado en detectar pedidos demorados”. La pantalla es una hipótesis de solución. También podrían ayudar una alerta, una integración o un cambio de proceso.
Producto, UX, investigación, ingeniería y negocio tienen áreas de trabajo compartidas. UX no se limita a la interacción con una interfaz ni existe una jerarquía universal que subordine todas las disciplinas al diseño de producto. Acordá responsabilidades según el proyecto.
Investigá el trabajo real y sus dificultades
Observá cómo se resuelve hoy la tarea. Combiná conversaciones, observación, soporte y datos de uso cuando estén disponibles. Buscá casos que contradigan la explicación inicial: personas que completan la tarea sin dificultad, quienes abandonan y quienes utilizan soluciones alternativas.
Separá lo observado de la interpretación. “Cinco participantes buscaron el estado del pedido en otra herramienta” es una observación de esa muestra. “Todos necesitan un tablero nuevo” es una conclusión mucho más amplia que requiere evidencia adicional.
Registrá necesidades de accesibilidad, entorno, frecuencia y consecuencias de un error. Una solución que funciona en una demostración tranquila puede fallar con mala conectividad, presión de tiempo o limitaciones de atención.
Priorizá las incertidumbres que podrían invalidar la idea
Las lentes de deseabilidad, factibilidad y viabilidad ayudan a ordenar preguntas, pero no son una secuencia rígida. El marco de cuatro riesgos de SVPG distingue valor, usabilidad, factibilidad y viabilidad de negocio. Es una herramienta para evaluar una solución, no una definición completa de la disciplina.
Valor
¿La solución atiende una necesidad relevante y alguien elegiría usarla o comprarla?
Usabilidad
¿Las personas pueden comprenderla y completar la tarea en su contexto?
Factibilidad
¿Podemos construirla y operarla con los recursos y restricciones disponibles?
Viabilidad
¿Es compatible con costos, modelo de negocio, acuerdos y funcionamiento de la organización?
Elegí primero el riesgo de mayor consecuencia y menor evidencia. Si una integración crítica parece técnicamente inviable, conviene investigarla temprano. Si no está claro que el problema importe, una construcción completa agrega costo antes de resolver esa duda.
Usá la representación más simple que responda la pregunta
Un boceto permite discutir estructura; un prototipo interactivo ayuda a observar tareas; una prueba técnica explora rendimiento o integración. Un piloto manual puede revelar cómo se presta un servicio antes de automatizarlo. La fidelidad necesaria depende de la incertidumbre.
También se pueden prototipar productos físicos y servicios: maquetas, simulaciones, guiones, recorridos o ensayos con el equipo. Un producto digital no es necesariamente tangible y un servicio no está condenado a probarse únicamente después del lanzamiento.
Definí tareas realistas y criterios antes de observar participantes. Evitá explicar la solución mientras medís si se entiende. Registrá dificultades, apoyos necesarios y errores críticos, además de opiniones. Una muestra pequeña puede revelar problemas de uso; no estima automáticamente su frecuencia en todo el mercado.
Combiná utilidad, costos y restricciones
Compará alternativas con evidencia y supuestos explícitos. No ordenes todo por cantidad de pedidos ni por facilidad de desarrollo: considerá alcance, gravedad del problema, esfuerzo, mantenimiento y dependencia de otras decisiones.
Un atributo atractivo en Kano puede diferenciar una oferta o resultar prescindible; la clasificación por sí sola no decide. También hay trabajo necesario de confiabilidad, accesibilidad o mantenimiento cuyo valor no aparece como una nueva función visible.
Ejemplo hipotético: un equipo evalúa alertas frente a un panel de control. El prototipo muestra que las alertas ayudan a detectar demoras, pero demasiadas notificaciones interrumpen el trabajo. La siguiente prueba debe ajustar umbrales y preferencias, no declarar validada toda la solución.
Verificá el resultado después de entregar
Antes de lanzar, registrá cómo reconocerás una mejora: tiempo para completar una tarea, errores, adopción pertinente, carga de soporte o un resultado comercial vinculado. Añadí métricas de resguardo para detectar efectos adversos.
Revisá qué sucede en uso real y con qué segmentos. Que una función se utilice no demuestra que resuelva bien el problema, y que aumente la retención no prueba por sí solo que el cambio de diseño haya sido la causa. Contrastá hipótesis y condiciones del lanzamiento.
Reservá capacidad para corregir, retirar o simplificar. El diseño continúa con lo aprendido; no termina al aprobar las pantallas.
Decisiones habituales
¿Hay que investigar siempre antes de prototipar?
La secuencia depende de lo que ya sabés y del riesgo. Un prototipo también puede servir para investigar, siempre que tenga una pregunta y un alcance claros.
¿Un test de usabilidad valida la demanda?
No. Muestra cómo se usa una solución bajo ciertas condiciones. El interés, la compra y la sostenibilidad requieren otras evidencias.
¿Todos los productos necesitan un dashboard?
No. La interfaz debe responder a tareas concretas. Alertas, automatizaciones u otros formatos pueden resolver mejor una necesidad.
Fuentes para profundizar
SVPG · The Four Big Risks — valor, usabilidad, factibilidad y viabilidad de negocio.
Brown, T. (2009). Change by Design. HarperBusiness. Diseño e innovación centrados en las personas.