Defining personas for UX evaluations

After user roles, we define personas as prototypical users of a system for UX evaluations.

Defining personas for UX evaluations

(TL;DR: personas at UX manager)

A persona is a description of an imaginary person who is an archetypical user of the system, and who may be used as a reference or inspiration when designing interfaces. Therefore, once we have defined the user roles involved in our system for UX evaluations, we can create some personas to make them more real.

Since we selected usability experts and frontend developers (as occasional evaluators) as focal roles, we have defined two personas, one for each of them:

These are primary personas who would require a dedicated interface; we may define other secondary personas whose needs would be met by the same interfaces used by primary personas.

Here you have those two personas in PDF format:

Or better browse them online (as they might change in the future):

From UX heuristics to an application for evaluations: user roles

Using a compilation of UX heuristics as starting point, let's take the first step to create an application for evaluations: defining user roles.

From UX heuristics to an application for evaluations: user roles

(TL;DR: user roles at UX manager)

When we talk about usability heuristics, Nielsen always comes to mind; but they are not the only ones. At heuristics.uxmanager.net you have a compilation of usability heuristics, including some for specific cases like Single-Page Applications (SPA) or mobile, and even a set from a psychological point of view. All of them are also available as a spreadsheet so you can use them for your own evaluations.

Besides those heuristics, the website includes a collection of accessibility guidelines including WCAG 2.1, all of them also as spreadsheets. Although they are usually considered as different techniques, in practice both usability heuristic evaluations and accessibility evaluations are similar in essence (i.e., checking if an interface accomplishes a set of principles), and even the specialists that perform them are many times the same.

So we have a compilation of usability heuristics and accessibility guidelines, and even spreadsheets to use them for evaluations; what else can we do with them?

(more…)

UX developers, ¿una quimera?

Un perfil mixto como un 'UX developer' podría ser básico, por ejemplo, para gestionar un design system o mejorar la experiencia de los desarrolladores.

UX developers, ¿una quimera?

Hace ya algún tiempo escribía sobre la experiencia de tener un perfil mixto entre diseñador UX y desarrollador y cómo, a pesar de provocar cierta indefinición personal, podía aprovecharse para aplicar de manera cruzada buenas prácticas y evitar errores comunes de una disciplina en la otra. Podría decirse que se trataba de una quimera en su doble acepción, tanto en la de ser híbrido mitológico como en la de situación imaginaria (ya que parecía no ser un perfil que se demandara realmente en las organizaciones).

Por supuesto, estamos hablando de UX y de diseño de experiencia de usuario como proceso que incluye investigación de usuarios, prototipado, evaluación, etc., y no únicamente como la habilidad de “hacer pantallas bonitas”.

Pensaba que me encontraba en un territorio un tanto inexplorado, pero poco después me topé con el artículo ‘Why we have user experience developers at Shopify‘ en el que no sólo se habla de esos seres híbridos que llama UX developers, sino que se dan razones para contratarlos en tu empresa (como ellos hacen):

The UX and engineering teams are not a part of each other’s process. These teams struggle to speak the same language, and handover slows each team’s understanding, making it harder to challenge the other.

UX developers bridge this gap.

(more…)

La UX de los programadores: ni esnobismo ni masoquismo

Necesitamos mejorar la experiencia de los desarrolladores como usuarios. Y quien dice mejorar su UX dice crear herramientas más fáciles de usar.

“¿Qué necesidad hay de hacer que las herramientas de los desarrolladores sean más usables?”, podrán pensar algunos; “Al fin y al cabo, se supone que esos usuarios son expertos en entender y usar la tecnología, ¿no?”. Craso error.

Los psicólogos no dejan de insistir en que los recursos cognitivos son muy escasos (sí, incluso los de los miembros de esa especie que vive pegada a un teclado). Dicho de otro modo: entender un problema y tomar decisiones requiere un esfuerzo muy importante y usa recursos que se agotan rápidamente. Así que si consumimos esos recursos en un problema determinado, tendremos menos disponibles para otras tareas. (more…)

Un impostor entre dos aguas

Algunas cosas que podrían aprender diseñadores y desarrolladores, unos de otros.

Un impostor entre dos aguas

Soy un impostor por partida doble.

Si el síndrome del impostor hace que dudes de tu competencia profesional a pesar de la experiencia o los logros que acumules, yo tengo el dudoso mérito de poder ser un fraude en, al menos, dos disciplinas: el diseño de interfaces (vamos a llamarlo así por ahora) y el desarrollo de software.

Me cuesta considerarme un diseñador porque, a pesar de tener un máster en diseño de interfaces cuyo trabajo final fue una herramienta de soporte al diseño, publicar algún artículo sobre el tema o haber desarrollado varios proyectos de prototipado y evaluación, no me emociono con los diagramas de UX, ni creo que el design thinking sea la solución a todos los problemas de la humanidad, ni considero que cosas como el diseño colaborativo sean tan positivas, ni tengo una obsesión compulsiva hacia los post-its.

Aunque tampoco debo de ser un desarrollador como Dios manda porque no soy un enamorado de la línea de comandos, ni proclamo a gritos lo maravilloso que es Git, y supongo que voy camino de la ceguera porque no he memorizado la combinación de teclas para poner cualquier editor con el fondo oscuro. Y eso que, cuando peina canas, uno ya tiene en la mochila casi de todo: desde el diseño de modelos de datos, SQL y stored procedures, hasta algunas experiencias con los últimos frameworks JavaScript, pasando por Java, .NET o PHP.

Pero… veamos el lado positivo: tener un pie a cada lado de la frontera hace que veas las cosas con cierta perspectiva, que puedas comparar hábitos y maneras de trabajar, e incluso que puedas proponer cómo unos y otros pueden beneficiarse mutuamente de buenas prácticas y aprender de errores ajenos (que siempre es más práctico que hacerlo de los propios).

