Muchas veces nos pasa que “no hay tiempo para diseño” o que nos piden “que le demos una mirada rápida a una pantalla”, incluso puede pasarte que seas dev y te pidan que des feedback del diseño o que sepas que algo se ve mal, pero no sepas por dónde empezar. Acá te dejo mi guía básica de cosas a mejorar cuando tengo poco tiempo y necesito hacer mejoras de UX con mucho impacto, aplicado a un caso real.

Accesibilidad en los colores

Pero Patricia, ¿cómo voy a controlar la accesibilidad de los colores si de eso no sé nada? Por suerte, acá no hace falta saberlo todo, hace falta saber qué mirar y cómo asegurarnos que pasamos los estándares (podemos elegir si quedarnos con los mínimos o con los ideales).

Acá podemos estar en 2 situaciones: tenemos ya el código o tenemos un archivo de Figma. Si lo que tenemos es el código, la cosa es muy fácil porque navegadores como Google directamente nos permite ver si los elementos son accesibles al inspeccionar el código.

Acá vemos cómo usamos las dev tools de Chrome para chequear contraste. Vemos que en ambos ejemplos los colores pasan las pruebas de contraste.

Si tenemos el archivo de Figma, tenemos 2 opciones:

1. Instalar un plugin como Stark, que hace que todo sea mágico y maravilloso. Es tan fácil como ejecutarlo, y comprobar si la relación color texto:color fondo pasa los niveles. Acá podemos observar que pasa casi todos los escenarios posibles, pero recomiendan que haya un poco más de contraste así es legible incluso en textos más pequeños.

1. Usar alguna web (como Adobe Colors) donde podamos copiar del Figma los colores de texto y fondo y comprobar lo mismo. En este caso, vemos que pasa el estándar AA (el mínimo), pero para el estándar AAA (el ideal) no pasa para los textos más pequeños (igual que en la prueba con el plugin de Figma).

La ventaja de usar herramientas más específicas como Stark o Adobe es que nos dan el resultado de la prueba de contraste que, si no sabemos qué mirar nos da algo más de feedback y ejemplos aplicados. Ejemplo: Adobe nos hace una muestra de distintas aplicaciones y nos indica cuál es la que falla, mientras que en las dev tools dice solamente si pasa o no y el resultado de las pruebas de contraste, que si no sabemos si es un número que corresponde a AA o AAA nos deja un poco sin saber qué hacer.

2. Contenido

Este es nuestro punto de partida: una pantalla que es parte de un flujo en pasos con un título principal, una bajada, más descripción, un botón para realizar una acción (la principal?), otro texto más abajo sin título, preguntas frecuentes más abajo, testimonios a la derecha y un título de lo que parece ser una checklist a la izquierda.

Entonces, antes de ponernos a ver si está lindo o no es necesario preguntarnos ¿cuál es el objetivo principal de esta pantalla? ¿qué información necesito para tomar decisiones? ¿sobra o falta información? Después de analizarlo podemos ver que:

1. El objetivo es que la persona usuaria pague.
2. Para eso antes debe entender qué incluye el pago.
3. Además, como mencionamos ya, es un proceso en pasos, pero este paso bloquea los pasos siguientes.

Cuando analizamos en detalle cada bloque de información nos damos cuenta que:

• los testimonios acá son innecesarios (podemos suponer que si la persona ya llegó a la instancia de pago, los testimonios no la van a hacer cambiar de parecer),
• hay información repetida sobre lo que incluye y excluye el pago que ocupa demasiado espacio (lo que está antes y después del botón de pago es básicamente lo mismo reformulado y más o menos largo).

Analizar qué información incluimos en la pantalla y qué objetivo cumple es clave para guiar a nuestras personas usuarias a cumplir el objetivo deseado. Así que acá podemos hacer varias cosas:

• preguntarnos qué función cumple cada texto,
• cuestionarnos si es necesario para el paso o es borrable,
• borrar lo innecesario,
• asegurarnos que lo que es necesario esté lo más optimizado posible. En UX Writing se sugiere que los textos deben ser claros, cortos y útiles. Si nuestro texto no cumple con alguna de esas máximas, significa que aún hay lugar para mejora. Si querés aprender más sobre UX writing y buenas prácticas, te dejo este otro artículo que escribí.

La pantalla sin la información redundante nos quedaría algo así:

No vamos a decir que es un cambio radical, peeeero se redujo bastante la cantidad de información a absorber.

3. Arquitectura de la información

Acá lo importante es empezar a cuestionarse cosas para ordenar el contenido que analizamos previamente. Primero lo primero, volvamos a las preguntas: ¿cuál es el objetivo de esta pantalla o este flujo? Si una persona ve esta pantalla rápido, ¿qué entiende? ¿qué es lo primero que lee? ¿qué queremos que haga?

Algo que se suele obviar y es muy importante son los títulos. Tener un título que explique: en qué sección del sistema estoy, en qué paso del formulario me encuentro o que diga cuál es el objetivo del modal que se me abre, es clave para dar contexto a simple vista y orientar a nuestras personas usuarias. Aplica tanto a título como a subtítulos. Lo importante es que cada “bloque” de información que tenemos tenga un propósito y esté ordenado, que tenga una “puerta de entrada” que le permita a la persona elegir en qué de todo concentrarse.

