👋 Hola, ¿Cómo estás?

Yo bien, aunque ha sido una semana de locos, es por eso que estoy enviando la newsletter el jueves a las 18h de la tarde y no el miércoles como tenía previsto. Pero oye, no pasa nada. Los imprevistos pasan, y a la vida no le importa nada lo que tú tengas planificado de antemano 🤗

Así que aquí estamos, un jueves de Creative Insights, ready para compartir algunas lecciones basadas en mi experiencia de casi 5 años como Product Designer que espero que te sean útiles.

¡Vamos a ello! 🤍

Ah, y si todavía no estás suscritx, dale al link de abajo para formar parte de esto↴

ERROR #1: Esperar demasiado para pedir feedback

Este es un error que solía cometer muy a menudo al principio de mi carrera profesional. Sentía que si enseñaba diseños inacabados o sin estar pulidos, demostraba que mis skills no eran lo suficientemente buenos.

Con el tiempo, me di cuenta de que a nadie le importaba que me hubiese pasado 1.000 horas puliendo un diseño, ya que al final lo importante es qué y como se comunica.

Así que me paré a analizar porque me empeñaba tanto en pulir los diseños y detecté red flags 🚩 en mí misma:

1. El primer motivo (y el más importante) era el síndrome del impostor 🥲 Pensaba que mostrar diseños inacabados, con posibles errores o sin pulir, era señal de poca profesionalidad. ¿Pero, adivina qué? Eso simplemente lo pensaba yo. Al final el resultado final es mucho mejor si había pedido feedback temprano, y además, contra todo pronóstico, también se ahorraba tiempo.

2. El segundo motivo era que pensaba que no iban a entender el objetivo final si el diseño no estaba pulido 📱 Suplía la falta de comunicación con un diseño más completo. Sin embargo, descubrí que lo único que hacía falta era presentar el contexto y comunicar de manera clara que es lo que se va a mostrar y porque no deben esperar un diseño final.

3. Por último, también pensaba que me iba a ahorrar tiempo ⏳ ya que muchas veces daba cosas por supuestas y pasaba el diseño final pensando que el feedback sería mínimo y.. ¡Spoiler! Nunca es así, siempre pueden aparecer nuevos insights o puntos de vista que pueden hacer cambiar el diseño, así que mejor construir algo escalable que un diseño final.

ERROR #2: Diseñar sin cuestionar lo que han pedido los stakeholders o developers

🙋‍♀️ Que levante la mano quien no ha cedido alguna vez a las presiones de los stakeholders y desarrolladores. Pues yo he cometido este error muchas veces (y este es uno que sigo cometiendo de vez en cuando).

¿El motivo principal? La necesidad de mantener una buena relación con ellos y las limitaciones de tiempo y presupuesto. También hay que mencionar, que hay veces que simplemente nos cansamos de insistir de la importancia de hacer User Research o User Testing. No es bonito de decir, pero estas cosas pasan, con algunos clientes/empresas es muy difícil llevar a nuestro trabajo a cabo de la manera correcta.

Esto me ha llevado varias veces a un estado de desmotivación y a cuestionar el valor de mi trabajo. Así que esto es lo que intento hacer ahora cuando me veo en esta situación:

1. Entender que el equilibrio es clave ⚖️ Obviamente nuestro trabajo como UXers es abogar por el usuario, pero hay veces que las necesidades de los stakeholders o los developers pasan por encima por X o por Y. Es de ingenuos pensar que siempre vamos a poder pasar las necesidades de los usuarios por delante, así que lo primero que hago es no culparme ni tomármelo como algo personal.

2. Aprender a negociar pequeñas concesiones 🤝 Entender que intentar incluir sus ideas/necesidades de manera estratégica (por ejemplo: con la condición de validarlas en un futuro) ya es un paso para acercar el User Research a los stakeholders.

