Registro

• Resulta pesado rellenar varios campos para una mera suscripción a newsletter. Es suficiente con tener el e-mail y nombre del usuario.
• Para evitar e-mails falsos u otros problemas de seguridad, el registro al newsletter podría ser a partir de una confirmación de correo enviado al buzón del usuario.
• El borrar la suscripción debería ser algo fácil, un clic y bien visible en el propio newsletter enviado. De lo contrario puede que el usuario (por no buscar) acabe marcando el newsletter como spam, perjudicando a la dirección de envió.

Spam

• Evitar los filtros spam no incluyendo palabras como: gratis, free, descuento, etc. Algo que puede ser difícil teniendo en cuenta el sitio web y el target al que vaya dirigido.
• Encabezar o situar en posiciones superior la fecha del newsletter. Esto podría evitar el ser confundido con Spam.
• Chequear los enlaces enviados en el contenido del newsletter. No pueden existir enlaces que lleven a un “not found” y menos aún enlaces que puedan llevar a sitios web penalizados por los buscadores.
• El envió de e-mails debe ser distribuido en periodos, no debe hacerse nunca de forma masiva y simultanea.
• Si se compran o se venden listas de e-mails lo más probable es que se acabe cayendo en una lista negra, con su consiguiente penalización como Spammer. Es complejo y lento salir de listas negras.
• Si varios e-mails chequean como spam al newsletter se puede caer en el riesgo de que un proveedor identifique la IP como Spammer.
• Una forma de asegurarnos que el newsletter sea leído en inbox y no pase directamente a spam, es hacer que la dirección de envió figure en listas blancas (desconozco como llegar a ello).
• Quitar URGENTEMENTE aquellos suscriptores que están eliminando, no abren, o marcan como spam el newsletter. Lo están perjudicando en cada acción.

Comunicación

• Estar en contacto con los lectores. Tras el registro al newsletter no pueden pasar los primeros 10 días sin ninguna noticia.
• Dar algún enlace hacia una web/email para contactar con el soporte.
• Se puede enviar el newsletter desde una dirección a la que el usuario pueda responder y así obtener con ello feedback directo del lector. Incluso invitarles a realizar ese feedback.
• Usar un lenguaje que tenga que ver con el target (edad, sexo, estudios, etc). Por ejemplo puede ser un lenguaje llano, natural o espontaneo que resulte muy cercano e invite a leer y participar.
• Los lectores parecen se más receptivos los Martes y Miércoles de 2 a 3 PM. Según he leído las razones pueden deberse a que los usuarios en el Lunes tienen la bandeja algo saturada del fin de semana, y los Jueves/Viernes ya vuelven a preocuparse más del fin de semana que del correo pendiente.
• Personalizar los e-mails para resultar más cercano y menos automatizado. Esto puede realizarse con variables para el saludo y despedida:
  • Hola [username]
  • Saludos [username] del equipo [nombre-proyecto]

  Incluso se podría personalizar en función de la hora del envió:

  • Buenos días [username]
  • Buenas tardes [username]
  • Buenas noches [username]

Contenido

• Poner un link para ver la versión web del email enviado (una alternativa).
• Pensar en títulos adecuados para cada newsletter.
  Ejemplo: Compañía – Asunto [Ref.12]
  • Primero la compañía/empresa/marca que enviá el newsletter.
  • A continuación el asunto/titulo del newsletter.
  • Finalmente podemos incluir el número (referencia) del newsletter.

  *nota: el asunto debe tener menos de 50 caracteres por razones de compatibilidad con el mayor número de gestores posible.

• Indicar al usuario que ha recibido el email debido a que esta suscrito en [nombre-proyecto] (enlace a la web).
• Los newsletter deben ir relacionados con la temática que se espera. El contenido debe ser de gran valor para no perder suscriptores.
• Dar muy buenas razones para permanecer suscrito al newsletter. Esto puede hacerse con descuentos, promociones, noticias, secretos, en definitiva cosas que no puedan obtener por otros medios.
• Incluir un enlace a la política de privacidad.
• Incluir datos para saber que detrás hay una empresa real. Por ejemplo la dirección, el teléfono, etc.
• Invitar al usuario a seguir leyendo contenidos con enlaces hacia la página web.

Diseño

Merece un post aparte debido a las peculiaridades: Código para el diseño de e-mails y newsletters.

