Defining a user research system

Knowing how your product is perceived and used is key for user experience designers. Even if you are not a UX researcher, you can do research to gain that knowledge. As soon as you start planning some of these research studies you’ll notice how difficult it could be to decide who do you want to talk to, what’s the purpose of the study or how to interpret discoveries.

However, there’s another challenge that comes with all of this that I consider equally important: how to manage all these findings coming from different sources to make them understandable and actionable for your team, as well as creating a system that encourages a culture of research.

The information gathered as a result of research sessions can come in many shapes and forms. I want to share with you how we have defined a very basic user research system to manage the results of conducted studies so you can create and work from the big picture to the specifics of an issue.

Picking up the right tools

I don’t think there’s a unique or perfect tool to do that, rather I’d consider what’s the process that fits best to your team and what they would consider something manageable. The user research system is your new product, and you should test its usability.

I know many people managers like to work with spreadsheets, this is not my case – not always – and not the case of my team of designers. We needed something visual, familiar, interactive, customisable and … user-friendly 🙂 We needed something easy to set up, to integrate into the other hundred work tasks we have to do every day and something that could really save us some time.

So we decided to use the tools that we use on a daily basis and get the most of them.

JIRA by Atlassian

The next-gen JIRA projects are meant to be used by small teams and they don’t require too much configuration. They are also great to link, move or transform any item into a development project, so you can track the progress from the day the problem was discovered to the day the solution was delivered.

JIRA’s unit of information is called ‘issue’. Issues can be related to each other (parent-child, cause-effect, etc.), and they are actionable, meaning that they can be at different status (to be done, in progress, etc.).

The next-get project gives you an easy interface to create a different type of issues and configure which fields they will have.

The taxonomy you want to use to organise the information can vary from team to team. In our case, all the insights were related to the same product and we tried to follow a simple approach to avoid being burnt into data and not capable of filling all the gaps. For this reason, we decided to create some minimum issue types:

  1. Usability Study: Any kind of research study we do to test or analyse user behaviour like user testing, surveys, competitors analysis, heuristics, etc.
  2. Usability Issue: Abnormal experiences that can cause confusion and are not aligned with standard and expected behaviour.
  3. Pain Point: Critical usability issues that have a high impact on the user experience and can cause frustration to our users.
  4. Insight: Things we have discovered about users during a study about their believes, values, behaviours or expectations.
  5. Idea: Potential action points or recommendations based on study insights.

Getting started: usability studies

A usability study can be any research method used to collect information about users like:

  • Surveys
  • Customer interviews
  • Heuristic evaluations
  • Data analytics
  • User Tests
  • Stakeholder feedback
  • Competitor analysis
  • etc.

Since each research method is done with a purpose, within a specific context and a challenge on the way it is planned and analysed, this information is included in the description of the study. This way, we can get better information about the issues related to it when visiting the findings after a while.

The information included on each usability study: Title (Summary), Description, Reporter, Start date, and Due date.

As a way to facilitate quick identification of the study when looking at all the issues we have created a naming convention ‘<study type – month/year>’.

Example of naming conventions of Usability studies.

Organising findings

Once we have created our first usability study, we can start adding issues to it. In our case, we are considering different types of items to organise all these findings.

Usability issues and pain points

A usability issue is any problem that can impact on a good experience of a user when interacting with the product. A pain point is similar to a usability issue but the consequence observed is the user frustration or incapability to actually interact as expected and desired.

Both are ranted by severity (low, moderate, high) and frequency (low, moderate, high). It’s debatable whether a highly severe and recurrent usability issue should be a pain point or not. To me, the main difference is that irrespectively a pain point has happened one or ten times, or whether it was critical from the perspective of how the product it should be designed, we have evidence that it’s yet not tolerable by users at all. It’s not what the expect, not what they want, not what they’d buy.