3. Aprender a defender las decisiones de diseño basándome en principios de UX y evidencia sólida 📝 Esto se ha convertido en una habilidad fundamental. Podemos basarnos en datos o patrones de grandes empresas que han testeado eso antes que nosotros (eg. Google o Apple) para intentar convencer a los stakeholders (¡funciona bastante bien!)

4. Comunicar de manera asertiva y clara 🗣️ La clave es comunicar por qué ciertas decisiones son beneficiosas para la experiencia del usuario para que los demás comprendan que no es una elección personal, sino que es una apuesta para el producto/negocio.

ERROR #3: Olvidarme de diseñar los Edge Cases

No creo que sea la única a la que muchas veces se la pasan por alto los edge cases, y es que es muy fácil centrarse solamente en los casos de uso más habituales y olvidar aquellos que solo pasan de vez en cuando.

No obstante, es importante tenerlos en cuenta, ya que van a marcar un antes y un después en la experiencia de usuario.

Aquí te dejo algunos tips que utilizo para intentar evitar olvidarme de edge cases:

• Empezar por diseñar el happy flow (el flow ideal que diseñamos para que el usuario llegue al objetivo acordado) y luego preguntarte qué sucedería si un usuario comete un error o se encuentra en una situación inusual. Cuantas más preguntas mejor.

• Mantener una conversación activa con los developers, ya que a menudo ellos se encuentran con nuevos edge cases cuando están implementando (no es lo ideal, pero siempre pasa).

• Acude a ChatGPT y pídele que te ayude a encontrar los edge cases de un “happy flow”. No olvidemos que la inteligencia artificial puede ser una gran aliada.

ERROR #4: Dedicar demasiado tiempo a los wireframes

Este también fue un error que cometí al inicio de mi carrera profesional y que ahora puedo decir que ya no hago.

Cuando empezamos a estudiar UX/UI se le da muchísima importancia a los wireframes (bueno, y a todos los pasos del proceso), pero lo que es realmente importante es saber valorar la necesidad de dedicar tiempo a crearlos dependiendo del contexto real del proyecto.

No hay que olvidar que los wireframes no son más que una herramienta para explorar soluciones y validar la estructura y/o arquitectura de un producto. Así que apuesta por wireframes rápidos que te permitan validar e iterar.

Debo confesar que a día de hoy casi nunca trabajo con wireframes. La mayoría de proyectos en los que trabajo tienen Design System, por lo que es más eficiente utilizar los componentes ya creados antes que ponerme a crear esqueletos.

No digo que no sean útiles, pero hay que saber valorar la importancia de crearlos.

Recursos de la semana

🎨 Realtime Colours: Herramienta online (también disponible como plugin de Figma) que te permite hacer una previsualización de paletas de colores y tipografías a tiempo real, de manera superrápida.

• ¡Shoutout al seguidor de Instagram que me recomendó esta herramienta!

📱 Chamjo.Design: Se trata de una biblioteca online donde encontrarás más de 500 capturas de pantalla o flows de apps.

• Es muy parecida a Mobbin (que sigue siendo mi favorita) pero esta tiene apps de Asia y otras "menos famosas”.

💻 Relume Library: Se trata de una biblioteca de componentes Figma y Webflow, pero lo interesante de Relume Library es que ha lanzado una funcionalidad para generar páginas web con inteligencia artificial a partir de un prompt.

• La versión gratuita solo te permite hacer el sitemap y un wireframe, pero vale la pena jugar con ello para tener un punto de partida para tu proyecto. También te permite pasarlo a Figma o Webflow una vez lo tengas listo.

Y esto es todo por hoy 🫶

Recuerda que puedes seguirme en Instagram 🫶 o enviarme un email para darme feedback sobre la newsletter o pedir que hable sobre algún tema en concreto!

Aaaaah, y si quieres puedes aportar tu granito de arena y escribir en los comentarios, si has cometido o si cometes uno de estos errores (o algún otro) ↴

〰️ Judit