Usando Axure para definir interacciones con contenido dinámico

No soy la persona más fan del mundo de Axure, me parece complicado y anticuado. Axure es una herramienta de prototipado, una de las más populares y una de las potentes. Pero sigue estando muy orientada a interfaces web sin embargo

  • No resuelve bien el diseño de web responsivo
  • Las animaciones son programáticas (no hay timeline de animaciones)
  • Las animaciones y los estados de los paneles dinámicos no se llevan bien
  • Hay demasiadas malas prácticas que pueden llevarte a hacer insostenible el mantenimiento de un proyecto

En cualquier caso reconozco que es una de las más completas y se pueden cubrir la mayor parte de los prototipos que se quieren hacer sin necesidad de saber programar y sin necesidad de abrir otras herramientas de diseño.

Además dotar de vida a un prototipo estático es una gran oportunidad para empezar a sentir cómo va a ser el uso real del producto. La pregunta es sobre quién queremos que caiga el esfuerzo de la creación de dicho prototipo ¿sobre el diseñador o el desarrollador? Es más ¿es un prototipo que se use sólo para decidir o también para testear?

El debate sobre qué nivel de fidelidad y de interacción debe tener un prototipo la dejo para otro momento, ahora me quiero centrar en descubrir alguna de las cosas interesantes que se pueden hacer con Axure que, si bien no resultan obvias a primera vista, no son tan complejas después de todo (eso sí, de aquí a programar hay un paso pequeñito).

Gestión de contenido dinámico

Algo que da muchísimo valor a un prototipo es el uso de datos y contenido real. En muchos casos, si el diseño de la información es bueno, cualquier otro elemento de la interfaz pasa desapercibido.

La forma de usar datos dinámicos con Axure es mediante el componente repeater.

Un repeater no es más que un contenedor de elementos que se pueden repetir con valores diferentes y con misma apariencia. Es decir, es como una tabla pero sin tener datos fijos.

A un repeater se le pueden añadir filas, eliminar y modificar como quieras. Además se le pueden añadir y eliminar filtros y un criterio de ordenación e incluso paginarlos.

Lo interesante de los repeater es que se pueden usar para definir el modelo de datos de la aplicación donde se pueden gestionar elementos de navegación dinámicos (como un sistema de pestañas), listas de elementos gestionados por el usuario (por ejemplo una lista de películas favoritas) o simplemente un historial de acciones (que pueden usarse para deshacer a un estado previo).

Variables globales

Otra gran utilidad de Axure son las variables globales. De nuevo un elemento muy práctico para quienes necesitan orquestar la lógica del prototipo de forma que todo esté coordinado.

Las variables globales se pueden instanciar en cualquier momento disparado por cualquier evento de cualquier componente y ayudan a mantener el estado de la interfaz.

Pero ¿por qué necesitaríamos estados? Seguramente en el mundo web donde casi 90% de lo que se hace es navegación lineal vuestros prototipos a base de hiperenlaces sean suficientes. Sin embargo, cuando quieres prototipar una interfaz de usuario donde el usuario puede interactuar con muchos componentes a través de ratón o teclado, existan ciertos elementos cuyo comportamiento va a depender de la combinación de dichas interacciones, es decir, del estado en el que esté la interfaz en cada momento. Para conocer dicho estado, usar variables globales resulta tremendamente práctico.

Enlaces comentados #3

Beautiful Programming

Una web donde se hacen cosas artísticas con programación. Para toda esa gente curiosa y con espíritu creativo con ganas de dominar el cincel digital.

PIXEL ART TO CSS

Un editor para hacer imágenes pixeladas que puedan incluirse en tu web con CSS. Todo muy retro pero moderno.

Samsung va a pisar el acelerador con la producción de pantallas OLED, ¿preparándose para el iPhone? 

Deseando que llegue el momento. Sin duda las plantallas OLED y flexibles van a revolucionar la industria tecnológica y potencias las experiencias de usuario que a través de ellas podrían ocurrir. Me imagino el mundo lleno de superficies tácticles ubícuas, superficies que están integradas en cualquier objeto físico sin marcos.

The Material re-Design of Google Play That Will Blow Your Mind

Un ejemplo de diseño con Material Design contado desde su proceso hasta su resultado. Una genial forma de aprender algo más sobre el proceso creativo y al mismo tiempo inspirarse con un diseño espectacular.

Disney’s Frozen – A Material Point Method For Snow Simulation

