Building your own tools with existing software

I’m sure you’re sick to death to hear whether designers should learn to code or not.

To me, coding skills have let me create my own designer toolkit by reusing and extending current software tools. Have you ever imagine how cool would be to become your own user while developing a solution?

At the moment there are thousands of open-source apps available for anyone to improve them. Some of them do just basic things like To-Do lists apps and others are a bit more sophisticated like Chats.

I’m not even talking about libraries and that crazy need of knowing the whole universe of packages and extensions of a programming framework. I’m talking about already built-in solutions with a purpose, with an API, and with an easy-to-consume documentation.

This is an experiment that I love to make from time to time: just pick an existing tool, see the code, imagine a different purpose with the current interaction model, a different way of using the visual grammar and customise it to see how the UI paradigm will work for a different goal.

If you include yourself as the target user, as a designer no one better than you what you want and need so, you can go ahead and create something fantastic to make your life easier, funnier or more productive.

Designer, you have the power of imagination, the good habits of a well-stablished UX process, and a strong creativity and ability to conceptualise things that most people can hardly envision, you just need to know the keys to play with the code and cross the red line.

It is to me the funniest way to learn.

Soon I’ll share my latest experiment: buidling my own UX testing framework 😉

Optimismo sin reservas

No he triunfado. No importa. Recuerdo que cuando estudiaba, cuando entrenaba, cuando me preparaba para afrontar retos, lo que me hacía sentir capaz no era el miedo a no dar la talla, ni el ser consciente de las dificultades del proceso, sino el desafío del esfuerzo.

Soy una convencida de que las mejores cosas que te da la vida requieren esfuerzo. Por eso, cuando pienso en qué cosas desalientan a la gente para superarse a si mismos, para atreverse con una u otra carrera profesional o proyecto, para arriesgar el corazón en una batida no está el miedo al fracaso, sino la pasión misma por vivirlo.

No, quienes actuáis con condescendencia no tenéis razón, solamente erráis en lo más básico: nadie espera alimentar su motivación con las frustraciones de otro.

Dejad de dar consejos y empezad a aceptar que por los demás lo más sensato es construir colectivamente. O quedaos solos. 

Adiós a la competencia del incompetente, así como a la irresponsabilidad del responsable. A partir de ahora me limito a no dar consejos, a hacer lo que tiene sentido, a ofrecer un rato de conversación sobre cómo podemos dejar de preocuparnos por triunfar y empezar a sentirnos orgullosos.

Pasen y vean, empezamos desde abajo.

From UX to Product Design

You may have read the article published by Eric Eriksson explaining the meaning of Product Design from the perspective of other ux-related roles such as Interaction & UX Desginers, Animation Designers, User Researches, Data Analysts, Prototypers (I love this one) and Business Strategists.

He states that

Product Design is the whole process

I remember that when we started talking about UX, UX was also the whole process considering that a UX designer was meant to drive and be reponsible of it. What a huge ambition right?

Our mistake (and our reality) was thinking that the UX individual was alone in this process.

Now that we have assumed that there are a lot of specialiaties, including the UX Specialists, we need to go back to think who was the person that ensured that the whole process is driving the good solution. So for that leading or visionary role we need to talk about Product Designers.

For sure UX is not alone in the dark, but an important gear to create and deliver digital products. This means that Product Design intersects with Business & Marketing, with Quality Assurance & Sales, and still keep their feet in the ground during the implementation of the product to facilitate delivery.

While I write this I remember one of the most highlighted ideas during the last UX Spain conference, where senior UX experts reached the conclusion that in order to do an ejoyable, useful and usable product for users, UX Designers had to become Product Owners (PO).

Product Owner is a popoluar term in agile methodologies and is the person who’s meant to speak the customer voice as well as validate that the delivery is aligned with the requirements.

Problems that I see with the terminology of Product Owner is that, firstly, not in all scenarios Users are the same as Customers and even if they are, not all our customers behaves in the same way. So considering that one person is capable of represent Users requirements without practicing any User Research technique is hard to believe. Secondly, the ‘validation’ state can be done only if your requirements, definition of done and acceptance criteria are clearly stated before the development starts, and in order to do that you’d still need exploratory design, co-creation or any other analytical artefact that puts users needs and expectations in the center.

So yes, I share the conclusion of considering that UX has to become a PO, but then we need to re-define what Product Owner really means.

And here comes the third of my thoughts regarding the transition of User Experience experts toward Product-something: Strategy is all.

Process are good, keep people working efficiently through all the stages. Ownership if shared is even better, since everybody feels that everyone is an equal part of the end result and we all success or fail together.

But what really kills the old-fashion way of delivering software is Strategy. And the premise of many (if not all) UX speacilists is the assumption that a product designed to meet user goals and create a positive experience with it has to be part of any strategy to make it adopted, and so be sold.

Yes, we can sell with our sales guys, we can look smart because our technology is smart and let our customers think that they’re doing an smart purchase, but the long-term goal of creating and enduring relation between our users and our products has to be based on the path of the User Experience. There’s no better promise of quality that a good quality product delivered on time. Deliverying functionalities without considering how users will interact with them (macro interaction) is as risky as ignoring that the small details and developed components are not the high priority focus of the delivery (micro interactions).

At least this is what I think while I aspire to become a good Product Designer some day.

Sgd. A UX specialist apprentice.

