Cómo adoptar un proceso de diseño centrado en el usuario en equipos ágiles

Es bastante común en las empresas de desarrollo tener equipos enteros trabajando mediante metodologías ágiles mucho antes de incorporar ningún rol especializado en Experiencia de Usuario. Incluso cuando cuentan con Diseñadores Gráficos, los referentes clásicos en prácticas como Scrum o Kanban no son muy explícitos en cómo o cuándo deben participar dichos roles durante el proceso. Cuando estos equipos necesitan de una vez por todas tomar una estrategia donde el producto que desarrollan sí tenga en cuenta al usuario para el que está destinado surgen las preguntas: cómo lo hacemos.

Diseñadores de …

Hace unos años cuando preguntaba a los desarrolladores qué esperaban de mí como diseñadora respondían algo así:

Espero que los diseñadores me entreguen un diseño de las pantallas y los flujos donde quede claro cómo debe comportarse la aplicación. Todo esto lo espero antes de empezar a trabajar en una User Story.

Básicamente proponían que el lugar de un diseñador era el de crear especificaciones (las interfaces de usuario vendrían a sustituir los diagramas de casos de uso, de flujo y modelado de negocio) siempre desde el lado del producto (ya que durante el desarrollo ni se nos ve ni se nos espera).

Evidentemente hoy en día no se concibe que un desarrollador sea ajeno al qué debe tener un producto al igual que no es realista que un diseñador no participe en el cómo debe funcionar. Sin embargo, las fórmulas para combinar a estos roles tan especializados dentro del flujo de trabajo ágil no resultan aún claras y, peor aún, generan la sensación de que aún existe más carga de trabajo.

La metodología como producto

Cuando se empieza a poner en práctica algo que hasta entonces no se había hecho o no había dado resultado tenemos que tener en cuenta que pueden llegar fricciones: hay que balancear la cantidad de cosas nuevas que se tienen que adoptar, lo bien o mal que nos las llevamos a la práctica y/o lo útil que resultan para el producto o el equipo.

Si consideramos la metodología de diseño centrado en el usuario como un producto, el equipo serían nuestros usuarios, por lo tanto la ‘percepción’ que tengan es tan importante como la propia eficacia y eficiencia de la metodología.

A continuación expongo algunas ideas sobre cómo enfocar ciertas actividades típicas de metodologías de trabajo como Kanban o Scrum para incorporar prácticas de análisis, diseño y validación para el desarrollo de productos con una mejor Experiencia de Usuario.

User Stories

La idea de las user stories o historias de usuario en desarrollo es muy sencilla, se han usado durante muchos años en la industria, aunque no fue hasta los años 90 que comenzó a recomendarse el uso de una plantilla en la que no sólo se contaba la historia desde la perspectiva del usuario, sino que que se añadía cierto contexto e intencionalidad. La plantilla más sencilla es la siguiente:

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Las historias de usuario son una oportunidad para comenzar la conversación con el equipo de desarrollo y de producto incluyendo la información que hemos obtenido en nuestra investigación.

Type of user (Persona). No hablaremos solamente de tipos de usuarios, sino que podremos ser más específicos y mencionar a la Persona protagonista (la cual lleva consigo una información de valor que podría considerarse parte de los requisitos no funcionales de la plataforma).

Do something (Motivation). Cada historia de usuario debería estar enfocada a resolver un problema concreto, éste problema vendría especificado por la necesidad de un usuario a realizar una actividad.

Get some benefit (Expected outcome). Las actividades y necesidades que los usuarios quieren poder hacer con nuestra solución buscan alcanzar un objetivo concreto, incluirlo como parte de la historia nos ayudará a entender el propósito e incluso a identificar escenarios de test.

Backlog

El backlog es la herramienta que se utilizar para gestionar las User Stories que definen el producto digital, aunque también se incluyen otros conceptos como Epics (User Story de gran tamaño) y Themes (conjunto de epics). Organizar un y priorizarlo no es una tarea menor, aunque se simplifica si mantenemos claro los objetivos y creamos ciertas convenciones.

  1. Epics y Themes deben servir para crear una visión de producto a alto nivel
  2. Las User Sotries deben facilitar la ejecución y entrega del producto

A mí me gusta trabajar con prototipos de baja fidelidad para el primer objetivo y refinar con prototipos de alta fidelidad para el segundo. Es importante considerar para este segundo caso la velocidad a la que se tienen que tomar ciertas decisiones, la cual es posible alcanzar si se han creado recursos como guías de estilo y componentes de la Interfaz de Usuario (UI en sus siglas en inglés).

Desde el aspecto de la validación también se puede trabajar a diferentes niveles de acuerdo con estos objetivos.

Para el objetivo primero definiremos los escenarios que pueden ser más interesantes testear y los KPIs que nos indicarán el resultado y para el segundo la métrica que ayudará a calcular dichos KPIs.

