UX Fighters: Primer asalto

UXfighters

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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)
  6. 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
      1. Micro-copy. Crear pequeñas narrativas que lleven al éxito del proceso.
      2. Micro-Interacciones. Deleitar al usuario con pequeños detalles.

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…]

Anuncios

Libros sobre Sass y Compass

Que Sass y Compass son ya una herramienta generalizada en el desarrollo web lo marca el hecho de que ya existan, que yo conozca, cuatro libros dedicados a esta nueva manera de codificar CSS, tres de ellos aparecidos este mismo año.

Si aún no lo sabes, Sass es un metalenguaje de CSS con la versatilidad de un lenguaje de programación (variables, código reutilizable…) que al compilar genera un archivo CSS. Compass es un framework para generar CSS que utiliza Sass para hacerte la vida más facil a la hora de crear sprites, trabajar con CSS3 y un montón de cosas más. He tardado en usarlo, y apenas estoy empezando, pero la verdad es que merece la pena el esfuerzo. El código es más limpio y mantenible y con la ventaja de que se tarda mucho menos en escribir.

Antes de empezar con él asociaba Sass a Ruby, lenguaje que desconozco y a la línea de comandos, que siempre asusta un poco. La realidad es que no hay que saber nada de Ruby para poder usarlo y que la interacción con la terminal es mínima.

La documentación oficial de Sass y de Compass es genial, pero muchas veces merece la pena tener un libro cerca para consultar, ya sea en papel o formato electrónico. Aquí van unas pequeñas reseñas de qué vas a encontrar, o echar en falta, en esos libros.

Sass For Web Designers

Portada del libro Sass For Web DesignersEscrito 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.

Explica de manera sencilla cómo Sass te puede hacer más feliz a la hora de escribir CSS con sus variables, @mixin, @import y @extend, cuenta como empezar a usarlo, cuál es el flujo de trabajo y da consejos sabios y cabales.

Como bolas extras dedica un capítulo a hacer Media Queries con Sass para los diseños adaptativos (Responsive Web Design) y otro a imágenes en pantallas de alta resolución.

No encontrarás aquí más información sobre Compass que lo que te he contado al principio del artículo. Tampoco un proyecto desde cero con todo el código, aunque sí ilustrativos trozos de Sass y su compilación en CSS.

Pragmatic Guide To Sass

Portada del libro Pragmatic Guide To Sass 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.

Me gusta especialmente cómo explica la versatilidad que nos da Sass a la hora de trabajar con los colores. Una parte entera del libro está dedicada a Compass. Empieza creando un proyecto y desarrolla en ejemplos algunas de sus funcionalidades: Listas, pegar el pie a la pantalla, clearfix, truncado de texto, columnas y sprites.

Hay dos bolas extras muy importantes en este libro: cómo Compass se complementa con Blueprint y una introducción a Haml, una especie de Sass para HTML que desconocía totalmente.

Sass and Compass in Action

  • Autores: Wynn Netherland, Nathan Weizenbaum, Chris Eppstein, and Brandon Mathis
  • Editorial: Manning
  • Año: 2012

Portada del libro Sass and Compass in Action

¿Qué se puede esperar de un libro sobre Sass y Compass en el que participan en su escritura los creadores de esas tecnologías? Pues que sea muy bueno y muy completo, orientado más a ingenieros de front-end que a los diseñadores.

Este libro, a diferencia de los dos anteriores va más allá de las funcionalidades básicas de Sass y Compass, estando más orientado a poner en práctica todos estos conocimientos en un proyecto real. Muy ilustrativo sobre ello es el capítulo dedicado a dar el paso a producción.

Bolas extras tiene unas cuantas; por ejemplo, cómo usar Saas y Compass con diferentes frameworks de CSS, Blueprint y 960º,  y un fabuloso y muy completo capítulo sobre sprites.

Se completa el libro con una parte titulada “Advanced Sass and Compass” que entusiarmará a los programadores y desesperará un poco a los diseñadores y maquetadores puros y duros.

Sass and Compass for Designers

  • Autor: Ben Frain
  • Editorial: Pack
  • Año: 2013

Portada del libro Sass and Compass for Designers

Ben Frain tiene un libro bastante bueno sobre diseño adaptativo, “Responsive Web Design With HTML5 and CSS3”, y en este sigue la misma metodología: Enseñar Sass y Compass a través de la creación de una página web. El código completo de cada capítulo se puede descargar e ir construyendo la web  la par que se va describiendo en el libro.

Aunque el público objetivo sea el mismo que el del libro de Cederholm, el diseñador / maquetador web con pocos o ningún conocimiento de programación, este va unos cuantos pasos más allá, recorriendo las posibilidades de Sass y Compass en casi su totalidad.

Tiene capítulos muy completos sobre manipulación de color, media queries y diseño adaptativo, CSS3 y sprites, tocando también las partes programables de Sass, como la creación de funciones o bucles. Es decir, que en realidad va un paso más allá de lo que un diseñador podría esperar de este libro, pero que seguramente necesitaría también saber.

Resumiendo

Los perfiles de los desarrolladores web son cada web más híbridos, así que no os toméis muy en serio este qué para quién del final y elige tu libro según hasta dónde quieras llegar en este momento con Sass y Compass.

  • Sass for Web Designers:
    • Maquetador /diseñador que quiere una primera impresión de Sass.
  • Pragmatic Guide to Sass:
    • Maquetador / diseñador que quiere ir un poco más allá de lo básico desde el primer momento.
  • Saas and Compass in Action:
    • Ingeniero de front-End que quiere dominar todos los aspectos de Sass.
  • Sass and Compass for Designers:
    • Para ingenieros de front-End y también para maquetadores/programadores que quieran alcanzar unos conocimientos medios/altos sobre Sass y Compass

The Elements Of Content Strategy

Portada del libro Elements of Content Strategy

“No se puede ser ambivalente sobre la WEB. Quizás la odies a veces, pero debes llevarla en la sangre”

Esta es una de las últimas frases que aparecen en The Elements Of Content Strategy. El libro de Erin Kissane es una introducción amena y sucinta a qué es la estrategia de contenido, una de las múltiples disciplinas que se dan cita bajo el paraguas del término Experiencia de Usuario (UX). Y así está escrito, con la suficiente pasión como para lograr que el lector quiera saber más de esta disciplina relativamente nueva. El libro trata los principios básicos de la misma, hace un recorrido histórico (el papel de editores, curators…)  y dedica su mayor parte a recopilar herramientas y técnicas que los estrategas de contenido (¿Es correcto el término?) usan en su día a día.

Se hace hincapié en la importancia de conocer al usuario (diseño centrado en el usuario), de buscar la claridad del contenido de manera que comunique , de no dejar que el contenido se quede obsoleto y en no tener miedo a prescindir del contenido no necesario.

Se habla también de la relación estrecha que un estratega de contenido ha de tener con el equipo de arquitectos de la información y de experiencia de usuario, con los que comparten algunas herramientas (Personas, investigación del usuario…) y de la necesidad de adquirir conocimientos sólidos de arquitectura de la información e interés por el diseño visual y el desarrollo de front-end.

También hay lugar para las diferentes especializaciones que pueden surgir dentro de este campo: marketing, gestión de la información o integración en equipos de UX o desarrollo web.

Entre las herramientas propias, destaca el ejemplo, completo y muy interesante sobre lo que sería un “Content Template”.

En resumen, una entusiasta introducción que da muchas pistas sobre por donde seguir si se quiere profundizar en la materia.