The information included on each usability issue: Title (Summary), Description, User type, User goal, User needs, Severity and Frequency.
The information included on each pain point: Title (Summary), Description, User type, User goal, User needs, Severity and Frequency.


Like usability studies, it’s important to agree to a convention on how usability issues and pain points are titled. In our case, we have agreed to phrase clear statements, for example:

  • (They) Want to see more information when visiting a product item
  • (They) Think it is too complex to create a post

Another convention would have been to use the typical scrum issue statement ‘As a user, I want to … so that I can …’. which gives more information about user intention and the user type.

Insights

Sometimes, when performing a user test or an interview we can discover things that are not actual problems, but give us information about how our users work or behave. We have called these findings ‘Insights’. Insights are also related to a specific user type while achieving a specific goal based on specific needs.

The information included in each insight: Title (Summary), Description, User type, User goal, User needs.

Issues and insights will contain as much information as possible, including quantitative information that will help stakeholders to value the impact of the finding.

Planning actions

As important as presenting the results of the study is to provide recommendations about what to do next. We will collect these recommendations using ‘Ideas’. Ideas can be related to one or many issues, and they’ll be actionable design recommendations.

Usually, ideas are created considering the severity and frequency of the issues they are intended to solve.

Ideas will be finally the seed of future user stories in design or development backlogs.

Conclusions

Although understanding users might be challening it doesn’t mean it has to be chaotic. Managing information from research can be done by any team, and it will help designers to be focused on what matters the most: the user experience.

Certainly, issues, insights or ideas don’t come out just based on the result of a concrete usability study, but after the formative analysis of several issues over time. We can create them at any point in time as soon as we discover it with no need for the usability study.

We can also create more layers to organise issues. For example, we have used the concept of ‘sprint’ to group items by area of experience. Things like user profile, notifications, creating <content_type>, receiving emails, etc. are examples of different types of product sections that might require a special analysis.

The good thing is that the way to categorise these issues doesn’t need to be limited by the tool but just planned according to the product characteristics. Having a simple process like this can facilitate to anyone to contribute with their knowledge and to gain visibility of the existing usability status of it.

Intentar ser mejores

Estamos más obsesionados con aparentar ser buenos que a veces nos olvidamos simplemente de intentar ser mejores. Pensándolo tiene cierto sentido, nuestra identidad moral y nuestra reputación son un valor que queremos preservar porque lo que piensan los demás de nosotros nos importa.

El problema surge cuando preferimos proyectar una imagen artifical sobre lo buenos que somos o nos creemos ser (de acuerdo a unos estándares) hasta tal punto que nos impide accionar los mecanismos para crecer: el ensayo y el error.

Me gustaría rescatar una historia que siempre me ha inspirado para explicar mejor esta idea.

Dick Fosbury
Dick Fosbury 1968 – Saltador de altura

Hace más de 60 años el atleta estadounidense Dick Fosbury revolució la técnica de salto de altura haciendo algo que nunca antes nadie había hecho: pasar por encima del listón de espaldas.

Hasta entonces, todos los saltadores buscaban batir sus marcas mediante la técnica rodillo ventral o a tijera, sin embargo, esta idea original le hizo ganar a Fosbury unos juegos olímpicos estableciendo un nuevo récord mundial en los 2m 24cm.

Fosbury, quien no se sentía cómodo afrontando el listón de frente y no terminaba de adaptarse a las técnicas clásicas, no sólo decidió romper con sus referentes, sino que tuvo que pasar meses y meses poniendo en práctica su nueva técnica y mejorándola totalmente en solitario soportando las mofas de sus compañeros de entrenamiento.

La mecánica era la misma, elevar la cadera lo máximo posible, pero el estilo era pura innovación.

El 1968 Fosbury demostró al mundo en una competición de máximo nivel que intentar ser bueno siguiendo los estándares no era suficiente para crecer y llegar a ser el mejor.

Hoy en día su estilo de salto es un referente y muchos atletas han batido impresionantes récords gracias a él (2m 45 cm masculino y 2m 09cm femenino).

