#

Si has estado en suficientes revisiones de diseño, conoces la escena. Alguien muestra una propuesta, y la conversación se va a los colores, a "a mí no me convence" o a lo que dijo el que tiene más cargo en la sala. Al final se aprueba o se rechaza, pero nadie podría explicar con qué criterio.

En las reuniones de aprobación con stakeholders que no son de diseño pasa algo parecido, pero al revés. Producto, negocio, riesgos o legal miran la propuesta y no saben muy bien qué decir. Algunos opinan sobre lo único en lo que se sienten seguros, como el color de un botón o el tamaño del logo. Otros se quedan callados y aprueban por compromiso. En los dos casos perdemos su mirada justo donde más aporta: si el proceso tiene sentido para el cliente y para el negocio.

Casi todos los equipos tienen principios de diseño. El problema es dónde viven: en una diapositiva del kickoff, con palabras como "intuitivo", "centrado en el usuario" o "delightful". Suenan bien, pero nadie los usa para decidir nada, porque no hay forma de usarlos.

Yo quería lo contrario: pocos principios, escritos para usarse en la revisión, no para colgarse en la pared.

#Principios con los que se puede decidir

Me tomó varios intentos llegar a un formato que funcionara. Lo que terminé haciendo fue escribir cada principio como si tuviera que defenderlo en una reunión.

Primero, una frase corta, que puedes repetir sin mirarla. Después, qué significa en nuestro contexto, porque un principio que vale igual para una app de delivery que para un crédito hipotecario no necesariamente le sirve a ninguno de los dos. Luego, ejemplos de cuándo se cumple y cuándo no, sacados de procesos que el equipo conoce. Y al final, una pregunta.

La pregunta es lo que hace que todo funcione. Si un principio no se puede convertir en algo que preguntarle a una propuesta, no hay forma de usarlo en una revisión.

También me obligué a que fueran pocos. Con más de cuatro o cinco, nadie se los acuerda; con cuatro, se pueden recorrer en una reunión sin abrir el documento.

#Cómo llegué a estos cuatro

Los principios no se inventan en una pizarra en blanco. Salen de los problemas que ya tienes, solo que todavía no les has puesto nombre.

Cuando asumí el liderazgo del equipo de UX en un banco, me di cuenta de que muchas decisiones de diseño las tomábamos de forma empírica: con nuestro criterio experto y, sobre todo, con principios de diseño estándar. El equipo era muy capaz, pero cada diseñador aplicaba su propio criterio, y eso se notaba en experiencias fragmentadas. Nos faltaba algo que nos unificara.

Mi primer intento fue escribir lineamientos de diseño, con reglas concretas sobre cómo resolver cada cosa. Rápidamente descubrí que no era eso lo que necesitábamos. Los lineamientos dicen cómo diseñar una pantalla, pero nunca alcanzan para todos los casos: cuando aparece uno nuevo, cada diseñador vuelve a su propio criterio, y la fragmentación regresa.

Lo que hacía falta era algo más amplio: no reglas sobre cómo diseñar, sino acuerdos sobre qué tiene que lograr cualquier diseño. Piénsalo como las líneas de una cancha de fútbol. No te dicen cómo jugar ni qué jugada armar, pero todos saben dónde están los límites y hacia qué arco van. Dentro de esas líneas, cada diseñador tiene libertad para resolver a su manera, y aun así el resultado se siente como de un solo equipo.

El proceso que seguí fue más o menos este:

1. Juntar los problemas que se repiten. Hallazgos de investigación, quejas de clientes, comentarios de revisiones pasadas, puntos de dolor de los journey maps. Todo lo que aparezca más de una vez.
2. Agruparlos por causa, no por síntoma. "Me pidieron el mismo documento dos veces" y "tuve que volver a llenar mis datos" parecen problemas distintos, pero vienen de lo mismo: el proceso no aprovecha lo que ya sabe del cliente. De ahí salió Rápido y sin fricciones.
3. Nombrar cada grupo y escribirle su pregunta. Si no logras escribir la pregunta, el grupo todavía es demasiado vago.
4. Probarlos en revisiones reales antes de darlos por buenos. Los que nadie usaba en la práctica, se fueron.
5. Recortar. Lo que quede después de eso, idealmente cuatro o cinco, son tus pilares.

Lo más valioso de este proceso es que los pilares terminan sonando a tu equipo. Cuando alguien dice "esto va contra Transparente y justo", todos recuerdan el caso del que salió.

#Mis cuatro pilares

#1. Simple y directo

Solo lo necesario, en el momento justo.

En banca, la regulación obliga a mostrar mucha información. No se puede esconder, pero sí se puede decidir qué va al frente y qué va al fondo. Ese es buena parte del trabajo de diseño.

Funciona cuando el cliente sabe qué documentos necesita antes de empezar una solicitud, o cuando un gestor completa una tarea en una sola pantalla sin saltar entre sistemas. Falla con formularios llenos de campos que "podrían ser útiles algún día", o cuando el usuario termina y no sabe si completó el proceso o si algo quedó pendiente.

