En todos los equipos en los que he trabajado hemos construido, en algún momento, algo correcto que no funcionó. La lógica era sólida, la función era real, la ingeniería era buena, y la gente igual no llegaba al final. Cuando eso pasa, el instinto es agregar: otro tooltip, otro paso de onboarding, otra explicación. Casi siempre es la dirección equivocada, porque el problema nunca fue falta de información.
Mi tesis en una línea: la gente no vive un sistema, vive una secuencia, y casi todo lo que llamamos calidad de producto es el trabajo de decidir qué va primero, qué puede esperar, qué debe quedarse fuera del camino y dónde debe decidir una persona en lugar del software.
Atención no es lo mismo que valor.
En La última transmisión, una nave acumula muestras y tú decides cuándo asegurarlas. El número creciente hace visible lo que podrías obtener; la incertidumbre hace que parar sea una decisión. Esa secuencia es el producto que experimentas.
El experimento no demuestra que alguien sienta ansiedad ni mide dopamina. Ilustra una decisión de diseño: podemos orientar la atención hacia seguir, o dar claridad para decidir cuándo basta. Mi criterio sería comprobar si la persona entendió las consecuencias y pudo cumplir su objetivo, no premiar únicamente más segundos o más toques.
Cinco cosas que creo
1Cada petición tiene un precio, y casi nunca lo miramos.
Un teléfono cuesta confianza. Un permiso cuesta seguridad. Un formulario de catorce campos cuesta la creencia de que esto va a ser rápido. Los tratamos como gratis porque a nosotros no nos cuesta nada agregarlos, y la persona que paga ese costo no está en la sala cuando los agregamos.
La disciplina útil es ponerle precio a cada petición y preguntarse si lo que recibimos ahora mismo lo vale. La mitad de las veces la respuesta es que pedimos un campo porque hace años un sistema aguas abajo lo quiso, y nadie lo ha revisado desde entonces. El trabajo de conversión más barato disponible para casi cualquier equipo es borrar.
2El problema que parece caro rara vez es el que te cuesta gente.
Los equipos van por la palanca visible, el rediseño, la marca nueva, el flujo reconstruido, porque es legible hacia arriba y satisfactoria de hacer. Lo que de verdad está perdiendo personas suele ser una frase que no se explica sola, un botón etiquetado con un sustantivo interno, o una pregunta hecha dos pantallas antes de tiempo.
Es poco glamoroso y ahí está el retorno. Prefiero publicar cinco correcciones aburridas que eliminan cada una un motivo para irse, antes que un rediseño ambicioso que mueve los motivos a otro lado.
3La claridad es una decisión de secuencia antes que de redacción.
Un buen texto no rescata un mal orden. Si le pides a alguien que verifique su identidad antes de que entienda a qué se está apuntando, ninguna cantidad de microcopy cálido vuelve razonable esa petición: pediste un depósito de confianza contra un saldo de cero.
Por eso empiezo con tres preguntas, en este orden. ¿Qué tiene que estar claro ahora? La decisión inmediata, con su motivo y su consecuencia en lenguaje llano. ¿Qué puede esperar? Importante no es lo mismo que urgente, y preguntar después suele ser más amable y más efectivo. ¿Qué debe seguir siendo humano? No toda rama merece automatizarse.
4La confianza se gana por etapas, también la del software.
A un compañero nuevo no le damos autoridad amplia el primer día. Lo dejamos observar, practicar en un lugar seguro, tomar decisiones chicas y crecer hacia las grandes. Y luego le pedimos al usuario exactamente lo contrario frente a un sistema automático: confía en el resultado, entrega la acción, ojalá salga bien.
La pregunta mejor no es “¿puede hacerlo este sistema?” sino “¿cuál es la responsabilidad más pequeña que puede ganarse ahora?”. Un sistema que hace visibles sus propios límites es más creíble, no menos, y el camino de vuelta a una persona es parte del diseño, no una confesión de fracaso.
5Una medición que no puede fallar no es una medición.
Esta la aprendí cara, operando sistemas automáticos que reportaron éxito durante semanas sin producir nada: trabajos escribiendo archivos vacíos, una compuerta que ninguna salida podía aprobar, un monitor anotando un cero seguro de sí mismo donde la respuesta honesta era “no hay dato”. Todas las verificaciones pasaban. Todas medían si el proceso corrió, no si algo pasó.
Entonces: nombra el resultado antes de construir el control, e intenta romper el control a propósito antes de creerle a uno que pasa. Lo mismo vale para un lanzamiento. Publicado no es funcionando. Desplegado no es funcionando. Una persona real obteniendo un resultado real del otro lado sí es funcionando, y nada por debajo de eso cuenta, por muy verde que esté la tubería.
Lo que esto descarta
Una tesis sólo sirve si vuelve poco atractivo cierto trabajo. La mía descarta las interfaces recargadas que esconden la decisión, la inteligencia que actúa una certeza que no se ganó, el crecimiento que depende de que alguien malentienda lo que aceptó, y las métricas elegidas porque son fáciles de mover.
También descarta cierta clase de ambición. Prefiero construir un camino honesto que funcione antes que cinco caminos ingeniosos que dejen a la gente sintiéndose atrasada.