Dick Fosbury siendo consciente de que su físico no era el más talentoso y de los frustrante que resultaba no alcanzar unos estándares de perfección cuestionables nos enseñó que para desarrollarse como buen deportista necesitaría tiempo y espacio para probar y equivocarse, para entrenar y perfeccionarse, para reconocer el fallo y aprender de él.

La creatividad nace de la angustia, como el día nace de la noche oscura… En tiempos de crisis la creatividad, supera el conocimiento.

Albert Einstein

En el terreno profesional nos encanta escuchar y suscribir los consejos de los nuevos coaches emocionales que nos alientan a adoptar un ‘afán de superación’ constante mediante la filosofía ‘maker’. No me parece mal seguir este heurístico para obtener conocimiento, sin embargo, sí creo que debemos darnos espacio y tiempo para ser conscientes de lo que hacemos y por qué lo hacemos. Hacer no es suficiente, en mi opinión debemos:

  1. Conocer nuestras capacidades y nuestro punto de inicio.
  2. Entender los principios básicos de la técnica actual.
  3. Crear alternativas disruptivas.
  4. Probar y fallar y volver a intentarlo.
  5. Probar y acertar y seguir practicando.

Post-humanismo y diseño

No todos podemos sostener, con un alto grado de seguridad, que hemos sido siempre humanos. – Rosi Braidotti “Lo Posthumano”

El concepto de humano, nacido en la Ilustración, nos da cierta tranquilidad. Ser humano es lo natural en nosotros, es nuestra característica fundamental como especie, nuestra identidad.

Sin embargo, en el contexto de las sociedades globalizadas y tecnológicamente dirigidas, esta identidad y sus relaciones con los demás se vuelve más compleja. Robots, prótesis, neurociencias, biogenética nos llevan a un mundo de tecnotranscendencia y ciberdrama.

Lo posthumano es, más allá de la cultura mainstream transhumanista de Silicon Valley, una crítica al androcentrismo humanista como primera medida de todas las cosas y una reflexión cultural cargada de entusiasmo sobre la relación entre naturaleza (el dato) y cultura (lo construido).

Los desarrollos científicos y tecnológicos borran esa línea categórica y se convierten en instrumentos políticos y productivos donde reconsiderar los principios fundamentales de nuestra interacción con otros agentes humanos y no humanos.

Desde situaciones perversas como la tecnología que nos permite maltratar a los animales, torturarlos o manipularlos para que nos resulten productivos, pasando por la brutalidad de las guerras a través de las tecnologías de la muerte, los valores humanistas se ponen en cuestión y lo posthumano busca reconsiderar en quién y qué nos estamos convirtiendo.

Entrevista en el CCCB a Rosi Braidotti

El posthumanismo no es ciencia ficción

Blade Runner, Black Mirror o la más reciente Years and Years son sólo unas cuántas producciones cinematográficas que dibujan distopías mostrando el lado más negativo y perverso de la tecnología y la sociedad que la acompaña.

Sin embargo, no podemos perder la oportunidad de dejar pasar otra revolución tecnológica sin mirar en las posibilidades que el devenir posthumano puede ofrecernos como ciudadanía y distanciarnos así de la corriente tóxica de pensamiento que justifica sistemáticamente que todo debe ser rentable a corto plazo para tener valor.

Feminismo, ecologismo, anti-colonialismo se entre cruzan en el planteamiento posthumanista como pruebas de un activismo por la reconquista de una identidad futura más inclusiva, sin caer en la falsa imposición de que la tecnología y la ciencia son “neutras” y, por tanto, masculinas y esto nos avoca a una catástrofe inexorable en la que no podemos intervenir.

¿Qué podemos hacer como diseñadoras y desarrolladoras de tecnología?

Para mí esta es la gran pregunta que llevo formulándome desde hace meses, desde la primera vez que oí hablar de este postulado filosófico que parece más un asunto urgente del presente, que una especulación futurista a la que no debemos atender.