En una de las preguntas Manovich comenta que no le gustan los defensores de la usabilidad web, pues cree que no tienen ningún criterio estético y están proponiendo algo que resulta extremadamente aburrido.

En mi opinión, no puedo estar más en desacuerdo con esta postura.
El primer pensamiento que puede tener tanto un diseñador como un usuario es que la usabilidad puede mermar la creatividad y que las convenciones de diseño que a su vez favorecen al campo de la usabilidad van en detrimento de las posibilidades creativas. Se puede llegar a pensar que incluso si seguimos todas las convenciones favorables en usabilidad acabaríamos con un diseño global homogéneo y aburrido.

Nada más lejos de la realidad. Los diseñadores siempre han estado expuestos a convenciones y también a restricciones en todos los medios de expresión, desde la pintura en lienzo al diseño web. De hecho el diseño web es diseño de interacción por lo tanto estamos expuestos a tener en cuenta la conducta humana en este medio.

Las convenciones de usabilidad y las restricciones impuestas por el diseño de interacción más que minar nuestra creatividad la agudiza, haciendo que sigamos siendo creativos pero teniendo en cuenta dichos factores.

Recuerdo una cita que lo ilustra perfectamente:
Diseño es arte optimizado para conseguir objetivos Shimon Shmueli

Ahora expongo una revisión de esta idea pero intentando tomar como base las premisas del DCU .

He elaborado un esquema en el siguiente documento: Diseño centrado en el usuario, una propuesta. (PDF – 188Kb)

Básicamente divido el proceso en 5 etapas:

1. Arquitectura de la información
   1. Análisis (información, objetivos, usuarios)
   2. Diseño conceptual (blueprints, wireframes)
2. Diseño
   1. Diseñó visual (mockups)
3. Desarrollo
   1. Front-end (web estática)
   2. Back-end (web dinámica)
4. Publicación
5. Mantenimiento

En la propuesta, la evaluación de interfaz/usuarios deber correr desde su inicio y en paralelo al proyecto.
Se harían interacciones de evaluación constante con los usuarios a través de: Blueprints (prototipo de baja fidelidad) > Wireframes (prototipo de media fidelidad) > Mockup (prototipo de alta fidelidad) > Web estática > Web dinámica.

Desde entonces han mejorado un poquito la accesibilidad, aunque siguen sin usar la etiqueta label para el campo de Email de inicio de sesión. En su lugar han puesto los atributos title y value. El problema es que algunas ayudas asistivas pueden no interpretar el atributo title, por lo que esta solución no sería suficiente.

Respecto a la usabilidad puede ser debatida, pero el hecho de perder (lo que tienes que rellenar en ese campo) cuando haces clic en el, me parece un error. Eso si, visualmente y a nivel de interacción queda chulisimo.

Hoy, Kus (de uninstallme.com) me comenta:

Acabo de encontrar esto http://www.csskarma.com/lab/slidinglabels/ y me he acordado de este post. No lo he analizado a fondo, pero me ha parecido una buena idea.

Y tanto que es buena idea, la accesibilidad es impecable. Se usa JavaScript como un complemento no intrusivo que se encarga de realizar el efecto y la transición del label. Solo le veo una pega, que puede resultar cansino, yo lo usaría para formularios muy pequeños, con 2 o 3 inputs.

Un lujo contar con tus aportaciones María

Enlaces y botones

En la zona superior del sitio web Cinemavip se define claramente a quien va dirigido y que puede ofrecer esta red audiovisual.

• Por un lado destacan los enlaces a la secciones de usuarios, el directorio de empresas y las ofertas de empleo. Tres pilares básicos de la red social.
• Por otro lado tenemos el Marketplace, un nuevo servicio sobre el que se quiere captar la atención. Por ello en este último caso gana fuerza el empleo de un botón, aunque con las mismas sinergias de colores que los enlaces.

Botón de formulario como acción principal

En los formularios el usuario puede realizar varias acciones: enviar, guardar, borrar, cancelar, volver atrás, etc. Para mejorar la experiencia de uso podemos identificar que acciones son más comunes y en base a ello destacarlas visualmente.

En este caso volvemos a recurrir al empleo de un botón para realizar la acción principal “Enviar”. Por otro lado disponemos de un enlace para “volver atrás”, una acción claramente secundaria. De esta forma evitamos el empleo de dos botones iguales que se enfrentarían por ganar el foco de atención.

