¿Qué es? 

En primer lugar, es necesario entender que UX y UI no son lo mismo, pero son dos caras de la misma moneda. 

Para entender qué es la experiencia usuaria (UX) y la interfaz de usuario (UI) de forma simple, veamos una analogía: El guión de una obra especifica los personajes, qué ocurre, cuándo y cómo. Mientras, la puesta en escena consta en los actores, con sus vestuarios, actuando sus papeles en el escenario. En el guión se forma la narrativa, el mensaje y la intención de la obra; mientras la puesta en escena se asegura de comunicarlo de la mejor manera posible. En esta asociación, UX se asemeja a crear el guión, mientras que UI a la puesta en escena. 

El diseño UX se encarga de especificar el “guión”, o las acciones, secuencias y flujos que recorre un usuario para cumplir ciertos objetivos. El diseño UI se encarga de darle un estilo que refuerce y comunique correctamente el “guión”, usualmente desde lo visual, pero también desde la audición (por medio de efectos de sonido). 

Mientras mejor sea la planificación de este “guión”, y su ejecución en interfaces, mejor será la experiencia del usuario. 

Ahora ¿qué significa que la experiencia del usuario sea “buena” o “mala”? 

Hablando de productos digitales (aunque en otros productos y servicios puede ocurrir de forma similar) una “buena” experiencia es aquella que permite al usuario completar sus tareas sin frustraciones. Suena simple, pero ello implica entender qué cosas provocan frustración en los usuarios. Algunos ejemplos son: información poco clara (el usuario no entiende cómo continuar o a dónde ir debido a etiquetas poco específicas, poco visibles o ambiguas), no saber dónde encontrar ayuda si tiene problemas, o que la ayuda ofrecida sea insuficiente; navegación confusa (el usuario no logra encontrar información debido a una diagramación poco intuitiva o desordenada), inconsistencias (cambios en la interfaz sin una lógica detrás producen confusión), entre otras cosas. 

*A menudo también se habla de reducir la fricción, pero esa no es la mejor métrica en todos los casos, ya que hay ciertos flujos e interacciones donde debe existir una medida de fricción para evitar realizar ciertos tipos de acciones de forma accidental (como eliminar información, ingresar información sensible, entre otras). 

Aquí se muestra un ejemplo ilustrativo de mal UX/UI:

Si te apareciera este mensaje ¿Qué harías?

Por qué UX UI es clave para prototipar (y para desarrollar sin botar plata)  

¿Cómo podemos saber qué frustra a los usuarios? Puedes pensar que sabes perfectamente qué necesita el usuario (o qué quieres tú que haga) y saltar de inmediato al desarrollo, para luego encontrarte con que nadie quiere usar tu producto y no sabes por qué. Esta es la razón por la que es importante prototipar y validar la experiencia. Solo mostrando y probando tus prototipos podrás saber si la experiencia es buena o mala antes de desarrollar (sabemos que hacer cambios a un desarrollo ya ejecutado es mucho más caro que hacer cambios en un prototipo).  

*Quizás no consideres importante si el usuario “la pasa bien” o “mal” usando tu producto, pero debes saber que si lo ignoras, tendrá un impacto en tus números, y no uno positivo. 

Hay que recalcar también que, para obtener validaciones reales, debemos probar los prototipos con personas que correspondan a nuestro público objetivo (no es lo mismo diseñar para niños de escuela básica que para adultos mayores). 

Proceso UX UI para prototipar: benchmark + validación (la dupla que manda)  

Benchmark: copiar bien para ganar tiempo  

Siempre es clave que antes de prototipar realices un benchmark de productos parecidos. Si nadie reinventa la rueda, no tienes porqué rediseñar un flujo que existe y funciona. Por supuesto que puedes mejorarlo, pero es mejor partir desde una base que desde nada. En la práctica, miras competidores directos (misma promesa), referentes de experiencia (apps que la gente ya domina) y patrones estándar (onboarding, búsqueda, filtros, checkout, formularios). Con eso en mente para diseñar aquello que ya existe, puedes poner énfasis en diseñar y probar aquellas cosas que son únicas, que se hayan creado para el producto en particular. 

El objetivo no es “parecerse”. Es responder preguntas incómodas: ¿cuántos pasos son realmente necesarios?, ¿qué información piden primero y por qué?, ¿dónde se cae la gente?, ¿qué lenguaje evita dudas? El output no debería ser una galería de pantallas, sino un mapa de flujo (user journey) y wireframes simples que capturan la lógica.  

Prototipo: rápido, barato, testeable  