Haakon Faste, en su disertación sobre los Factores Posthumanos, plantea una de las primeras consideraciones que forman parte del Diseño Centrado en el Posthumano: la relación interactiva entre personas y máquinas y su direccionalidad provoca que tengamos que eliminar la necesidad de “uso” y “control”.

El término “usuario” es un mito, los humanos no “usamos” la tecnología para “mejorar nuestra eficiencia”, por lo tanto no buscamos diseñar sistemas “usables” desde una perspectiva ávida centrada en la persona, como asegura el autor. Humanos y computadores se usan entre sí. La manida frase “el producto eres tú” no es más que una forma popular de describir la existencialidad de los productos tecnológicos en base a nuestra actividad y nuestra atención. Instagram, Mac, Tesla, etc. existen porque nos usan.

¿Debemos por tanto considerar la “inutilidad” como parte fundamental del diseño de productos posthumanos? La teoría que Faste propone se dirige a describir un marco metodológico en esa dirección con una fuerte influencia artística que resulta de lo más interesante.

Seminario sobre Diseño Centrado en el Posthumano

Reflexión final

No he leído lo suficiente, ni he estudiado filosofía, antropología o cualquier otro área de conocimiento humanista para saber dar una respuesta a este devenir. Ni si quiera creo saber de lo que hablo, tan solo resumo y troceo ideas capturadas que me hacen reflexionar de forma continua sobre el futuro con cierta ansiedad.

Una de las peores sensaciones en mi convicción activista, que no optimista, es la de conformarme con que todas las injusticias del presente son causadas por un problema en la educación de nuestra sociedad contemporánea. Si así fuera, podríamos abandonar toda posibilidad de cambio presente y centrarnos en la esperanza de que las futuras generaciones resolverán nuestros conflictos. Lo poco que alcanzo a entender sobre posthumanismo me devuelve a un necesario y constante estado de crítica al desarrollo de la tecnología de la cual nosotros sí somos responsables.

Desde el diseño de experiencias a cualquier otra disciplina que tome decisiones sobre cómo serán/son las máquinas y qué seremos/somos las personas con ellas, debemos seguir cuestionando la metodologías que nos llevan a razonar sobre un “sentido común” donde la racionalidad y la lógica se antepongan a la genialidad creativa y colectiva.

Tengo claro que no habrá más diseño “centrado” en sistemas o humanos, que el diseño especulativo no es diseño de futuros, que no hay productos mínimos que sean viables, pero tengo el problema de que no sé ni por dónde empezar para convenceros.

Not a single design process

We spend years and years exploring, trying and following guidelines about what’s right and wrong to do when “doing UX”. We look for the perfect process, the one that tells you: yes, you’re following a user-centred design methodology that will ensure the best user experience possible.

But let’s face it: there’s no one single process that helps you to solve any and every single problem, and not all designers can and must follow the same creativity path to build good solutions.

So what shall we do then? My suggestion, follow principles, not processes and get alignment, not agreement.

Always learning about users

In my experience, I’ve seen different designers working in a very different way, those who need to start playing around with high-fi prototypes to start questioning the problem, and those who need to start asking people around before moving a single pixel.

Research comes in different ways, and that’s good as long as we wonder who are our users, how do they behave, and what do they expect. We can look for the answers while speaking with them or while building a prototype. We can learn about them while testing a wireframe and while picking the ideal colour palette if you really consider their needs.

The key thing is to be open to make design decisions based on this information at any stage of the process. It shouldn’t be too late to use a piece of knowledge for the good of the product.

Use the tribe

Agile methodologies might be the golden egg or the most toxic ‘member’ of your team. Only very senior designers really know how to adapt the methodology to their own process and way-thinking, and how to be flexible enough to move forward at the development pace. However, the process doesn’t depend only on me as a designer, but me as part of a tribe.

