Cómo tomar decisiones de diseño según el contexto
En un equipo de producto podemos decidir si cambiar el color de una acción, reorganizar un flujo, modificar una regla de negocio o replantear qué problema debería resolver el producto. Todas son decisiones de diseño, pero no tienen el mismo alcance, las mismas consecuencias ni necesitan el mismo proceso.
Tomar una decisión de diseño no consiste en aplicar siempre el mismo framework. Algunas decisiones son pequeñas y reversibles; otras afectan flujos, reglas o la dirección del producto. Antes de elegir cómo decidir, conviene entender su alcance, qué ocurre si nos equivocamos, qué incertidumbre necesitamos reducir, qué evidencia puede ayudarnos y quién debe participar.
Este artículo propone recorrer esas preguntas a partir de una decisión concreta.
No necesitas elegir algo especialmente importante. Puede ser una decisión que estés evaluando ahora, una que hayas tomado recientemente o incluso un ejemplo hipotético.
Empecemos por una decisión concreta
Antes de hablar de modelos o frameworks, piensa en alguna decisión de producto o diseño que tengas cerca.
Puede ser algo tan cotidiano como:
- cambiar una parte de una interfaz;
- elegir entre alternativas de solución;
- modificar un flujo o una regla;
- decidir qué investigar o medir;
- tomar una decisión más estructural sobre la experiencia.
No hace falta un brief. Una frase corta alcanza. Este texto permanece solo en tu navegador.
Si no tienes ninguna situación en mente, puedes utilizar este ejemplo durante el recorrido:
Ejemplo hipotético: un equipo que mantiene una herramienta operacional está evaluando modificar su sistema de búsqueda y filtros porque algunas tareas requieren demasiado tiempo.
Volveremos sobre esa misma decisión a medida que avancemos.
Primero, entiende en qué nivel estás decidiendo
Un cambio de color y un cambio en la dirección de un producto pueden involucrar diseño, pero sería extraño analizarlos de la misma manera.
Peter Merholz y Kristin Skinner, en Org Design for Design Orgs, describen el trabajo de diseño a través de diferentes escalas: Surface, Structure, Strategy y Big Picture. Su modelo no fue creado como una clasificación de decisiones.
En este artículo no utilizo esos niveles para clasificar el trabajo de un equipo, sino como una pregunta inicial para reconocer dónde actúa principalmente una decisión.
En Surface aparecen decisiones sobre la expresión visible del producto: tipografía, color, espaciado, layout, animaciones o detalles de interfaz.
En Structure, las decisiones empiezan a modificar cómo funciona la experiencia: navegación, flujos, arquitectura de información, jerarquías o relaciones entre partes del sistema.
En Strategy, la conversación se mueve hacia la UX Strategy: qué necesidades se priorizan, qué resultados se buscan, qué requerimientos importan o hacia dónde debería evolucionar la experiencia.
Y algunas decisiones llegan a un nivel todavía más amplio, que Merholz y Skinner denominan Big Picture, donde el diseño se conecta con cambios que exceden una pantalla, un flujo o incluso un producto particular.
La clasificación no implica que una escala sea más valiosa que otra. Una decisión de Surface puede resultar crítica para la accesibilidad o la comprensión. Una decisión estratégica puede ser relativamente pequeña o experimental.
La pregunta no es cuál nivel es “mejor”.
La pregunta es:
¿Qué estás modificando principalmente?
Si, por ejemplo, estás modificando cómo funciona el buscador de una herramienta, la decisión parece actuar principalmente en Structure.
Eso todavía no nos dice cuánto deberíamos analizarla. Para eso necesitamos otra dimensión.
Después, pregunta qué tan fácil es volver atrás
Amazon popularizó una distinción útil entre decisiones de one-way door y two-way door.
Una two-way door permite probar una dirección, observar qué sucede y regresar si el resultado no funciona. No significa que revertirla sea gratis, sino que volver atrás sigue siendo razonablemente posible.
Una one-way door, en cambio, implica un compromiso mucho mayor. Revertirla puede resultar difícil, lento, costoso o directamente imposible.
Esta diferencia importa porque un proceso de decisión pesado puede ser tan problemático como uno demasiado liviano.
Si podemos probar una alternativa durante pocos días, observarla y deshacerla sin grandes consecuencias, quizá no necesitemos semanas de deliberación.
Pero si estamos modificando una regla central del producto, migrando información o introduciendo una dependencia difícil de desmontar, avanzar con la misma ligereza sería otra cosa.
Volvamos a nuestra decisión.
Si esta decisión resulta equivocada, ¿qué tan fácil sería volver atrás?
Supongamos que cambiar el sistema de búsqueda requiere trabajo de diseño y desarrollo, pero la implementación anterior podría recuperarse.
No estamos frente a una puerta completamente cerrada.
Pero tampoco es gratis.
Eso empieza a elevar el nivel de compromiso.
Reversibilidad no es lo mismo que impacto
Hay una trampa posible en el modelo de las puertas: asumir que una decisión reversible es automáticamente poco riesgosa.
No necesariamente.
Imaginemos que el nuevo buscador puede desactivarse en unas horas, pero durante ese tiempo dificulta una operación utilizada cientos de veces al día. Técnicamente podemos volver atrás. Eso no significa que las consecuencias de equivocarnos sean pequeñas.
Por eso conviene separar dos preguntas.
La primera ya la hicimos:
¿Podemos revertir la decisión?
La segunda es:
¿Qué podría ocurrir mientras estamos equivocados?
No necesitamos transformar estas respuestas en una puntuación de riesgo.
Lo importante es hacer visible la exposición.
Una decisión puede ser fácil de revertir y, al mismo tiempo, justificar bastante cuidado porque afecta tareas críticas. También puede ocurrir lo contrario: una decisión difícil de revertir cuyo impacto real es relativamente acotado.
El trabajo de Itamar Gilad sobre desarrollo de producto guiado por evidencia conecta una idea similar: cuánto necesitamos validar depende, entre otras cosas, del riesgo y del nivel de compromiso que implica avanzar.
No buscamos certeza absoluta.
Buscamos ajustar el esfuerzo a lo que está en juego.
Antes de buscar evidencia, identifica qué no sabes
Cuando un equipo no está seguro sobre una decisión, una reacción frecuente es pedir “más datos” o “hacer research”.
Pero evidencia no es una categoría única.
Una entrevista, una prueba de usabilidad, analytics y un experimento controlado responden preguntas diferentes. No tiene demasiado sentido discutir cuál es el método “más fuerte” sin haber definido primero qué queremos aprender.
Por eso, antes de elegir el método, conviene formular otra pregunta:
¿Qué es lo que todavía no sabemos?
Tal vez no entendemos qué necesitan las personas.
Tal vez conocemos la necesidad, pero no sabemos cómo realizan actualmente una tarea.
Quizá observamos el problema, pero no sabemos cuál de dos alternativas facilita mejor el trabajo.
O quizá la incógnita es otra: sabemos que una solución funciona, pero queremos conocer su impacto sobre determinado resultado.
Esta pregunta cambia bastante la conversación.
Si queremos comprender una necesidad o una motivación, una conversación contextual u observación puede aportar evidencia relevante.
Si queremos conocer un comportamiento existente, analytics, datos operativos u observación directa pueden ayudarnos.
Si queremos identificar dónde una interfaz dificulta completar una tarea, una prueba de usabilidad puede ser mucho más pertinente.
Y si queremos estimar causalmente qué sucede cuando exponemos a grupos comparables a dos alternativas distintas, un experimento controlado puede ser apropiado cuando el producto y el contexto permiten realizarlo.
Para las decisiones que estamos analizando, ordenar todos los métodos en una única jerarquía puede resultar engañoso. La evidencia útil depende primero de la incertidumbre que necesitamos reducir.
La pregunta correcta viene antes que el método.
Si tu incertidumbre puede resolverse con un experimento controlado
Algunas decisiones permiten comparar alternativas mediante un experimento.
En esos casos, conviene definir antes de observar el resultado:
- qué queremos mejorar;
- qué resultado no queremos deteriorar;
- cómo comprobaremos que los datos son confiables.
La literatura sobre experimentación online distingue precisamente estas preocupaciones: métricas relacionadas con el objetivo, guardrails que ayudan a detectar efectos indeseados y controles sobre la calidad de los datos.
Imaginemos que una variante del buscador permite encontrar información más rápido, pero también aumenta los errores.
Mirar únicamente la primera métrica podría llevarnos a una interpretación incompleta.
Esto no convierte al experimento en el destino natural de toda decisión. Si la incertidumbre principal es comprender por qué una persona no encuentra una función, una prueba de usabilidad puede ser más pertinente.
En otras situaciones quizá no necesitemos investigar más.
Necesitamos decidir.
¿Cuánta evidencia necesitas realmente?
Llegados a este punto aparece el problema inverso.
Si cada incertidumbre conduce a otra investigación, podríamos postergar cualquier decisión indefinidamente.
El objetivo no es eliminar toda incertidumbre. Eso rara vez es posible.
La pregunta útil es:
¿Tenemos suficiente confianza para el nivel de compromiso que estamos por asumir?
Volvamos al ejemplo.
Hasta ahora podríamos tener algo así:
Decisión: cambiar el sistema de búsqueda.
Escala: principalmente Structure.
Reversibilidad: posible, pero costosa.
Consecuencia: errores operativos y pérdida de tiempo.
Incertidumbre: no sabemos qué alternativa permite encontrar información de forma más efectiva.
Con esa combinación, implementar directamente una solución completa basándonos únicamente en una preferencia del equipo implicaría asumir bastante incertidumbre.
Quizá una prueba pequeña con las alternativas principales sea considerablemente más barata que implementar, descubrir el problema y revertir.
En otra situación, el análisis podría producir el resultado contrario.
Si estamos modificando un detalle fácil de revertir, con exposición mínima y suficiente comprensión del problema, seguir investigando puede costar más que avanzar y observar.
Más evidencia no es automáticamente una mejor decisión.
La evidencia tiene valor cuando reduce una incertidumbre que realmente importa para el compromiso que estamos por asumir.
A veces el problema no es qué decidir, sino quién decide
Muchas decisiones se vuelven lentas no porque falte información, sino porque no está claro quién necesita participar.
Diseño propone una alternativa.
Producto tiene otra interpretación.
Desarrollo conoce una restricción importante.
Una persona necesita aprobar.
Otra puede bloquear la implementación.
Y en algún momento resulta difícil distinguir quién aporta información de quién tiene realmente la responsabilidad de cerrar la decisión.
El framework RAPID, desarrollado por Bain & Company, separa cinco roles:
- Recommend: quien propone una dirección.
- Agree: quien debe acordar cuando su aprobación es necesaria.
- Perform: quien ejecutará lo decidido.
- Input: quien aporta conocimiento relevante.
- Decide: quien toma la decisión final.
Su valor no está en asignar cinco roles ceremoniales a cada discusión.
Bain advierte justamente que no todas las decisiones justifican ese esfuerzo.
La herramienta empieza a resultar útil cuando la responsabilidad es ambigua o una decisión atraviesa varias funciones.
Si respondes que no está claro quién decide, quizá el problema que necesitas resolver antes no sea de diseño.
Es de gobernanza de la decisión.
Antes de cerrar, revisa cómo estás mirando el problema
Podemos tener un proceso claro, información relevante y responsabilidades definidas y aun así inclinar la decisión sin darnos cuenta.
John Hammond, Ralph Keeney y Howard Raiffa describieron varias trampas frecuentes en la toma de decisiones, entre ellas el anclaje (anchoring), el costo hundido (sunk cost), la evidencia confirmatoria (confirming evidence), el sesgo hacia el statu quo (status quo) y el exceso de confianza (overconfidence).
No hace falta memorizar sus nombres para empezar a reconocerlas. Si querés profundizar en el tema, también podés leer sobre sesgos cognitivos.
“Fue la primera solución que pensamos y todavía parece la correcta.”
Puede existir anclaje: la primera alternativa establece un punto de referencia que condiciona cómo evaluamos las siguientes.
“Ya invertimos demasiado como para cambiar ahora.”
Puede aparecer el costo hundido: usamos una inversión pasada, que ya no podemos recuperar, como argumento para seguir invirtiendo.
“Estoy buscando información que confirme lo que ya pienso.”
Puede aparecer evidencia confirmatoria: prestamos más atención a aquello que sostiene nuestra posición.
“Si podemos dejar todo como está, mejor.”
Puede aparecer un sesgo hacia el statu quo: mantener la situación actual recibe un trato preferencial simplemente porque ya existe.
“Estoy bastante seguro de que sabemos qué va a pasar.”
Puede haber exceso de confianza: sobreestimamos nuestra capacidad para anticipar resultados.
Reconocer una de estas trampas tampoco resuelve automáticamente la decisión.
Pero puede cambiar la siguiente pregunta.
En vez de:
¿Cómo demostramos que esta solución funciona?
podríamos preguntar:
¿Qué evidencia nos haría cambiar de opinión?
Es una diferencia pequeña en la formulación y bastante importante en la manera de mirar el problema.
Para decisiones difíciles de revertir, imagina que ya fallaron
No todas las decisiones necesitan un ejercicio formal de riesgos.
Pero cuando una decisión es difícil de revertir, tiene consecuencias importantes o todavía contiene mucha incertidumbre, puede ser útil cambiar temporalmente de perspectiva.
Gary Klein propuso el premortem como una forma de anticipar riesgos en proyectos: el equipo supone que el proyecto ya fracasó e intenta explicar por qué.
Aquí podemos adaptar esa misma lógica a una decisión cuyo costo, impacto o dificultad de reversión justifique mirar hacia adelante.
Estamos seis meses en el futuro.
La decisión salió mal.
Ahora intentamos explicar por qué.
En el ejemplo del buscador podríamos descubrir un riesgo que todavía no habíamos considerado:
La nueva búsqueda permite encontrar elementos más rápido en los casos principales, pero elimina filtros utilizados por personas que resuelven situaciones menos frecuentes.
El premortem no demuestra que eso vaya a ocurrir.
Hace visible una posibilidad que podemos decidir investigar, mitigar o aceptar.
Ese es su valor.
Tu mapa de decisión
Después de recorrer estas preguntas, la decisión inicial sigue siendo la misma.
Pero nuestra representación del problema debería contener más información.
A medida que respondas las preguntas del artículo, aquí se irá armando tu mapa de decisión. El ejemplo editorial de abajo sigue disponible sin necesidad de interactuar.
Podría verse así:
Cambiar el buscador del dashboard
Escala
Principalmente Structure.Reversibilidad
Se puede revertir, pero tendría un costo.Consecuencias
Podría generar errores y pérdida de tiempo en tareas frecuentes.Principal incertidumbre
No sabemos qué alternativa permite encontrar información de forma más efectiva.Evidencia a considerar
Observar el comportamiento actual y probar las alternativas principales.Participación
Necesitamos input de otras áreas, pero debe quedar claro quién decide.Posible sesgo a revisar
Sesgo hacia el statu quo.Riesgo a considerar
Resolver los casos principales podría empeorar tareas menos frecuentes.Siguiente pregunta
¿Cuál es la forma más pequeña de reducir la incertidumbre principal antes de comprometernos?
No es una respuesta automática.
Tampoco es una puntuación que determine si la decisión es correcta.
Es un mapa.
Su función es hacer visibles aspectos de la decisión que inicialmente podían estar mezclados: alcance, reversibilidad, consecuencias, incertidumbre, evidencia, responsabilidades y riesgos.
El proceso debería adaptarse a la decisión
Un sistema para tomar decisiones no debería convertir cualquier cambio en un workshop, una investigación y tres reuniones de aprobación.
Ese exceso también tiene un costo.
Una decisión pequeña, reversible y con consecuencias limitadas puede necesitar poco más que criterio suficiente para avanzar y capacidad para observar qué ocurre después.
Cuando la reversibilidad disminuye, la exposición aumenta o aparecen incertidumbres importantes, tiene sentido elevar progresivamente la exigencia: conseguir evidencia pertinente, involucrar a quienes conocen restricciones relevantes, aclarar quién decide y anticipar posibles fallas.
Los frameworks de este artículo no forman una receta ni necesitan aplicarse todos.
Funcionan mejor como preguntas disponibles.
¿En qué nivel estamos decidiendo?
¿Podemos volver atrás?
¿Qué ocurre si nos equivocamos?
¿Qué es lo que todavía no sabemos?
¿Qué evidencia podría reducir esa incertidumbre?
¿Quién necesita participar y quién decide?
¿Hay algo condicionando cómo estamos mirando el problema?
El objetivo no es eliminar la incertidumbre.
Es entender qué sabemos, qué no sabemos y cuánto necesitamos aprender antes de comprometernos.
Una decisión pequeña no necesita convertirse en un proceso pesado. Una decisión difícil de revertir tampoco debería tratarse como un detalle.
Parte del criterio está en saber distinguirlas.
Relacionado
- Relacionado: Pensamiento analítico, crítico y creativo en UX
Fuentes
- Peter Merholz y Kristin Skinner. 12 Qualities of Effective Design Organizations. O’Reilly, 2017.
- Jeff Bezos. 2016 Letter to Shareholders. Amazon.
- Itamar Gilad. How Much Product Discovery Is Enough?. 2022.
- Itamar Gilad. Evidence-Guided: Creating High-Impact Products in the Face of Uncertainty.
- Aleksander Fabijan, Pavel Dmitriev y colaboradores. Top Challenges from the First Practical Online Controlled Experiments Summit. 2019.
- Bain & Company. RAPID Decision Making Framework.
- John S. Hammond, Ralph L. Keeney y Howard Raiffa. The Hidden Traps in Decision Making. Harvard Business Review, 1998.
- Gary Klein. Performing a Project Premortem. Harvard Business Review, 2007.
Si trabajas en productos donde las decisiones atraviesan múltiples roles, reglas, restricciones o sistemas, puedes conectar conmigo en LinkedIn.