Hay equipos que trabajan con dos backlogs (product backlog y sprint backlog) diferentes para cada uno de los objetivos. Esto tiene como ventaja la libertad para estructurar ambos pipelines como resulten más cómodos, pero carga de mayor trabajo a la hora de priorizar y planificar. Trabajar en un solo backlog requiere sin embargo de más consenso en la convención que quiera tomarse y cuando se trata de incorporar nuevas actividades se generará aún más fricción.

Qué podemos esperar

Cuando las cosas van bien…

  • el equipo entiende el problema y forma parte de la definición de la solución óptima
  • el equipo tiene claro los requerimientos de la solución
  • el equipo sabe lo que tiene que hacer en cada momento

Cuando las cosas van mal…

  • el equipo deja cosas sin terminar
  • el equipo deja de comunicar cosas importantes
  • el equipo hace tareas sin entender de dónde viene la necesidad
  • el equipo no va alineado

Una mánager me dijo hace tiempo algo que me encantó

No hace falta estar de acuerdo sino estar alineados.

Cuando se trata de definir procesos, podemos estar más o menos convencidos de que van a funcionar, pero si el equipo decide conjuntamente seguirlo cualquier persona que se desalinee hará que el resto no funcione de forma óptima.

La mejor estrategia es ir incorporando nuevas técnicas poco a poco, que el equipo se acostumbre a usar ciertos términos e identificar la necesidad de hacer una mejor investigación, mejor diseño y mejor testing y por lo tanto de seguir incluyendo más y mejores técnicas de diseño centrado en el usuario.

Conclusiones

Las técnicas de diseño centrado en el usuario no deben ser incompatibles con las metodologías ágiles, la forma en la que definimos el problema y describimos la solución pueden ayudar a mantener un enfoque más dirigido hacia las personas que usan el software y a conducirnos hacia soluciones que las tengan más en cuenta. Tanto lo que hacemos en diseño como la forma en lo que lo hacemos es parte de la comunicación y el proceso de entrega, así como de la creación e identificación de necesidades del producto.

La siguiente pregunta que me formulo es ¿estamos dispuestos a asumir el esfuerzo?

Tiene sentido definir un término como la Experiencia de Usuario

La Experiencia de Usuario (UX) es una disciplina holística, lo es todo, es el alfa y el omega, el principio y el fin, el caos y el orden y si le preguntas a un diseñador de UX te dirá que “cualquier cosa que hagas tú que no haya hecho él NO es UX”. Somos así.

UX es un término difícil de definir y, sin embargo, después de tantos años, me sigo encontrando con el mismo problema cuando tengo que explicarlo en algún taller o charla de introducción. Mejor o peor, esta es la forma en la que intento enfocar la definición del término: contando la historia sobre cómo llegué a valorar lo que significa ‘Experiencia de Usuario’.

Cómo llegué a entender el valor de la UX

En todo este tiempo de profesión creo que no llegué a entender bien la importancia de la UX hasta un día que, visitando el museo de Ciencia e Industria de Mánchester, muy recomendable por cierto, me encontré con una historia muy curiosa que me fascinó y está relacionada con la siguiente ilustración la cual representa un ‘día cualquiera’ en una fábrica algodonera.

 

IndustrialRevolutionManchester
Entre 1780 y 1820. La revolución de las máquinas

Ésta es una ilustración de cómo eran las máquinas entonces, el detalle de esta imagen está en esa niña pequeña. La razón por la que esa niña (al igual que otros niños de la época) trabajaba como un adulto era, entre otras cosas, porque las máquinas algodoneras estaban diseñadas de tal forma que obligaban para su funcionamiento que una persona, generalmente un niño, de no más de un metro de altura se moviera bajo el tejal para recoger el sobrante textil, evitar que la máquina se atrancara y mantener la cadencia de producción, incluso a riesgo de su propia salud física.

La verdad es que hasta que no vi estas imágenes no entendí el impacto tan grande y tan relevante que podía tener algo mal diseñado, mal ‘planteado’. Porque eso es lo que era, estas máquinas estaban simplemente pensadas para producir, para funcionar en un contexto mercantilista, pero no para que las manipulase un ser humano (adulto a ser posible) durante diez horas al día.

Todo esto sucede en el contexto de la Primera Revolución Industrial, época que incrustó en nuestra sociedad la creencia de que mediante la transformación tecnológica se perpetuaría la filosofía de la innovación, la modernidad y el progreso. ¿Os suena este pensamiento?

Mientras tanto el recién nacido mundo del cine comenzaba a reflejar cómo evolucionaría esta hasta la exageración proyectando distopías como la que veíamos en Metrópolis. Nada más lejos de la realidad ¿no?

Volviendo a la ciencia no ficción.

La ergonomía se ocupó entonces, y menos mal, de practicar un diseño que se adaptara a nuestras características físicas, psicológicas y ambientales. Personas, máquinas y contexto como principios fundamentales para el desarrollo de la tecnología.

Intencionada o no, las consecuencias de un buen diseño tendrían un enorme e irremediable impacto en nuestra sociedad como hemos visto. Tal y como vemos actualmente.