Un prototipo no es un producto. Es un mecanismo de aprendizaje. Puede ser un wireframe clickeable en Figma, un mockup más detallado para validar comprensión y confianza, o incluso un “fake door” (mostrar una opción y medir interés antes de construirla).  

Parte del truco para hacer más eficientes las validaciones es escoger qué validar y qué no, y son precisamente los flujos más específicos del producto (en general las funciones clave) los que vale más la pena prototipar y validar.  

*Siempre es importante validar la navegación y el lenguaje usado para verificar que los usuarios entiendan cómo usar el producto, pero esto se puede incluir en otras validaciones. 

Prototipa lo riesgoso, no “todo”. 

En general, lo más riesgoso se encuentra en el rango de UX más que de UI, por lo que la mayoría de los testeos (y sus validaciones) serán en el ámbito de la experiencia. Con la etapa UX concluída, se realizará el diseño UI, el cual también puede ser testeado al detalle para asegurar la calidad, la consistencia y claridad gráfica, entre otros factores. 

Validación con usuarios: menos opinión interna, más evidencia real 

¿Cómo se valida la experiencia? En simple, se selecciona una o más tareas que se quieren poner a prueba, se pide a los usuarios de prueba que realicen la tarea en el prototipo y se observa qué hacen y cómo. La validación no se trata de preguntarle a la persona si le gusta o no, se trata de observar lo que hace. Entiéndase que una validación exitosa no es necesariamente aquella en que el usuario logra el objetivo sin problemas, sino aquella donde lograron levantarse la mayor cantidad de posibles problemas por resolver. 

Por la misma razón, hay que evitar guiar al usuario para que cumpla el objetivo, sino que ver si logra cumplir el objetivo o no, y de qué forma (Ojo con las frustraciones). 

*Tarea se refiere a una serie de acciones que debe realizar un usuario para cumplir con un objetivo. Por ejemplo, comprar un par de zapatillas de una determinada marca y color en una tienda de ropa.  

Pero todo esto abre varias preguntas ¿Cuántas veces tenemos que probar el prototipo? ¿Con cuántas personas? ¿Cómo sé si ya está listo el diseño de la experiencia? Los posibles costos de realizar validaciones (ya sea tiempo en buscar participantes, tiempo realizando las pruebas, alguna forma de pago a los voluntarios, entre otros) pueden ser intimidantes, pero lo que dice la teoría es bastante alentador: Aproximadamente el 80% de los problemas de usabilidad pueden ser detectados al testear con solo 5 usuarios. El retorno por testear con más personas es decreciente, llegando a aproximadamente el 100% de los problemas testeando con 15 personas.  

¿Qué recomiendan los expertos? Realizar varios testeos de forma sucesiva, en lugar de realizar solo un gran testeo. Al realizar un primer testeo con 5 personas, encontrarás la mayoría de los problemas, los que puedes rediseñar antes de realizar un segundo testeo con otras 5 personas (de esta forma, no perderás tiempo detectando los mismos problemas que aparecieron en el primero), donde se encontrará otro 15% de los posibles problemas originales y dará luz a características más profundas del diseño.  Finalmente, en un tercer testeo se encontrarán la mayoría de los problemas restantes. 

*Nótese que esto varía si se trata de un sistema para grupos de usuarios muy distintos (como padres e hijos) 

En resumen: Seleccionas a tus usuarios de prueba, defines tareas concretas (“cotiza X”, “encuentra Y”, “cambia Z”), observas tiempo, errores y puntos de bloqueo (“no entiendo”) en el intento, y cierras con decisiones (qué se cambia y cómo). Luego testeas de nuevo.  

Impacto real en negocio: dónde pega UX UI  

UX UI bien hecho impacta donde duele: conversión, costos y velocidad. Menos fricción aumenta la probabilidad de que el usuario termine la acción. Mejor claridad reduce soporte y retrabajo. Y un diseño consistente habilita escalamiento (componentes y principios de diseño sistematizados en un design System) 

Para innovación (en forma de un producto digital), UX UI es el puente entre “piloto” y “escala”. Ejemplo típico: un piloto interno se ve impecable en demo, pero cuando lo usa el área operativa aparecen errores, pasos innecesarios y resistencia. Con UX UI + validación temprana, ese piloto se vuelve una decisión Go/No-Go basada en evidencia, no en entusiasmo.  

Usa UX UI cuando tu solución es nueva, o cuando rediseñas lo que funcionaba antes, el riesgo es alto o el costo de equivocarte es caro (o sea: casi siempre). No es lujo. Es método. Y en organizaciones serias, el método existe para una sola cosa: decidir mejor y más rápido.