Resolviste el problema equivocado

En pocas palabras: El encuadre del problema y su definición deciden qué percibes, qué ignoras y qué tipo de solución llegas a considerar posible. Si aceptas demasiado rápido el marco del encargo, puedes acabar resolviendo muy bien el problema equivocado.

El encargo llega a tu mesa. Alguien ya ha nombrado el problema. Lo lees, asientes, abres tu herramienta y empiezas a diseñar. El error suele ocurrir antes de que exista un esquema de pantalla o un borrador de texto. Ocurre en esos segundos en los que aceptas la definición de otra persona sin comprobarla.

A los diseñadores se les entrena para resolver. La formación, los portafolios y las entrevistas de trabajo suelen premiar las respuestas más que la reformulación. Se presta mucha menos atención a si la respuesta encaja con el problema real. Así que te vuelves bueno resolviendo y, sin darte cuenta, dejas de preguntar qué estás intentando resolver.

El encuadre moldea la respuesta

En 1983, Donald Schön escribió algo que debería haber cambiado la enseñanza del diseño, pero en gran medida no lo hizo. Distinguió entre resolver problemas y lo que llamó definir el problema. Definirlo consiste en decidir, para empezar, qué cosas tratar como problemáticas: nombrar la situación, encuadrarla y decidir qué cuenta como hecho relevante.

La forma de encuadrar un problema moldea lo que acabas diseñando. Plantea «los usuarios no encuentran el botón de compra» y mirarás el botón. Plantea «los usuarios no confían lo suficiente en esta tienda para completar una compra» y mirarás un conjunto completamente distinto de cosas. El comportamiento es el mismo, pero el trabajo cambia. El marco empieza a estrechar la respuesta antes de dibujar una sola línea.

Kees Dorst, que pasó años estudiando cómo piensan realmente los diseñadores expertos, encontró que el encuadre ocupa un lugar central. Los diseñadores experimentados no corren hacia las respuestas. Permanecen más tiempo con el problema. Se resisten al primer marco que reciben. Prueban otras formas de mirarlo antes de comprometerse con un camino.

Algunos problemas cambian mientras trabajas en ellos

Horst Rittel y Melvin Webber dieron nombre en 1973 a una categoría de problemas con la que la mayoría de los diseñadores trabaja a diario sin tener una palabra para ella. A diferencia de los problemas acotados, con un punto final claro y soluciones correctas, estos cambian cuando los tocas. Resolver un aspecto cambia las condiciones de todos los demás.

Los problemas sociales nunca se resuelven. En el mejor de los casos, solo se vuelven a resolver, una y otra vez.

— Rittel & Webber · Traducción del inglés

Muchos problemas de diseño funcionan así. Diseñas el proceso de bienvenida para reducir el abandono. Reducirlo significa que más usuarios llegan a la parte principal del producto, lo que aumenta la presión sobre soporte. Resolver la pérdida de usuarios revela un problema de retención que no habías visto. El sistema se mueve cuando lo empujas.

Rittel y Webber no decían que estos problemas fueran imposibles. Decían que castigan a quien busca una respuesta limpia y única. El sistema sigue moviéndose bajo tus pies.

Esto importa a los diseñadores porque el encuadre estrecho es lo habitual. Recibes un encargo, aceptas su marco y avanzas. Dice «simplifica la página de ajustes» y la simplificas. Pero quizá el problema real sea que los usuarios llegan a ajustes porque no encuentran lo que necesitan en el flujo principal. O quizá soporte pidió un panel de filtros más agradable cuando el problema real era que los resultados de búsqueda eran basura. La página de ajustes era un síntoma, no la causa. Solo hiciste más fácil convivir con el síntoma.

Segway resolvió lo equivocado

El equipo de Dean Kamen construyó Segway. El sistema de autoequilibrio fue una auténtica hazaña de ingeniería. Tenían una definición clara del problema: la movilidad personal urbana es ineficiente y podemos construir algo mejor que caminar para distancias cortas entre edificios.

El dispositivo funcionaba como se había diseñado. Movía personas, se equilibraba solo y apenas requería aprendizaje. Kamen predijo que las ciudades se rediseñarían a su alrededor. Solo se vendieron 140.000 unidades durante toda la vida del producto. La producción terminó en 2020.

El equipo planteó el problema como una cuestión del dispositivo: construir una forma mejor de moverse entre edificios. Pero el problema real era mayor que el dispositivo.

Las ciudades tenían aceras que no estaban diseñadas para vehículos. La normativa prohibía los Segways en carriles bici y calzadas en la mayoría de los lugares. El precio de 5.000 dólares lo dejaba fuera del alcance de muchas personas que podrían haberlo usado para desplazarse al trabajo. El encaje social también era dudoso.

Nada de eso aparecía en el marco original. El marco preguntaba: ¿podemos construir un vehículo mejor para distancias cortas? No preguntaba: ¿lo admitirán las ciudades, los reguladores, los empleadores y las normas sociales? El equipo construyó la máquina y leyó mal el entorno donde tenía que vivir.

Quédate más tiempo con el problema

Algo que suele separar a los diseñadores menos experimentados de los más sólidos es cuánto tiempo permanecen con el problema antes de empezar a crear cosas.

Un diseñador menos experimentado tiende más a escuchar el encargo, pensar que suena suficientemente claro y ponerse a trabajar. Uno más sólido frena primero. Pregunta qué está resolviendo realmente, por qué importa y si es el problema correcto. A otros puede parecerles una demora. Suele ser la parte que más importa. He visto a equipos ahorrar semanas por hacer la pregunta sencilla a tiempo. También los he visto saltarse esa pausa y pasar un mes puliendo lo equivocado.

Mucho trabajo malo empieza con un encargo que suena razonable pero apunta a lo equivocado, o solo a una parte. Cuando el equipo empieza a diseñar, resulta más difícil cuestionar ese punto de partida. Por eso los diseñadores más sólidos dedican más tiempo al problema antes de dedicarlo a la solución.

Hacen preguntas sencillas que es fácil saltarse. ¿Por qué hacemos esto? ¿Por qué ahora? ¿Qué está fallando realmente? ¿Arreglamos el problema real o solo construimos la solución sugerida por alguien? No son preguntas glamorosas, pero evitan mucho trabajo inútil.

Un diseño sólido dirigido al problema equivocado también fracasa.