If this make any sense it’s in my head, if you (dis)agree, you can blame on the comments of this post.

Always solving the same problem: data model vs mental model

Information design is one of the most interesting fields to me that relates with the User Experience. How users perceive and understand the information based on what we show them and how they interact with it, it is like trying to create a language that goes beyond the interface and the standards. It is challenging and, sometimes, uncertain.

However the other day I had a déja vu while one of my mates was sharing a research made on an data analysis use case. Suddenly I felt I’ve been solving the same problem of information design over the last three years.

We talked about how raw data becomes information, and how there should be another data that represents the meaning of that information, and how past events may affect to current indicators or not. We talked about the visualization of multiple charts were the only way to understand some concepts, and how users should decide the events and configuration to provide real meaning beyond the data values.

I’m not going to enter into specifics on that use case, but the problem that reminds me the same kind of question was the one that I worked for years: the Electronic Patient Record (EPR).

In an EPR there are some information which indicates current health status: vital signs. This can tell you if you’re alive, getting better or getting worse. It is also a clue to start investigating what made you feel bad.

That’s one level of information based on data collected directly from a person. Of course you can collect more data like a blood test or a urine test or similar.

Another level of information is just the history of every visit to your doctor. All of them with symptoms, diagnosis, and treatments. Those events could be related between them by episodes (let’s say a flu, a pregnancy, a surgery…) and, in a different level, related by the diagnosis of an illness (let’s say cancer, diabetes, etc.).

The problem you have is that you need to navigate information from different layers based on different levels of the data abstraction. And you want to find correlations, make differential analysis and causations at any level, because you don’t really know what’s the cause of the problem.

What I thought it was similar is that when we model the problem, we have to provide meaning to the data abstraction and that requires an understanding of the user mental model (In my case how doctors research on data).

Another leg of this problem is how users can interact with the data to find how it is related. We cannot solve everything with a static picture of the data.

Last, but not least, we needed to represent very clearly what is the data in a relevant present (24hours, 7 days,…) and what belongs to the history, and how history is explored and contrasted with present data.


Somehow I felt the problem was always the same, and the only thing that makes it different is the kind of person who typically interacts and uses the data. So the solution should start to understand his/her mental model and define the model of the data meaning based on them, instead of the defining the data model of the system that is meant to represent it.

Prueba de diseño en Cinefilica

Así de chulo me está quedando el nuevo diseño de Cinefílica, pero tengo mis dudas sobre si publicarlo. El layout responsivo funciona pero me está dando muchos quebraderos de cabeza para encajar ciertas cosas.

Quitarme de un plumazo la navegación es un decisión muy radical. Si bien podría confiar en la página de inicio como distribuidor de contenido y potenciar el buscador (y sus resultados) para darle al usuario todo lo que necesita explorar, me quito la posibilidad de extender en algún momento el sitio web a algo más que el catálogo.

Otra cosa que hago desaparecer es el pie, creo que debería incluirlo aunque muchísimo más discreto que lo que hay ahora. Eso sí, los géneros debería hacerlos más visibles en la página de inicio, a fin de cuentas, están recibiendo visitas.

No sé si acabaré publicando estos cambios, en cualquier caso aquí los comparto.

Semana #1 – Intro a la Ciencia de Datos

La Ciencia de Datos comienza, casi como cualquier ciencia, motivada por un deseo de curiosidad. En este caso preguntas que hacerle a los datos. 

Es posible que los datos no contengan la respuesta, pero el deseo de preguntar junto con el entendimiento de la naturaleza de los mismos nos puede ayudar a obtener respuestas y descubrimientos.

Los tipos de análisis de datos que se pueden hacer podrían clasificarse como

  • Descriptivo
  • Exploratorio
  • Inferencial
  • Predictivo
  • Casual
  • Mecanístico

Algo básico para cualquier persona que comience en este área es entender que hay que evitar caer en los siguientes errores

  1. Correlación no implica causalidad
  2. Sobreajuste: interpretar un análisis exploratorio como predictivo
  3. Análisis descriptivo que no se puede inferir
  4. Interpretar un análisis exploratorio como inferencial

Por otra parte hemos aprendido a preparar nuestro entorno de trabajo con R usando R-Studio y dejar nuestras cuentas de Github listas para empezar a trabajar.

Este primer curso está planificado en cuatro semanas pero la verdad es que ha resultado bastante fácil avanzar ya que queda todo en el ámbito introductorio. A la espera de que me evalúen el primer ejercicio me he apuntado al segundo curso de la especialización: R Programming (seguro que éste sí requiere de más tiempo).

Lecturas recomendas para el comienzo del curso

Curso especializado de Data Science en Coursera

Hoy comienzo el primero de los cursos dentro del Programa Especializado de Data Science que ofrece la Universidad Jhons Hopkins a través de la plataforma de formación Coursera.

Es un programa para principiantes que puede dar buena base sobre los conceptos, disciplinas y tecnologías que se usan cuando se quiere hacer de los datos información.

Considero fundamental entender y dominar las habilidades relacionadas con la manipulación de datos para poder modelar sistemas de información y, posteriormente, diseñar componentes visuales que representen conceptos inteligibles, interpretables e interactivos.

Así que voy a intentar con este programa ordenar todas las ideas con las que en el último año vengo trabajando como parte del equipo de Valo.

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.


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.