Destacar a base de color

En este ejemplo vemos 3 eventos próximos en el tiempo, pero el más cercano esta ubicado como el primero de ellos y bajo un color de fondo más oscuro, resaltándolo frente a los otros dos y así alertando de su cercanía.

Los 3 ejemplos pueden parecer pequeñas tonterías pero conviene prestar atención a detalles así, los cuales son cruciales para la experiencia del usuario.

Añadir tab en Internet Explorer

Añadir tab en Firefox

Siempre que instalaba una versión de Firefox repetía la tarea de poner el icono “añadir pestaña”, y el caso es que me parece incomprensible que este navegador no pusiera algo tan usual por defecto hasta ahora; Por fin!

Recuerdo que Yusef Hassan comento esto mismo y alguien menciono que Firefox si tenía ese botón, pero la verdad es que yo no lo descubrí hasta la nueva versión, donde ya aparece bien clarito y posicionado.

En esta ocasión Firefox llego después que otros navegadores, aunque hay que reconocer que lo hizo con fuerza, a mi parecer la posición y la icono-grafía es mucho más intuitiva que la del resto.

Juan comenzó hablándonos acerca del significado de la usabilidad, interpretando el concepto usabilidad como un atributo, una cualidad de algo.
Sobre esto ya se ha escrito en el blog: ¿qué es la usabilidad web? y ¿cuáles son sus ventajas?.

A continuación nos da un ejemplo muy esclarecedor de usabilidad.
Fijémonos en el cajero (de las entidades bancarias), devuelve antes la tarjeta que el dinero y esto simplemente persigue un objetivo: no olvidarnos de la tarjeta. Algo muy lógico pero inteligente, pensemos que cuando vamos a sacar dinero en nuestra mente tenemos únicamente dos palabras “sacar dinero”, una vez recibido hemos cumplido nuestro objetivo y nos vamos sin pensar en terceras cosas.

Juan comenta que la usabilidad es una ciencia multidisciplinar por lo tanto es necesario incorporar a gente de diversas ciencias (y no se trata de informáticos), todos pueden aportar su visión (diseñó, tecnología y negocio).

A continuación nos habló largo y tendido sobre idealista.com.

Me resultaron muy interesantes las diapositivas que mostraban el avance del diseño desde el año 2000.
Por otro lado también me llamo la atención los test y bocetos pintados de pruebas de usuarios. Es curioso ver como la gente pinta exclusivamente aquellos elementos con los que ha dialogado (establecido algún tipo de interacción): botones, casillas, cajas de texto, enlaces, etc.
Por ello es tan importante que cuidemos y mimemos estos elementos.

Sobre interacción nos dijo como lo ideal es que percibamos previamente la acción de un elemento sin llegar a dialogar con el. Osea un botón debe percibirse como tal!

Posteriormente comentó algunas leyes que influyen en la usabilidad.

• Ley de Hick: Cuantas más elementos existan más tiempo se tarda en tomar una decisión. El número máximo parece ser 7.
• Ley de Fitts sobre la que también hemos hablado.
• etc.

Buena conferencia, ha sido muy gráfica.

Comienza hablándonos sobre su perfil profesional (freelance, consultor de usabilidad, diseñador de interacción, blogger, etc). Me ha gustado eso de que con el blog ha adquirido gran parte de lo que sabe, por eso le gusta definirse también como blogger.

Le apasione su trabajo y nos cuenta que esto es algo fundamental (me siento reflejado jejeje).

Sobre los diferentes temas abarcados nos comenta que principalmente hablamos de diseño. Y en este momento hacemos un recorrido por la Wikipedia, RAE y WordReference para aproximarnos al significado de este término.

Como resultado tenemos una serie de palabras: proceso, búsqueda de una solución, creatividad, técnica, etc. Ahora bien, ¿cómo podemos afrontar todo esto?. La respuesta es clara: mediante una metodología.

Y en este punto he recordado un libro que leí hace muchos años sobre ingeniería del software (como han cambiado las cosas desde entonces). Bueno, la cuestión es que para la web podemos aplicar una metodología clásica, como la que se empleaba para el software de escritorio (a grandes rasgos).

Hasta aquí todos hemos llegado casi “sin problemas” (me incluyo) pero ahora viene lo mejor.

Daniel nos propone que una vez tengamos la experiencia aportada de la metodología podemos empezar a romper los procesos.

