La especialización es para los insectos
Cuando compré la entrada para UXfighters justo empezaban a dar fruto los últimos dos años de intentar encauzar mi vida profesional por donde yo quería y no por donde me dictaban las consultoras para las que he trabajado. Iba con la idea de ser muy novato en esto, o al menos en como yo entiendo que tiene que ser un diseñador UX Pero ya lo dijo uno de los ponentes, «casi todos somos intrusos en esta profesión». Así que de momento me quedo con la realidad de que mi trabajo actual y mucho del pasado está bajo ese término tan ambiguo que el paraguas de la UX y dejemos para un post futuro dudas sobre definiciones de concepto y de identidad individual.
Es complicado hacer un resumen de todo de lo que se habló estos días en la primera edición del UXfighters, pero como bien se dijo, la función de un diseñador de UX es poner orden en el caos y releyendo las notas (Habrá post- posteriores con las notas en crudo) veo patrones que se repiten entre los conferenciantes.
- A diseñar se aprende diseñando.
- Pues si a hacer se aprende haciendo y a programar se aprende programando, a diseñar se aprende diseñando: Prototipar, hacer wireframes, dibujar en una servilleta, pintar en el illustrator, buscar soluciones a problemas cotidianos.
- El usuario sí importa.
- No hay que perder nunca el foco de esto. Creation, el sello que publicó locuras maravillosas como el Loveless de MBV tenía claro que ellos hacían las cosas por sus usuarios “Doing it for the kids” era su eslogan. Y cuando dejaron de tener este mantra en mente y empezaron a hacer las cosas para ellos y para un público no objetivo desaparecieron y las multis se repartieron sus migajas.
- Recordemos que hacemos las cosas para prevenirles de experiencias negativas y para crearles experiencias placenteras, que cuidamos y mimamos el copy, el diseño visual, las interfaces y las interacciones para que hagan “sus cosas”, sean estas las que sean (consultar el saldo del banco, comprar online, verse una porno…) sin tener que fruncir el ceño.
- El cliente también importa.
- Sí. Cliente no es lo mismo que el Usuario. El cliente te paga para que diseñes un producto que el pondrá en manos del usuario para obtener un beneficio. Y al cliente hay que, si no quererlo, sí intentar entenderlo y trasmitirle que lo que hacemos lo hacemos por el usuario y que todos saldremos ganando si trabajamos en la misma dirección.
- Diseñar y programar.
- El que diseñador y programador se fusionen en un solo cuerpo, a la manera de Tetsuo no va a ser algo de hoy para mañana, pero quizás si de mañana para pasado mañana y hay que estar preparado. No le falta razón a Leyva, lo he vivido y lo vivo cada día, actualmente los programadores pueden diseñar más o menos bien, al menos el layout de una web y encima añadir funcionalidades e interacción, pero no veo al 99% de los diseñadores haciendo una consulta a la base de datos y pintando en pantalla los resultados.
- Google apuesta también por esta hibridación con su Material Design, un lenguaje de diseño. Su framework de JS, AngularJs, ya cuenta con un repositorio de componentes Web y Google Polymer parece que va en serio con su mezcla de material design y web components.
- Conocer al usuario.
- Contra mejor conozcamos al usuario al que nos dirigimos mejor podremos diseñar para él. Tenemos varias maneras de conocerle.
- La analítica web nos va a decir cómo se comporta en nuestra web. Y a partir de los datos obtenidos vamos a poder adaptar la web a sus necesidades.
- Las empresas que disponen de centros de atención al cliente desaprovechan la oportunidad que ellos les brindan para conocer de primera mano cuales son los problemas de los usuarios. El equipo de diseño debería de poder trabajar en contacto con los Customer Care para conocer esos problemas y, de paso, mejorar el sentido de pertenencia (a sense of belonging) de los empleados, de manera que se vayan creando sinergias que se muevan en la misma dirección no ya solo entre departamentos más o menos relacionados (diseño y desarrollo) sino entre todos los departamentos de la empresa.
- Los propios metadatos que se pueden obtener del usuario porque el usuario nos los proporciona de manera voluntaria (o involuntaria, pero nunca haciéndole trampas)
- Contra mejor conozcamos al usuario al que nos dirigimos mejor podremos diseñar para él. Tenemos varias maneras de conocerle.
- Si no son micro-lo-que-sea no son los auténticos.
- Lo micro está de moda. Ya sea por que vivimos en tiempos de microeconomía personal o porque lo pequeño es más cuqui, lo cierto es que es la palabra de moda y con razón. Ya lo cantaban los cohete; Micro, macro, esto no es un simulacro
- Micro-copy. Crear pequeñas narrativas que lleven al éxito del proceso.
- Micro-Interacciones. Deleitar al usuario con pequeños detalles.
- Lo micro está de moda. Ya sea por que vivimos en tiempos de microeconomía personal o porque lo pequeño es más cuqui, lo cierto es que es la palabra de moda y con razón. Ya lo cantaban los cohete; Micro, macro, esto no es un simulacro
Para dentro de unos días dejo el plasmar de una manera más o menos coherente las notas que tomé y comentarlas desde mi posición de aprendiz de UX, que es casi como decir aprendiz de mago. De mago que pone orden en el caos. No recuerdo quién dio esta definición de nuestro trabajo (si, venga, esto en ello), pero me quedo con ella. [À Suivre…]
Escrito por Dan Cederholm, un diseñador con varios libros fabulosos sobre CSS en el mercado, esta es una perfecta introducción a Sass si vienes del diseño o de la maquetación y tienes pocos (o ninguno) conocimientos de programación.
Este es el primer libro que leí sobre Sass. Y hace honor a su nombre. Es un libro pragmático en el que desde el primer momento se aprende haciendo. Cada capítulo es un ejemplo explicado paso a paso de manera que puedas testear el código por ti mismo. Se explica desde cómo instalar y probar con la línea de comandos y se van detallando los conceptos de Sass de manera progresiva, cubriendo un amplio espectro del lenguage y sus posibilidades.
T&T 