Seguimos con la historia y no tuvimos que esperar mucho para Revolución de la Computación. Personajes como Ada Lovelace o Alan Turing contribuyeron al surgimiento de una era histórica única, una era en la que las máquinas serían cada vez más inteligentes y sustituirán, quizá, el esfuerzo intelectual, de cálculo y procesamiento de información. La Informática como rama de estudios de todas estas ideas, nada que no sepáis.

eniac
Dos mujeres programando la ENIAC (1945-47) – US Army

Y desde este contexto, el equivalente histórico: la Interacción Persona-Ordenador, como área de conocimiento que estudia el diseño de estas ‘máquinas inteligentes’ para construirlas de acuerdo a las características de las personas que estaban destinados a usarlos.

Digamos que uno, quizá el primero, de los pasados de la Experiencia de Usuario reside desde el aspecto técnico, pero no es el único. César Astudillo lo cuenta muy bien en su artículo ‘¿Para quién luchamos?’. En el campo UX conviven ‘linajes distintos’. Como hemos visto los profesionales del diseño, pero también de las ciencias humanas, psicología, sociología, gente de negocio, de márketing y comunicación.

Pero ¿qué tenemos en común? Que todos desde nuestra forma de ejercer esta profesión vemos en la Experiencia de Usuario un espíritu de cambio. La UX surge como fenómeno transformador de la tecnología de trascendencia humanista.

La UX ya ha transformado el concepto de Usabilidad. No se limita por tanto únicamente a analizar la facilidad de uso (eficacia, eficiencia y satisfacción) de las personas que utilizan productos interactivos sino que alude también a un factor emocional del usuario. No se limita a calificar los productos de usables o útiles, sino que abarca las vivencias y las relaciones de las personas con dichos productos a lo largo del tiempo.

Como dice Nate Bolt, autor del libro Remote Research:

You don’t come up with an iPod just by making a Walkman really easy to use.

En este sentido el contexto emocional se suma al contexto de uso como factor determinante de la posible experiencia de usuario. En dicho contexto, se tienen en cuenta tanto sentimientos pre-asociados, como el actual estado de ánimo y emociones evocadas por el producto y afecta entre otras cosas a la capacidad de aprendizaje, atención, memorización, rendimiento y percepción de utilidad.

El término de UX según Donald Norman

En cualquier caso, si todo esto no ha terminado de convencerte mi sugerencia es leer y escuchar a los más grandes en este campo.

 

Diseño persuasivo, diseño alienante

Habrás escuchado una y mil veces que el diseño de interacción tiene que ser persuasivo, convincente, emocionante, tiene que motivar e influir en nuestra decisiones a la hora de interactuar con un producto o servicio.

It’s about understanding the emotions that influence people’s behavior and decision-making, and then acting on that information to design compelling user interactions

El objetivo del diseño de interacción persuasivo es modificar el comportamiento del usuario a través de las emociones usando teorías de la psicología y la sociología.

Desde luego hay otros principios básicos en diseño de interacción como los conceptuales y los de interfaz, pero en lo que concierne a la relación persona-máquina, persuadir es la clave. Persuadir, repito, para modificar el comportamiento.

La motivación de la persuasión es uno más de los límites que debemos saber identificar para no contribuir a la creación de una cultura de consumidores interactivos alienados. De esos que se convierten en el producto cuando no pagan por él. De esos cuyo tiempo de calidad lo pasan enganchados a la tecnología por puro entretenimiento.

¿Quiero decir que el entretenimiento es malo? En absoluto, lo que quiero decir es que el diseño de experiencias que persiguen la alienación de los usuarios es éticamente reprobable si se quieren seguir ciertos valores. Los que nos propone el libro About Face (una biblia para mí desde hace diez años que sigue teniendo conceptos imprescindibles) me parecen un buen punto de partida:

  • Ethical (considerate, helpful)
    • Do no harm
    • Improve human situations
  • Purposeful (useful, usable)
    • Help users achieve their goals and aspirations
    • Accommodate user contexts and capacities
  • Pragmatic (viable, feasible)
    • Help commissioning organizations achieve their goals
    • Accommodate business and technical requirements
  • Elegant (efficient, artful, affective)
    • Represent the simplest complete solution
    • Possess internal (self-revealing, understandable) coherence
    • Appropriately accommodate and stimulate cognition and emotion

Sin embargo nadie dice que esto sea fácil, más si cabe cuando las experiencias no se pueden diseñar ni construir, si acaso facilitar. Es ahora, después del uso y del tiempo cuando hemos podido identificar las consecuencias de ciertos diseños, por ejemplo, del famoso botón ‘like’. Una lectura de las experiencias de usuario generadas tras ese diseño llevada quizá al extremo la pudimos ver en el capítulo ‘Caída en picado’ de Black Mirror, donde la reputación dependen totalmente de cómo los demás te valoren y ahí está la tecnología para ‘ponerlo fácil’.

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 😉

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

Thanks

UX for Developers

UX for Developers