We should use the tribe more to provide and receive feedback, to delegate and transform ideas, and to lead the design thinking process. We’re not always the best executing a design, but we can seed other’s people minds to generate better solutions.

Using the tribe is more than sitting on a room to agree on what to do and how to do it, but to facilitate the conversation around design to find an alignment of objectives. Designers, like other stakeholders, have their own principles and priorities and they should be respected, not simply transformed, that’s when alignment makes sense.

Diverge and Converge

Always learning about users and using the tribe are just two examples of how design processes can be deconstructed into principles. Whether you are redesigning a product or starting from scratch you know that there are some activities that are needed:

  1. Understanding users and their context of use.
  2. Modelling user requirements into something actionable.
  3. Creating usable and convenient solutions.
  4. Getting cool things done and evaluated against requirements.

It’s not about their sequence, but their value. When I design a product, I like to think that at any point in time we can apply any of those principles and get benefit from them, that any time is the right one to speak to a developer or to a user and get clarity about the solution or the problem.

So if you’re trying to define your perfect design process I’d suggest you wondering about how you believe it should be done and write down those principles first.

Diseñar con datos, más allá del A/B Testing

Resumen

Diseñar con datos parece sencillo: haces un test A/B y te quedas con la solución que más conversiones tenga ¿cierto? pero ¿somos conscientes de lo que nos dicen los datos? ¿cómo sabemos qué conviene evaluar? ¿qué hacemos si los resultados contradicen nuestras ideas originales?

¿Hay vida (y datos) más allá de los tests A/B? En esta charla me gustaría compartir algunas ideas y experiencias sobre cómo, cuándo, dónde y por qué podemos usar los datos a lo largo de un proceso de diseño para la Experiencia de Usuario, desde la investigación de usuarios (cuantitativa) hasta la toma de decisiones sobre un producto digital real.

Trataremos también de reflexionar (durante y después de la charla con un café) sobre cómo crear una cultura del diseño informado con datos, donde la experimentación y el desafío sean una constante.

Además, los datos están de moda, el diseño marca la moda, Netflix lo hace ¿qué puede salir mal?

Read more

Data-ink ratio: good design can be better

Data-ink ratio establishes that every pixel used to represent data must be non-redundant and non-erasable, meaning that if the ink is removed from the image, the graphic will lose the content. 

That Tufte’s principle can be understood very quickly with this example gif image:

Darkhorse Analytics

On this occasion, I’m going to take a risk and forcing me to find examples on Dribbble, a social network for designers where you can find outstanding visual design examples. 

The reason why is because it’s easy to see the fail on old and poor designed interfaces, but it’s harder to find the ‘room of improvement’ in those places which already excel.

Disclaimer: I’m not judging the quality and creativity of these designs (which is obvious and I envy), but just trying to do a conscious exercise of critique to identify improvements in the case those designs were meant to be made with the viewer’s understanding in mind.

Read more

6 examples of bad dashboard designs

Dashboards are used to present large amounts of information in a condensed and visual form. 

They are meant to be represented on a single screen, to make an efficient use of the space, avoid superfluous graphics and include actionable, meaningful and relevant data according to viewers objectives.

However, we can find some examples where dashboards display the information in the wrong way. These are some examples of bad designs that can make a nicely intentioned dashboards fail.

1. Tiny and spaced

Yet the dashboard is displayed in one single screen, the amount of white space between charts make it difficult to read as unique piece of information. Increasing font-size and adjusting proportions would make it more efficient.

Resultado de imagen de dashboard opensource
Pentaho Dashboard
Read more

Recursos para una intro a la UX

Este artículo está especialmente dedicado al alumnado del Máster Front-end Lemoncode, aunque creo que puede resultar útil a cualquier persona con perfil de desarrollo que quiera comenzar a practicar y saber más sobre la Experiencia de Usuario. 