Esto es algo que ya comentaba en su día Alberto Knapp.

Imagino en las palabras de Dani, que en vez de seguir un proceso basado en la sincronía en el que a veces la consecución de objetivos se vuelve unidireccional. Es mejor realizar un proceso asíncrono y bajo una consecución de objetivos bidireccional.
Madre mía releyendo lo que acabo de escribir me están dando mareos

La idea que se persigue bajo las claves de metodología, proceso y producto es que el resultado final prime por encima del proceso y no al revés.

Bueno, lo importante de toda esta “paranoia” se resume en: iterar.

Prototipar (probar) e Iterar (feedback) interpretando el producto final como el propio proceso metodológico. En este sentido se le da máxima importancia al producto final y no tanto al proceso que se lleva a cabo.

Pero… ¿y si falla alguna de las iteraciones?.
Por ejemplo supongamos que entregamos un wireframe al cliente. Este a pesar de haber recibido una explicación breve de lo que se trata, ve el wireframe y simplemente nos responde diciendo que no le gusta nada el diseño.

En este punto debemos prestar atención a los obejetivos.
En el caso concreto del wireframe no basta con una simple explicación al cliente, hay que describir ese wireframe, presentarlo y explicar su conceptualidad.

Tanto el wireframe, diseño, desarrollo y cualquier entregable tiene que perseguir el cumplimiento de unos objetivos concretos.

Y lo que es aún más importante, todo cliente tiene una serie de objetivos. Puede que nosotros no los conozcamos o que el cliente no los sepa comunicar, pero esos objetivos están ahí.
De hecho todo tiene objetivos, el propio proyecto, los entregables, el cliente, el equipo, la compañía.

En fin, me quedo con descubrir objetivos, tenerlos muy claros, acometerlos, e iterar mirando siempre al producto final y no dejándose manipular por el proceso.

Bajo este rimbombante titulo Isabel nos ha hablado acerca de:

• Los fundamentos del diseño de interacción.
• El diseño estratégico.
• La función de prototipar.
• La información gráfica.
• La estrategia en el contenido.

Fundamentos del diseño de interacción

El Diseño de interacción define el comportamiento (la “interacción”) de un producto o sistema en respuesta a sus usuarios.

Isabel nos habló de las principales tareas que debería desempeñar un diseñador de interacción:

• Analizar el comportamiento de los usuarios.
• Crear historias y escenarios.
• Prototipar y probar con los usuarios.
• Ofrecer soluciones de interacción.

Un tema que me resulto curioso fue la idea de analizar a los usuarios realizando cuestionarios libres para que estos no se sientan probados.
También hizo mucho hincapié en que interpretemos el diseño como un proceso para resolver problemas. Y esto me hace recordar una de mis citas favoritas:

Diseño es arte optimizado para conseguir objetivos. Shimon Shmueli

Diseño estratégico

De todo este apartado me quedo con una frase:

Si el diseño no genera negocio es que es una mierda. Ale Muñoz

Estoy absolutamente de acuerdo y es algo que he experimentado (tanto en el fracaso como éxito). Es totalmente necesario que nuestro trabajo genere riqueza o nos reporte algún tipo de beneficio.
Supongo que para los que estamos como freelance o empresarios esto se magnifica produciéndonos mucha “comedera de tarro”, pero también nos hace madurar a pasos agigantados y darnos cuenta de lo gratificante que es generar uno mismo esa riqueza.

Prototipar

Un prototipo es un modelo original, la forma, o ejemplo de algo que actúa como ejemplo, la base, o la norma para otras cosas de la misma categoría.

Destacó principalmente:

• Generar un prototipo es menos costoso que desarrollar el producto final.
• Al ser testable ayuda a corregir potenciales errores antes de entrar en producción.
• Hay dispositivos como el eye tracking que ayudan a la hora de detectar problemas.

Información gráfica

La presentación de los datos puede ser hermosa, elegante y descriptiva. Una frase que me ha parecido muy bonita.

Después nos pregunta ¿cuáles son los enfoques más creativos para presentar los datos en formas que nunca hemos pensado antes? Y nos habla sobre diferentes modelos: mindmaps, newsmap, etc.

Por último algo muy importante que no aparece en la diapositiva pero que nos comentó: Es importante que pensemos en soluciones creativas, innovadoras y que sobre todo valgan para un futuro.