Esto vale también para los documentos: contratos, hojas resumen, términos y condiciones. Es fácil asumir que la regulación exige un nivel de detalle enorme, y que por eso los documentos terminan siendo largos. Muchas veces no es así. Gran parte del largo lo ponemos nosotros: lenguaje legal donde no hace falta, cláusulas que se copian de un documento a otro sin que nadie las revise. Cuando uno vuelve a leer la norma con calma, suele pedir menos de lo que creíamos. Ordenar por lo que el cliente necesita saber primero y escribir en lenguaje simple cumple igual, y se lee mucho mejor.

La pregunta: ¿qué pasa si quitamos esto? ¿El usuario igual puede completar su objetivo?

#2. Rápido y sin fricciones

Cada paso que sobra es un paso que duele.

Un paso que no agrega valor real está de más. Esto es todavía más crítico en banca empresa y en procesos internos, donde el tiempo es literalmente dinero.

Funciona cuando un crédito por convenio no le pide al cliente datos que el banco ya tiene, o cuando una aprobación interna avanza sin esperas manuales. Falla cuando el proceso pide la misma información en distintos momentos, o cuando hay validaciones que no agregan seguridad real, solo fricción.

La pregunta: ¿cuántos pasos tiene esto hoy? ¿Cuántos debería tener?

#3. Transparente y justo

Sin sorpresas, sin letra pequeña.

El usuario siempre debería saber en qué estado está, qué sigue, cuánto cuesta y por qué. La transparencia no es solo una cuestión ética: también es una ventaja competitiva.

Funciona cuando el cliente sabe en qué etapa está su solicitud y cuándo va a tener respuesta, o cuando los costos y condiciones se explican antes de firmar. Falla cuando una solicitud se envía sin confirmación ni siguiente paso claro, o cuando una comisión aparece recién al final.

La pregunta: ¿el usuario sabe exactamente dónde está, qué sigue y qué se espera de él?

#4. Continuo y coherente

Un solo proceso, aunque pase por diez touchpoints.

Para el cliente es un solo trámite, aunque por dentro pase por la app, una agencia, un gestor y tres áreas distintas. La experiencia no debería romperse entre lo digital, lo presencial y lo humano.

Funciona cuando lo que ve el gestor coincide con lo que ve el cliente en la app, o cuando un proceso que empezó en agencia se puede continuar en digital sin empezar de cero. Falla cuando el cliente recibe información distinta por correo, por la app y en la agencia, o cuando cada canal se diseña por separado.

La pregunta: ¿qué pasa antes y después de este momento? ¿La experiencia tiene sentido como un todo?

#Cómo los uso en una revisión

Antes de aprobar o rechazar una propuesta, pasamos por las cuatro preguntas. Nada más.

La regla que más me costó definir, y la que más me funciona, es esta: una solución no tiene que pasar los cuatro pilares perfectamente, pero sí tiene que tener una respuesta consciente para cada uno. Si no la tiene, vuelve al tablero.

Esto cambia la conversación. Ya no discutimos si algo "se ve bien". Discutimos, por ejemplo, si vale la pena sumar un paso de validación (que va contra Rápido y sin fricciones) porque el riesgo lo justifica. Esa tensión entre pilares es sana, siempre que se decida a propósito y no por accidente.

Algo que no esperaba: las preguntas también les dan a los stakeholders que no son de diseño una forma de participar. No necesitan saber de tipografía para preguntar "¿el cliente sabe qué sigue después de este paso?". Y esa pregunta, viniendo de alguien de riesgos o de operaciones, suele ser más valiosa que cualquier comentario sobre colores.

Para que los pilares no se queden en un documento estático, llevo un registro de decisiones: cada vez que un pilar inclina una decisión, o cuando decidimos ir en contra de uno, lo anoto.

Con el tiempo, ese registro se vuelve más útil que los propios pilares: muestra cómo se aplican de verdad, con casos que el equipo reconoce.

Y los pilares no son eternos. Los revisamos una vez al año, o antes si cambia el alcance de lo que diseñamos.

#Dónde se cruzan con el EXP Index

Los pilares dicen cómo debería ser una buena experiencia. El EXP Index dice si lo logramos. No es un mapeo exacto, pero cada pilar tiene una o dos señales donde se nota primero cuando falla:

Esto me sirve en las dos direcciones. Si el EXP Index de un flujo cae, sé qué pilar revisar primero. Y si en una revisión aceptamos ir en contra de un pilar, sé qué métrica vigilar después del lanzamiento.

#Lo que no resuelven

Los pilares no reemplazan la investigación. Una propuesta puede responder bien las cuatro preguntas y aun así fallar con usuarios reales, porque las respuestas las damos nosotros, desde adentro.

Tampoco eliminan el juicio. Cuando dos pilares chocan, alguien tiene que decidir, y los pilares no dicen quién gana. Lo que sí hacen es obligarnos a decirlo en voz alta.

Y no son universales. Estos cuatro salen de procesos financieros complejos, con regulación, varios canales y mucha espera. Otro contexto probablemente necesita otros.

#Si quieres armar los tuyos

Haz el recorrido que conté más arriba con los problemas de tu propio equipo, y escribe cada principio con sus cuatro partes: la frase, qué significa en tu contexto, cuándo funciona y cuándo falla, y la pregunta. Si no puedes escribir la pregunta, todavía no es un principio.