La ciencia que hay detrás de la recreación de la nieve en la película de Disney Frozen. Espectacular resultado, precioso.

6 enlaces comentados #2

Applying UX Design Methods to Organizational Design and Teamwork

Me ha gustado porque reflexiona sobre por qué limitamos la experiencia de usuario a la tecnología o a un entorno concreto. En este caso lo aplica a un ejemplo concreto.

Why Users Abandon Forms with Select Menus

Hacía tiempo que no leía nada sobre usabilidad aplicada a interacción con formularios, se ve que ya no está de moda.

Death by Micro: Feedback Loops and Knowledge Management in User Experience

Even more dangerous is the possibility of our notconnecting the dots, failing to understand our mistake, and reflexively iterating on it in pursuit of future success.

 

Visualizations That Really Work

Visualizando visualizaciones que son útiles.

The Art Of Layout Testing With Galen Framework

Tests automáticos de interfaces definidos de forma declarativa. Me pregunto si el esfuerzo de especificar el diseño merece la pena. Imagino que sí en sitios web donde el diseño cambia poco y sin embargo crecen mucho, tipo Amazon.

Real-time dashboards considered harmful

La polémica de la semana, me ha encantado este artículo. Básicamente rompe el mito de la utilidad de los datos que muestran datos en tiempo real, pensados para un patrón preventivo en cuanto a la identificación del estado de un sistema, y apuesta como solución por el uso de alertas (las cuales fomentan un comportamiento reactivo en los usuarios).

Además pone una de mis más odiadas películas en cuanto a la poca usabilidad de la interfaz que imagina: Minority Report. Pero es que Tom Cruise es muy bueno produciendo estas cosas, en Oblivion volvió a hacerlo: mostró un Dashboard que era una TV más bien y que en el momento del drama bien no podía interactuarse con él (sólo podía contemplarse) bien había que hacer un esfuerzo físico para solucionar la urgencia.

Enlaces comentados #1

Aquí dejo una serie de enlaces interesantes que he leído estos días o tenía en mis marcadores.

Lo que se espera un estudiante de 1º de informática y lo que se va a encontrar en realidad

Contado desde la perspectiva de los estudiantes y profesores. Muy curiosos sus comentario cuando llegamos a la sección “No es carrera para mujeres… pero debería serlo”

Dynamically Inlining Critical CSS with Server-side JavaScript

Un buen artículo sobre optimización de CSS

Hugo

El CMS para diseñadores hipsters, aunque a mí no me convence del todo, prefiero el siguiente 😉

Meteor 1.3.3 released

Éste sí que es el framework Javascript más hipster que recomendaría a los diseñadores conocer si quieren meterse en el mundo del prototipado interactivo web.

Improve User Experience With Real-Time Features

Éste artículo me ha llamado la atención por una pequeña prueba de concepto que estoy haciendo implementando una app que recoge interacciones de usuario y las envía a valo.io. También me llamó la atención encontrarme con esto: http://blog.invisionapp.com/user-interactions-tool/ que no deja de ser un prototipo para visualizar interacciones de usuario.

Pixel Density, Demystified

Por si aún hay quién confunde resolución de pantalla con tamaño de pantalla. La densidad de píxel explicada de forma sencilla.

Why UX Designers Don’t Need More UX Design Tools

Ya está bien de seguir empecinados en aprender más y más herramientas, ésas no son las habilidades que nos harán mejores diseñadores de UX sino la capacidad de crear, de ver más allá, de entender el negocio y la tecnología.

CSS for People Who Hate CSS

Me he sentido reflejada, no porque odie el CSS sino porque me encantan los lenguajes con sentido, limpios, coherentes, que responden a la lógica y CSS es uno de tantos ejemplos.

No more UX Teams

Last 1st of April I gave a talk titled UX for Developers. Although I struggle with anything that sounds patronising with new insiders – UX is the same thing for everybody – I thought that approaching the User Experience in a developer fashion was an interesting topic.

Some days later, I’m still hesitating of any role demarcation of UX exclusively, and the thing that makes me doubt the most is what we refer as a UX Team.

What is a UX Team?

A UX Team, in theory, should be composed by all those people who have:

Do you know any other point? Please share 🙂

We are tribal beings and we love to have a feeling of belonging so we also impose to our pairs what means to be a UX person, so we exclude and we include based on our understanding of how we work. And here is where I start feeling an outsider.

