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.


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.


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



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.  


We are not problem solvers

Please, stop calling yourself a problem solver, with a bit of luck you might be able to facilitate others the understanding of what it seems to be a problem and, maybe, find one of the many ways to approach it.

If you ever see a person happy or satisfied when using the result of your team development, then you’ll be close to be called a User Experience <whatever role>


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.


El contexto del usuario

El hombre de la foto fue mi taxista hacia el Aeropuerto de Hong Kong. Le pedí si podía fotografiarle y me dejó con la condición de que él no saliera identificado.

Usaba hasta 5 teléfonos móviles, uno con peticiones entrantes de diversos hoteles, otro con las peticiones del radio taxi, otro con el resultado de la actividad de apuestas, otro para recibir llamadas con un listín de contactos y el otro no logré entenderlo.

Ninguno de ellos mostró un mapa en todo el recorrido. Si mostraron información sobre el tráfico, no lo sé. Pero ni un sólo mapa, ni un sólo sonido de voz humana explicando indicaciones de cómo dirigirse a un sitio. Sólo ‘beeps’, zumbidos y llamadas.

El taxista, un Toyota, y un montón de pantallas sobre el volante. ¿Qué diseñador/a podría imaginarse esto antes de empezar con el papel y el lápiz?