Estrategia en el contenido

Tengamos en cuenta que las ideas son generadas, evaluadas, criticadas, alabadas y recicladas. Que todos generamos contenido, que a su vez genera conversaciones (vídeo, chats, comentarios, etc).

Me ha resultado curiosa la mención a Smashing magazine y su modelo. Como se ocupan de ejercer de comisarios, siendo una referencia en el diseño web y únicamente dedicándose a indexar y lanzar contenidos ya generados.

Finalmente nos enumera una serie de claves e ideas con el fin de analizar los contenidos para rentabilizar y sacar adelante proyectos.

Dispositivos móviles

Elena comenzó hablándonos acerca de los diferentes dispositivos móviles y sus características:

• Diferente hardware
  • Varios tamaños de pantalla.
  • Paleta de colores, contrastes, imágenes.
  • Diferentes teclados: caracteres, disposiciones, teclas-significados
  • Conexiones, memorias, etc.
• Diferentes métodos de interacción: joystick, click whell, touchpad, touchscreen, reconocimiento de voz o el clásico teclado.
• Diferente Software: Nos podemos encontrar múltiples sistemas operativos: Symbian, Windows Mobile, Mac OS, Android.

Problemas comunes

• La pesada tarea de introducir texto.
• Pantalla demasiado pequeña.
• Botones pequeños para nuestros dedos.
• Modelos de navegación complejos.
• Scrolls horizontales.
• Imágenes.
• Webs que no sigan estándares.
• Falta de soporte para elementos embed, plugins y scripts.

Posteriormente me resultó muy interesante la comparativa acerca de usabilidad en los móviles normales, los smartphones, y los móviles de pantalla completa (iPhone).

Y retomando de nuevo al omnipresente iphone, Elena nos da 4 consejos:

• Orientar el diseño a botones y que exista espacio suficiente entre ellos.
• Feedback visual para los toques.
• Diferenciar que zonas son activas.
• Posibilidad de retroceder.

Diseñando una experiencia de usuario satisfactoria

Para diseñar la versión móvil de un sitio web nos dice que tenemos 4 opciones (de peor a mejor):

• No hacer nada y esperar que la renderización haga su trabajo.
• Reformar el diseño suprimiendo estilos e imágenes.
• Diseñar una hoja de estilo especifica.
• Diseñar un estilo y aplicación especifico.

Si acudimos a la cuarta opción debemos tener muy en cuenta el área de la arquitectura de la información.

Y más consejos al respecto:

• Diseñar en base a objetivos.
• Tener en cuenta el volumen de información para la velocidad.
• Reducir el número de enlaces y tener presente el coste del clic.
• Limitar opciones.
• La información se debe presentar de forma lineal.
• Muy importante el ordenar los contenidos por prioridad, popularidad.
• Accesos rápidos para otorgar mejor experiencia de uso a los usuarios habituales.
• Feedback, cuando se produce una acción responder con un sonido o cambio de estilo.
• Todo debe tener un principio, cuerpo y final.
• Prevenir errores.
• El contraste es muy importante en aplicaciones móviles.
• Diseñar pensando en contextos múltiples y dinámicos. Por ejemplo en un contexto en el que tengamos el audio desactivado.
• Siempre que fuese posible seleccionar texto en vez de introducirlo.

De todos estos consejos hay uno que me parece especialmente importante: prevenir errores algo crucial para la usabilidad. Es clave anticiparse al posible error antes de que ocurra, y si ocurre solventarlo de forma inteligente.

Posteriormente Elena nos habló (largo y tendido) de las Mobile Web Best Practices 1.0 y finalmente del recurrido validador W3C mobileOK Checker.

Algunas preguntas

Le pregunto a Elena como ve el estado de la web móvil hispana. Pensando en las excesivas tarifas, conexiones lentas, etc.
Me comenta que a pesar de todos los inconvenientes se va notando un incremento en versiones textuales o dirigidas a móviles, sobre todo los sitios webs de periódicos.

Otra pregunta interesante es si ella prefiere una web única, o dos versiones (una de escritorio y otra móvil). Su respuesta predeciblemente ha sido una doble versión.

Esto es interesante puesto que como hemos comentado en este blog “Mejor con estándares web, ventajas” sabemos que una ventaja es precisamente la adaptación al dispositivo final. Aunque hoy en día sea totalmente irreal.