Empiezo recordando un artículo que no pasa de moda: 14 libros de UX que pueden darte una base sólida teórica y conceptual sobre Diseño y Experiencia de Usuario.

Un recurso  online gratuito y tremendamente valioso es The Encyclopedia of Human-Computer Interaction.

Una vez tengamos alguna base teórica os comparto también recursos prácticos que cualquier perfil puede intentar utilizar en su día a día desde el momento cero.

Cómo hacer entrevistas

Steve Portigal es un referente en este ámbito, su libro Interviewing Users puede resultaros útil para empezar. Aunque si lo que queremos es sacar el máximo rendimiento, podéis seguir los consejos de este artículo:  3 better questions to ask in user interviews.

Read more

Opensouthcode: resultados de la encuesta y datos de la experiencia

task performance opensouthcode survey

El pasado 1 de Junio mi colega Miguel Torres y yo hicimos una presentación en el evento sobre software libre Opensouthcode y hablamos sobre cómo podíamos analizar la Experiencia de Usuario (UX) con Javascript (JS). Durante nuestra charla presentamos un modelo con el que tomar métricas automáticas de usabilidad para poder conocer mejor a las personas que interactúan con nuestros productos digitales construidos con tecnologías web.

Al final de la presentación hicimos una demostración de cómo podía aplicarse a un caso real y para ellos utilizamos como excusa una encuesta que habíamos lanzado semanas antes. La encuesta no serviría más que a la presentación, sin embargo, ya que un buen número de personas se molestaron en contestarla, es nuestro deber compartir la información que recogimos.

Es importante aclarar que la forma en la que almacenamos los datos fue un poco peculiar, y por peculiar me refiero a que usamos el mismo Google Analytics, un servicio en principio destinado a analítica web. En cualquier caso, aquí están los resultados.

Resultados de la encuesta

La encuesta, lanzada el 10 de mayo de 2018 y activa hasta la fecha ha recibido 77 respuestas, y se dividió en tres pasos:

  1. Preguntas descriptivas sobre la persona.
  2. Preguntas sobre la profesión.
  3. Preguntas sobre los intereses.

Sólo el segundo de ellos era opcional y podían saltárselo, pero en todos ellos, todos los campos eran obligatorios. Éste hecho ha podido afectar a algunos datos ya que para ciertos perfiles había preguntas irrelevantes, por ejemplo diseñadora/es que no utilizan o no tienen preferencia por ninguna base de datos en concreto. Read more

Test de usabilidad automático

Estamos ante un panorama donde el desarrollo de aplicaciones con tecnologías web está creciendo muy rápidamente y esto merece una atención especial. En concreto lo que respecta a la tradicional analítica web no parece salir de los modelos de aplicaciones como los e-commerce o redes sociales a la hora de ofrecer herramientas que permitan entender e interpretar ‘lo que está pasando’ desde una perspectiva de usuario. Plantearnos cómo podemos mejorar estas herramientas de analítica para entender cómo se comportan nuestros usuarios al mismo tiempo que capturamos datos globales sobre su experiencia y su percepción de usabilidad nos ayudará a tomar mejores decisiones de diseño.

En este artículo busco describir un modelo de automatización de los tests de usabilidad con usuarios como continuación del trabajo anterior ‘Measuring UX with your own tools’ con el que poder:

  1. Medir y analizar grandes cantidades de datos generados por los usuarios.
  2. Hacer del diseño un proceso experimental y cuantificable.

Partimos de que la Experiencia de Usuario abarca muchas más cosas que la interacción del usuario con el producto digital a través de su interfaz, pero que esta interacción condiciona su experiencia y es una parte fundamental de la misma. Dejando un lado la visión holísitica del término, la teoría de la actividad vendría a describir el framework en el que se basa este modelo de representación, análisis e interpretación, aunque no está limitado al mismo. Este trabajo también se inspira en la metodología HEART de Google como método para medir la UX a gran escala para aplicaciones web.

Read more