If there’s a UX Team means that there’s a development team, meaning that UXers don’t develop. So we’re saying that in a SDLC we do everything except develop. Developing or coding? That’s the funny word game.

What it should be?

To be clear, you can be anything you want. Having said that I am as designer as developer – I’m actually and engineer but it’s worthless master degree. I don’t do coding, I do sketches. I design and develop, build, evaluate, conceptualise and create products which considers the person who will use it. I also make some research, and react on user testing. 

I believe UX is a set of disciplines which requires certain skills and design is one of them, coding too. If you care about the experience and you develop those skills you’re a UXer regardless what your role says. But not everyone with a UX title have same skills so assuming that a conversation between entitled UXers is gonna be more productive is as true as thinking that because I am Spanish I have to understand every single sentence of Spanish people.

Actually a skill which is common and a-must for any UX-oriented person is communication. And we do not make very well on communication all the time.

If I get stakeholders understand what I’m saying and I’m really capable of translating any of their words into a design problem I can analyse, then stakeholders are my tribe. If I don’t get it then I suck as a UXer. 

We’ve spent so much time looking for our people, our community, our pairs, we don’t want to feel alone or misunderstood, we don’t want to be undervalued, but if we keep saying that UX is such an important and holistic thing, it is driven the development, leading innovation and blah blah blah, then let’s be consequent, let’s include everybody, every role, and develop empathy. Do not use your team membership to justify what you are not, try to grow from inside to show off that UX is a shared responsibility and your super powers are additional points of strength for the product.

If you have read so far you deserve to discover this article: 

UX design: Manipulation or Communication

Thanks

UX for Developers

UX for Developers

Resumen de la charla ‘Mainstream UX’

Debe ser que estoy en un momento esencialista o cyborg, que últimamente disfruto de una forma más directa de la creación tecnológica a través de la filosofía.

Pensándolo bien creo que siempre ha sido así, es decir, si algo en común tiene creer que los computadores, sistemas, aplicaciones, productos digitales, etc. deben ser diseñados para que las personas que los usan tengan una buena experiencia así como haber estudiado los fundamentos matemáticos, físicos y lingüísticos para desarrollar herramientas de procesamiento automático inteligentes, es en mi opinión la creencia de que el binomio hombre-máquina es el único concepto que tiene sentido y es, en esencia, lo que debería centrar nuestra atención como diseñadores y desarrolladores de tecnología.

No sé muy bien por qué digo esto, porque lo que yo quería compartir es la presentación que hice el otro día en nuestro evento mensual ‘Yes We Tech’ y alguna de las ideas que traté de transmitir con más o menos éxito.

Nótese que el hilo conductor cinéfilo no es casual y me ayuda a contar la historia precisamente como a mí me gusta, con todo el drama posible.

‘Mainstream UX’

La hipótesis fundamental era sencilla: Si la UX (Experiencia de Usuario) no es mainstream, debería de serlo.

Para ello comencé con una escena clave en la historia del cine, escena que representa a trabajadores típicos saliendo de sus fábricas en un contexto de post-revolución industrial.

Esa gente ¿qué pensaría? ¿pensarían que las máquinas algún días les acabarían sustituyendo y por tanto haciéndoles prescindibles?

Con una visión más apocalíptica y lejos de creer que la mentalidad capitalista productiva persiguiera durante la revolución industrial únicamente traernos modernidad y progreso, la película de Metrópolis nos dibuja una escena mucho más franca sobre cuál es el papel del hombre en su relación con las máquinas: la esclavitud y el riesgo de su integridad física.

Si estas imágenes nos parecían exageradas, rescaté otra mucho más realista. La que muestra cómo en Manchester, ciudad pionera en cuanto a construcción de maquinaría industrial, en una fábrica textil de algodón cualquiera, el diseño de las máquinas obligaba a que una persona de ‘pequeño tamaño’ fuera la única capaz de pasar diez horas de jornada laboral asegurándose de que la producción no parara. En aquel contexto y en aquella sociedad esa personita era generalmente un niño o una niña.

Todo esto como excusa para hablar de un libro, o más bien de la creación de una disciplina, como la Ergonomía, que empezaba a preocuparse por invertir el modelo de creación industrial y comenzar a pensar más en cómo somos las personas que usaríamos esas máquinas.

Aunque hasta este punto todo nos pareciera ajeno nada más lejos, personajes como Alan Turing, las chicas de la ENIAC o Ada Lovelace de alguna forma contribuyeron a la Revolución de la Computación con una aspiración muy parecida: construyamos sistemas con una capacidad de procesamiento superior al de los humanos que nos ahorren esfuerzos de cálculo y de entendimiento de la información.