(more…)

Experiencia de usuario (UX) en sitios de viajes

Algunos problemas comunes y recomendaciones para mejorar la experiencia de los usuarios de sitios web de viajes y vacaciones.

User Experience (UX) in travel sites, in English

Buscando un viajeHay temporadas en las que parece que no se puede poner la TV sin que aparezca anunciado algún sitio web sobre viajes. Además, últimamente se insiste especialmente en la facilidad de uso, y es lógico: con tanta oferta, que los usuarios consigan sus objetivos de manera sencilla puede ser un factor determinante a la hora de elegir uno u otro. Pero entonces, ¿qué factores hay que tener en cuenta a la hora de conseguir una buena experiencia?

Los sitios web de viajes no son una excepción a la regla de que no hay trucos mágicos a la hora de conseguir una buena experiencia. Los resultados se consiguen aplicando las técnicas habituales de usabilidad y UX, siguiendo estándares y buenas reglas, desarrollando múltiples alternativas y, sobre todo, conociendo bien a los usuarios, testeando y midiendo.

Aún así, sí que podemos identificar aspectos que merecen especial atención en este tipo de sitios web. A continuación tenéis algunos de ellos. (more…)

forUSE: usage-centered design (recovered)

Some articles about Usage-Centered Design by Constantine & Lockwood, recovered from their former forUSE website.

The usage-centered design approach to UX design (as defined by Constantine & Lockwood) has been always a reference to me. Their articles describe practical well-defined techniques which I think can (and should) be included in development processes, and my humble opinion is that it deserves more attention than it gets.

Usage-centered design itself has been viewed as providing already established and effective methods for putting activity-centered design into practice and for overcoming some of the stated shortcomings of human-centered design (Norman, 2006).

Actually, I used their descriptions of techniques for Personas, User Roles and (Abstract) Use Cases as the basis for their implementation into UCDmanager. One of the main reasons for this choice is that they set the basis for a design methodology which includes different interrelated techniques, instead of the toolbox of heterogeneous independent methods we usually have.

Sadly, it seems that their forUSE website is no longer active (although it still can be accessed through the Internet Archive’s Wayback Machine). That’s why I’m recovering here some of their articles. (more…)

Y tu web, ¿es de chocolate o de fruta?

Un experimento psicológico nos ayuda a entender por qué es tan importante que nuestras interfaces sean sencillas y "no hagan pensar" al usuario.

Ocurre a veces. Después de estudiar en detalle una aplicación o un sitio web para entender bien cómo funciona y cuál es su propósito, pasas a proponer un prototipo o un rediseño de las páginas o pantallas con el loable objetivo de que sea más inteligible y fácil de usar para sus usuarios. Y entonces, alguien (habitualmente responsable del producto) dice algo parecido a esto:

  • “Bueno… Tampoco hace falta que sea tan sencillo”.
  • “Nuestros usuarios no son tontos; ya saben algo del tema”.
  • “Es que hacen falta unos conocimientos mínimos para usar esto”.
  • “No pretendemos que cualquiera pueda usar nuestro producto”.

Ante lo cual tú, que eres el “experto” en estas cosas, puedes reaccionar de dos modos: o te agarras a tu autoridad y a la máxima de hacer las cosas lo más sencillas posibles, e intentas que se tengan en cuenta tus sugerencias; o bien sufres una crisis de fe y te preguntas si realmente es necesario hacerlo todo tan sencillo, o hasta dónde tenemos que llevar aquello de “No me hagas pensar” del libro de Steve Krug.

Pues bien: en esos momentos de duda existencial viene al rescate un experimento realizado a finales de los 90 por los psicólogos de la Universidad de Iowa, Baba Shiv y Alexander Fedorikhin. (more…)

El botón de los 300 millones de dólares, en Palma

Un cambio en un formulario web hizo ganar 300M$ a una empresa; este jueves vemos cómo.

Mañana jueves, 31 de octubre, voy a dar una pequeña charla de introducción a la UX (User eXperience) / usabilidad en Palma, organizada por Betabeers y con la colaboración de PalmaActiva.

El botón de los 300 millones de dólares.
Qué es la usabilidad/UX, y por qué debo preocuparme por ella

La charla es gratuita y en el momento de escribir esto todavía hay plazas. No se necesitan conocimientos técnicos previos, y yo creo que puede resultar interesante para cualquiera que tenga relación con la tecnología y sus usuarios: desarrolladores, jefes de proyecto, responsables de producto, o simplemente alguien que tiene una web.

Y por si fuera poco, después compartiremos una cervecita. 🙂

‘We are not good at designing’ (or why users are black swans)

This is one of the conclusions of the author of "The Black Swan" that may be also applied to the design of interfaces.

Listen Nassim Taleb in this interview (minute 4) claiming that humans are bad designers:

In his most popular book, “The Black Swan” (nothing to do with the movie), Taleb explains that many disciplines allegedly scientific like sociology, meteorology, politics and especially economics, are so complex and are so hugely affected by single events impossible to foresee (“black swans”), that making valid predictions is useless in most cases. Worse still, we are unaware of how bad we are making predictions.

Obviously, Taleb is not talking specifically about interface design, but it’s inevitable to come to the same conclusion because it’s also true that we are not good at designing interfaces. That’s why every approach to User-Centered Design is iterative: we know we are not going to find a suitable solution at first, so we keep trying and refining until we reach a valid design (because “we are good at discovering things”).

And what are our black swans? Users: it’s impossible to foresee how users are going to react in front of an interface (anyone who has performed or watched a usability user test has realized).

(more…)