Lo que van a ver a continuación son varias pruebas que además fueron mezclándose con cambios de UI, pero creo que es clave ver como la misma información cambia de lugar y de tamaño.

4. Jerarquías

Es muy difícil separar este ítem del anterior. Ya definimos los títulos, que el contenido sea el mínimo necesario, y ¿qué hago con eso? ¿dónde están mis acciones? ¿tengo muchas? ¿tengo pocas? ¿cuál es la principal? Acá, ya todo se vuelve muy complejo y cada vez más subjetivo, pero lo ideal tiende a ser identificar esa acción principal y usar un botón primario y para las acciones secundarias usar botones secundarios, links o íconos según sea necesario. Lo importante es que a la persona le quede claro cuáles son las posibles acciones. Preguntarnos, más allá del orden, ¿qué cosas queremos o necesitamos destacar? En este caso puntual, destacar el precio era importante, así como también cuánto podían obtener de reembolso o que quede claro que van a pagar, para lo cual se cambiaron un poco los componentes que se muestran (antes el pago era un paso aparte) y los tamaños para llamar la atención.

5. Affordances

Esta puede ser una palabra compleja de entender, pero básicamente la pregunta es ¿todos los elementos se entienden cómo lo que son? ¿Los botones se leen como botones? ¿O podemos mejorar su UI para que un link se vea como un botón y se entienda a simple vista que es algo clickeable?

Algunos problemas puntuales que tenía la pantalla inicial eran:

• el return home era raro, hablaba de volver (que una puede asociarlo con atrás, pero el ícono era una casa), buscaba estar en el lugar de una flecha (pero, de nuevo, el ícono era una casa) como que entre significado y objetivo de la acción había un par de contradicciones.
• Arriba de nuestro título primario había una flecha para atrás… que no llevaba para atrás! Abría un modal para actualizar otra información. Todo se vuelve más confuso.
• Lo que parece un checklist al costado, es un flujo en pasos donde no podemos avanzar si no vamos completando cada paso.

Entonces, ¿qué podemos hacer? En este caso lo resolvimos:

• unificando la flecha de volver al inicio con el título, para que quede claro que si apretamos ahí nos vamos de donde estamos;
• le dimos al listado de pasos un diseño más secuencial y definimos 3 estados posibles: uno para los pasos ya completados, uno para el paso actual (el activo/en proceso y del cual solo puede haber uno) y los deshabilitados para aquellos que aún no pueden completarse;
• movimos el ítem de “update insurance coverage” debajo de lo que incluye el plan para que la persona pueda actualizarlo y entenderlo como requerimiento antes de poder proceder al pago.

6. UI

Es bastante mentiroso decir que este es el último paso porque, en mi caso, me resultó más natural irlo haciendo en el camino. Pero, si llegaste hasta acá solo analizando contenido y UX o trabajando en papel, tranquilamente podes dejarlo para el final. Algunos tips:

• asegurarnos de estar usando colores institucionales o que los tonos sean consistentes (ejemplo: que todos los textos tengan los mismos colores o que todos los botones usen el mismo violeta). Esto, idealmente, sigue las guías de estilo de la marca y sino podemos usar el sentido común para que la paleta sea reducida y armónica.
• chequear que estemos usando las tipografías de la marca y buscar generar consistencia en su uso. Ejemplo: si vemos que se usa una tipografía para títulos y otra para el resto de los texto, trasladar dicho criterio a los títulos que incorporamos.
• ver qué cosas pueden ser imágenes o íconos para facilitar su interpretación y llamar más la atención. En nuestro caso originalmente los ítems tenían ilustraciones que vimos que aportaban valor y ayudaban.
• generar bloques de contenido, ya sea mediante líneas, espacios vacíos o cajas, que permitan sectorizar y aislar la información para interpretarla como una unidad.
• buscar que los elementos secundarios no llamen demasiado la atención. Particularmente, me pasaba que las FAQ destacaban demasiado y sabía que quería que pasaran más desapercibidas.
• cuidar las alineaciones , tanto de textos como de elementos, para guiar al ojo y facilitar su correcta lectura.

Algunos cambios extras que hicimos en esta pantalla:

• agregamos el logo de Stripe junto al botón de pago para dar confianza;
• movimos el logo de reglas HIPAA para que esté siempre presente en la barra de navegación y no sea algo circunstancial;
• Movimos la caja de “Contact us” a un botón flotante para usar Zendesk o similar,
• dejamos 4 “grandes bloques de información”: el de los pasos a la izquierda, el central principal con lo que incluye el plan y acciones a realizar antes de pagar a modo de alerta, el de pago, resaltando el costo a pagar y lo que puede que se les devuelva luego y las FAQ al final de la pantalla.
• Cambiamos el título principal para que coincida con el nombre del paso a la izquierda y se genere esa relación entre pasos a realizar y dónde estoy.

¿Es todo lo que hago como UX & UI Designer? No, obvio, si tenemos tiempo, más recursos y nos dan la oportunidad se puede trabajar en muchas cosas más, analizar cosas en detalle, hacer research, validar con el equipo, peeeeeero si los recursos son limitados esta es una gran forma de hacer mucho con poco y que se note nuestro aporte a la causa. Espero que te haya servido, dejame en los comentarios si tenés dudas o querés saber más en detalle de algo puntual!