La modernidad y el progreso de nuevo al servicio de la cadencia productiva fueron arriesgando esta aspiración y a nuestras casas llegaron no sólo lo que serían herramientas de trabajo inútiles sino computadores destinados al uso personal poco usables.

Como ya pasara con la Ergonomía y aprovechando la herencia, la Usabilidad, el Diseño de Interacción y la Experiencia de Usuario se convierten en disciplinas impulsoras del desarrollo tecnológico al servicio de las personas (de sus expectativas, de sus necesidades, de sus objetivos y de su contexto).

A este punto de mi charla me di cuenta de que había gastado tanto tiempo en justificar por qué era importante que retomáramos esta perspectiva desde cualquiera de nuestros roles que a penas había facilitado entender cómo se lleva a cabo la tarea de diseñar y desarrollar productos que realmente estuvieran centrados en las personas.

Desde mi modesta experiencia, planteé cuatro preguntas esenciales:

  • ¿Para quién diseñamos?
  • ¿Qué diseñamos?
  • ¿Cómo diseñamos?
  • ¿Cómo podemos estar seguros?

Para quién diseñamos

Es probablemente la pregunta más fundamental de todas. Lejos de analizar a nuestros usuarios por sus características físicas o sociales, la respuesta debe partir de la búsqueda de patrones. No diseñamos para nosotros mismos (recuerda, you’re not the user) ni para nuestra madre (aunque parece que aún usamos a nuestras madres como modelo de la persona más tonta con la que validar la usabilidad de nuestros diseños, a parte del machismo inherente de quien usa este tipo de ejemplos, es igualmente erróneo pensar que todas las formas de ser un usuario ‘principiante’ son iguales).

No busquemos categorizar a nuestros usuarios sino agrupar, porque cuando se agrupa se hace un esfuerzo por:

  1. Entender qué tienen en común
  2. Entender qué tienen de diferente y
  3. Analizar el volumen y recurrencia de estas características

Por otra parte la Experiencia de Usuario no puede ser tan anonimizada, es decir, no basta con pensar en uno o varios grupos de usuarios genéricos y tratarlos como iguales, sino que es necesario buscar los rasgos de personalidad que tienen o queremos que tengan. Aquí es donde entra el juego de la construcción de un usuario inexistente al mismo tiempo que intentamos conocer a quien pensamos es nuestro usuario objetivo.

Un ejemplo, en mi opinión, muy oportuno de esta nueva personalidad es la que ha conseguido crear Instagram, red social que nos ha hecho creer que todos somos excelentes fotógrafos, que ha hecho fácil algo que mucha gente desconocía como el retoque fotográfico y que ha resuelto la carencia de la habilidad del encuadre rompiendo con el formato panorámico.

Qué diseñamos

Esta podría ser la pregunta más capciosa. ¿Diseñamos interfaces? ¿diseñamos experiencias? ¿modelos de negocio?

Mi único consejo (conste que mis consejos a mí aún me cuesta aplicármelos) es no dar nada por hecho. Cuando creemos que diseñamos un producto que es realmente un servicio, una interfaz que es realmente una pantalla, una web que es realmente un motor de procesamiento, pensar en estándares y patrones es difícil. ¡Pero no imposible!

Es importante identificar la esencia del modelo que estamos usando para poder crear sobre él una gramática familiar. Si es una web visible a través de un navegador, el historial de navegación y la posibilidad de que el usuario escape simplemente re-escribiendo una URL es algo que no sucederá de la misma forma que si usamos una aplicación desde nuestra muñeca aunque la tarea – por ejemplo, buscar una dirección – sea la misma. El paradigma que usemos tiene ciertos estándares (cambiantes sí, pero estándares al fin y al cabo) que ayudan al lenguaje de interacción.

Cómo diseñamos

Si nos atenemos a nuestras habilidades como diseñadores está claro que algunos diseñan mejor que otros. Pero esta pregunta no va en ese sentido.

Las herramientas, las metodologías, las prácticas y las costumbres no tienen tampoco por qué ser las mismas en cada proyecto o para cada interfaz. Durante mucho tiempo he detestado la mentalidad de hacerlo todo con Photoshop o buscar la herramienta de prototipado universal con la que podamos representar todo tipo de paradigmas e interacciones.

No dejemos que nuestra búsqueda de la especialización personal/profesional haga que equivoquemos la forma de comunicar el diseño.

Por otra parte, el propio proceso de búsqueda de soluciones acabará formando parte de la cultura de diseño y desarrollo y, por tanto, de la misma identidad de la empresa que detrás haya ofreciendo dichos diseños.

Cómo podemos estar seguros…

… de que lo hacemos es realmente usado de la forma más eficiente posible, de que el resultado de lo desarrollado es satisfactorio, de que la interacción es eficaz, de que la respuesta emocional es positiva y la creación es valorada por los usuarios. Cómo sabremos esto si no probamos, observamos, medimos y tomamos decisiones que vayan directamente a iterar y mejorar.

El llamado ROI (Return of Investment) puede ser condición necesaria pero no suficiente para garantizar que la experiencia de usuario es de calidad. Dentro de las diferentes formas de analizar esta necesidad, la implicación o contemplación de los propios usuarios en la validación del sistema que se está desarrollando es fundamental para eliminar la incertidumbre.


Finalmente quise hacer una nueva reflexión sobre la importancia de realizarse estas preguntas independientemente del punto evolutivo de la tecnología y recordarnos que detrás de cada interfaz siempre hay un humano.  Que la experiencia de usuario es tan fundamental como el propio hecho de formar parte de la comunidad de creadores de tecnología y que por esta razón debe ser mainstream, si no lo es ya.

Y por si todo esto nos pareciera una fumada siempre podemos volver a nuestras fábricas y vivir con la preocupación de no saber si algún día las máquinas habrán sustituido no sólo el músculo sino también el cerebro del hombre.  

Talleres y Charlas 2016 #YWT

yeswetech:

La comunidad de YWT ha comenzado el año con energía y muchas ganas de crecer y queremos que participes en ella.

Hemos creado este tablero para que lancéis vuestras propuestas de charlas (talks) o talleres (workshops) tanto si es algo que os gustaría que alguien los impartiera, como si os ofrecéis vosotras mismas a hacerlo.

Si queréis presentar vuestra propia propuesta sólo tenéis que escribidnos a través del enlace de ‘Participa’ de esta web o por correo electrónico a hola.yeswetech@gmail.com y explicarnos el tema sobre el que os gustaría hablar. 

Si echáis un vistazo al tablero veréis que hay algunas tarjetas sin asignar y que han sido propuestas por nuestras techies ¿os apuntáis a prepararlas?

   

Quiero dar una charla en YWT

La organización se pondrá en contacto con vosotras para planificarlo en la agenda cuando mejor y con el formato que mejor se adapte al contenido.

Me gustaría ver una charla sobre…

Si queréis que alguien se ofrezca para dar una charla, también podéis participar. Añadiremos una tarjeta

al tablero e intentaremos buscar a la persona ideal para dar la charla o taller.

Como sabéis, esta comunidad persigue potenciar la participación de la mujer en eventos relacionados con la tecnología por lo que priorizaremos siempre las charlas y talleres presentados por mujeres, si bien la asistencia a los mismos es abierta a todas y todos.

Quiero presentarme

Si eres un nuevo miembro de la comunidad y te gustaría presentarte y explicarnos tus motivaciones o proyectos, aprovecha el formato corto de 3′ para hacerlo. 


Mantente al día de los próximos eventos de la comunidad YWT a través de esta web o de nuestro meetup.

Preparando un año nuevo llenos de iniciativas…

Side Projects

I think everybody should have at least one side project.  

It forces you to think in the consequences of your decisions and assume the responsability of sucess or failure

It keeps you focused on looking for the perfection while you have to be aware of being pragmatic.

It helps to balance a good design and a good implementation

Side projects are personal, so you learn the importance of being proud of what you do.

Side projects are pressure-free, so you learn to enjoy of every step of the process. 

My side projects may never succeed but I won’t keep on working on them because they help me to love my job, to go on discovering new things, to settle down knowledge and to maintain the illusion.

Does this mean that your daily job doesn’t give you the same kind of experience?

Absolutely not, time and budget factors are key to keep it real. I strongly believe that productivity is necessary as a way of taking the most of your dedicated time at work. Besides, work it’s the perfect team environment to proof all what you get from your side projects. 

So yes, love what you do, do what you want, and collect what you get with proud and satisfaction.


Cinefilica is my side project, and now I have the chance to take it back and share it with a very good friend of mine who’ll help me to try a different idea over the same concept.