Cabría pensar que, al haber tanta escasez, los sueldos de los desarrolladores deberían estar por las nubes, y que habría peleas por entrar a estudiar ingenierías. Pero no parece que la situación sea exactamente esa.

[…] como la demanda laboral viene mayoritariamente de la consultoría, prolifera la formación privada que promete enseñar JavaScript en un ‘bootcamp’ de pocas semanas, aunque lo que en realidad enseña es a llenar el perfil de LinkedIn de los ‘palabros’ que buscan los ‘headhunters’. Un sector roto siempre se llena de buitres.

Eduardo Manchón en Programar es de pobres: por qué el mundo del ‘software’ está roto en España

Si fuera una película española de los 90, a esta situación la podríamos titular “¿Por qué lo llaman encontrar talento cuando quieren decir encontrar a alguien que conozca en profundidad todas y cada una de las tecnologías que uso y tenga varios años de experiencia con ellas, pero que esté dispuesto a no cobrar demasiado?“.

Cierto: como título queda un poco largo. Y como película muchos tendríamos una sensación de “esta ya la he visto”, a tenor de la respuesta que tuvo este hilo en Twitter:

He tenido acceso (no me preguntéis cómo) a los contactos que ha tenido MESSI con un club que pretende ficharle. Curiosamente, ese club ha contratado a un RECRUITER ESPECIALIZADO EN IT, así que la conversación que ha tenido el recruiter con Messi ha sido tal que así:

— jordisan (aká RamSys) (@jordisan) April 14, 2021

Y es que muchos de los que hemos tenido la desgracia de vernos, en algún momento, buscando trabajo en el desarrollo de software tenemos la misma opinión sobre la mayoría de las ofertas: los requisitos (y las entrevistas) de las ofertas de trabajo se parecen más a un checklist de tecnologías que a la búsqueda de un buen desarrollador (cuando un buen desarrollador probablemente aprenderá esas tecnologías en unas semanas y las dominará en pocos meses).

Seamos claros: que no encuentres a alguien con 5 años de experiencia en Angular (y que además domine HTML, CSS, React, Vue.js, typescript, webpack, npm, docker, kubernetes, git, …) por 24.000€ al año no es un problema de falta de talento.

Volviendo al símil deportivo, muchas empresas no buscan formar jugadores de cantera, sino hacerse con grandes estrellas que hayan ganado ya muchos títulos, con la esperanza de que sigan ganándolos. Pero esas estrellas no abundan. Y menos si no estás dispuesto a pagarles por lo que se supone que valen.

Batallitas personales

No voy a dar la lista de mis cuitas laborales, porque no serán muy diferentes de las que tengan muchos en el mundillo del software. Tampoco sé decir si tengo talento o no, porque con la experiencia uno acaba acumulando muchas más dudas que certezas. Pero sí os voy a dar un par de ejemplos de hace ya bastantes años:

• Mi primer trabajo al salir de la universidad (el siglo pasado, literalmente) fue como becario (y luego con contrato indefinido) en una caja de ahorros. Por supuesto, al entrar no tenía ni experiencia ni conocimiento de los procesos o tecnologías que allí se usaban, pero eso se le presupone de un becario, ¿no? Como todos, acabé aprendiendo cómo y con qué se trabajaba allí (alguien que ha terminado una carrera debe tener esa capacidad). Por cierto, era un sitio donde se gestionaba mucho dinero de mucha gente. Poca broma.
• Varios años después, harto de no encontrar un puesto en Mallorca, terminé trabajando desde casa para una empresa extranjera. Al empezar tampoco tenía una gran conocimiento en las tecnologías concretas que allí se utilizaban, pero eso no fue impedimento para ellos porque sí tenía ya experiencia con diferentes plataformas. Sin entrar en detalles, durante los 4 años que estuve tuve que rechazar (por motivos personales) una oferta de trabajo presencial que, para los cotillas, digamos que tenía unas condiciones bastante por encima de lo que se encuentra por estos lares.

No detallaría estas anécdotas personales si no fuera porque tengo la sensación de que esas barreras de entrada en forma de tecnologías concretísimas que se ponen a la hora de contratar a un desarrollador han ido a peor en los últimos años. Y que, además, son cada vez menos comprensibles en un mundo, como el de la tecnología, que cambia en cuestión de pocos años (cuando no meses).

— Para este puesto de frontend necesitamos que domines HTML, CSS, JS, TypeScript, React, Vue.js, Angular, WebPack, Node, Docker, MongoDB, Kafka, Git, Kubernetes, …
— Sin problema. También sé Python, Kobra Kai, Aikido y Nesquick++.
— ¿Estás de broma?
— No haber empezado tú.

— jordisan (aká RamSys) (@jordisan) March 21, 2021

Es muy difícil todo esto

Encontrar e identificar el talento es muy complicado. Mucho. Muchísimo. Deberíamos asumir que no es algo que se consiga en una entrevista de una hora o revisando si un CV contiene determinadas palabras clave, como si fuera un bingo. Seguramente tenga más que ver con revisar la experiencia de esa persona, su capacidad de trabajo y de aprender nuevas cosas. Y, obviamente, con darle la oportunidad de demostrarlo.

Si hace falta talento para ser buen desarrollador, también hace falta talento para encontrar ese talento. Personalmente, creo que deberíamos todos aspirar a hacerlo mucho mejor que como lo hemos hecho hasta ahora.

The post En busca del talento ¿perdido? appeared first on jordisan.net.

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:

• Susanna, a freelance web developer (occasional evaluator role)
• Marc, a usability and UX consultant (usability expert role)

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):

The post Defining personas for UX evaluations appeared first on jordisan.net.

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?

Creating an application for evaluations

Now that we have the guidelines, we would like to create an application to perform evaluations using them. Since we are talking about implementing a user-experience technique, the expected way would be following some type of user-centered methodology.

As a first step, we must consider some kind of research technique to gather information about requirements and user profiles. Ideally this research should be done by studying multiple real-life cases, but since this is a personal project with (very) limited resources, for this stage I’ll use my own knowledge and, hopefully, some feedback from the design community.

To document the design process I will use a public project in UX manager, a personal website developed as my master thesis to manage different UCD techniques in a single integrated repository.

So the first technique we will apply is defining user roles.

User roles in UX evaluations

Following the definition by Constantine, a user role is a particular kind of relationship between some users and a system, an abstraction, a collection of characteristic needs, interests, expectations, and behaviors. In this case, these are the profiles I can think of when talking about usability/accessibility evaluations:

• evaluators: usability and/or accessibility experts evaluating interfaces and delivering reports;
• designers (explorers): although they don’t perform evaluations, they should take guidelines into consideration when creating interfaces;
• frontend developers (occasional evaluators): they may be interested in perform some kind of evaluation of the interfaces they are developing;

Remember that the description of this technique dictates that a single person may play one or more roles, and that the system should consider all the roles; that doesn’t imply that all roles need a separate interface or that they will translate into actual user profiles in the final system.

Now let’s define which of those roles are “focal” or high-priority to serve as the central focus of the interface (without excluding other roles). In this case, I’m choosing usability experts and frontend developers (occasional evaluators) as the focal roles, as I consider that they will take more advantage of this system; other roles (designers, accessibility evaluators) may still benefit from it, but probably as a complement of existing tools they already use for their job.

In any case, following an iterative approach to design, these user roles might change in later stages.

Here you have the (current) complete description of the focal user roles; the complete documentation of all the roles are available as user roles in UX manager; you can check them and provide your feedback in order to define these (and maybe other) roles.

What’s next

Once user roles are described, a good candidate for the following technique would be defining personas for the focal roles, and then starting to create some prototypes for the interfaces. I’d try to follow that path, depending on my availability and the feedback from the community. Stay tuned!

The post From UX heuristics to an application for evaluations: user roles appeared first on jordisan.net.

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.

El punto de vista del artículo encajaba con mi experiencia: los equipos de diseño y los de programación suelen estar relativamente separados en las organizaciones, e incluyen especialistas que habitualmente:

• tienen perfiles y habilidades muy diferentes
• raramente utilizan las mismas herramientas
• hablan lenguajes diferentes

Precisamente esa discontinuidad, esa brecha en el proceso de desarrollo puede suponer un problema importante a la hora de convertir las necesidades de los usuarios en una aplicación usable, justo ahora que estamos llegando a la conclusión de que dicho proceso tiene que ser iterativo, ágil e integrado.

¿Puede implementarse una metodología ágil o un desarrollo iterativo cuando la comunicación entre diseño y desarrollo es unidireccional y basada en capturas de Photoshop, sin un método de feedback establecido? Eso es algo más propio de una metodología en cascada clásica, donde las especificaciones vienen dictadas “desde arriba”, son inmutables y prácticamente no existe comunicación en el otro sentido.

Justo ahí es donde esos UX developers, personas con conocimientos y experiencia tanto en el campo del desarrollo como en el del diseño, pueden (podemos) actuar como puentes, salvando esa brecha entre disciplinas y facilitando la comunicación en ambos sentidos: por un lado, aportando contexto y limitaciones técnicas a las decisiones de diseño; por otro, incluyendo un punto de vista y una empatía hacia el usuario final en el equipo de programación.

Tomando como punto de partida ese artículo he pensado que se puede concretar más en qué aspectos los UX developers podrían aportar valor en el proceso de desarrollo. Y se me ocurren dos ejemplos:

• en herramientas tan en boca de todos como los design systems
• en un aspecto tan crucial (y, en mi opinión, un tanto descuidado) como la UX de los desarrolladores.

Design systems: quién le pone el cascabel al gato

De un tiempo a esta parte da la sensación de que no eres una organización que se precie si no tienes tu propio ‘design system‘. Más allá de discusiones sobre si es realmente un concepto nuevo o si se trata simplemente de una evolución natural en el proceso de diseño, podemos probablemente acordar que un requisito fundamental en un sistema de diseño es que funcione como repositorio único de estilos, de componentes, de principios, etc. para todos los involucrados en el proceso de desarrollo: fundamentalmente diseñadores y programadores.

Hasta ahora un equipo de diseño podía, por ejemplo, proporcionar una guía de estilos a los desarrolladores y dejar que la integraran en sus interfaces en función de las posibilidades de la arquitectura; por otro lado, los programadores podían tener su propia librería de componentes software para implementar los diseños, librería a la que los diseñadores probablemente no tenían acceso.

Actualmente, para evolucionar hacia un verdadero design system todos esos elementos tienen que formar parte de un único repositorio compartido e integrado. Y como tal, ese repositorio no puede ser creado ni impuesto por una de las partes involucradas, sino que debe ser acordado y puesto en común por todas ellas. Las intenciones son indudablemente buenas, pero ¿quién puede llevar a cabo esa tarea?

Es precisamente ahí donde la figura del UX developer puede jugar un papel fundamental en un design system, tanto a la hora de definir las características y necesidades del sistema y desarrollarlo (detectando puntos en común y posibles fricciones) como para actuar como mediador entre las partes involucradas, al conocer cada una de ellas y hablar su lenguaje propio. Cualquier intento de crear un design system impuesto por un solo departamento teniendo en cuenta únicamente sus propias necesidades tendrá todos los números de terminar en fracaso.

La ‘developer experience’, o los programadores también son personas

En un artículo anterior hablaba de la necesidad de mejorar la experiencia de usuario de los desarrolladores. Cada vez más el proceso de desarrollar una aplicación requiere conocimientos variados, desde el uso de multitud de librerías y herramientas de terceros (frameworks JS, npm, Git, …), hasta el seguimiento de determinados procesos y metodologías (Scrum, Agile, TDD, …). Conceptos como el de full-stack o el de devops pueden dar la falsa sensación de que los profesionales de perfil técnico pueden asumir toda esa sobrecarga de información sin ningún coste. Y no es así: ni siquiera los programadores pueden saberlo todo sobre todo.

“Fullstack” developer. pic.twitter.com/yfymQmJJgq

— Brian Holt (@holtbt) March 24, 2018

Usar interfaces muy claras, hacer las herramientas más fáciles de usar, reducir la necesidad de memorizar datos, automatizar las tareas más repetitivas, … Todos esos propósitos básicos de UX habitualmente referidos a los usuarios finales se pueden (y se deberían) aplicar también a los propios programadores. Reducir la carga cognitiva necesaria para manejar sus herramientas y procesos hará que estos se puedan concentrar en la tarea más complicada y creativa: desarrollar.

Y no se me ocurre nadie mejor que un UX developer para llevar a cabo esa tarea de mejorar la experiencia de los programadores. ¿Por qué no aplicar una evaluación de usabilidad a las herramientas que usan los desarrolladores para ver qué procesos se pueden mejorar? ¿Por qué no hacer un test de usuario con programadores para detectar qué problemas tienen y mejorar su experiencia? Estoy convencido que cualquier recurso dedicado a facilitar el trabajo de los desarrolladores se compensa muy sobradamente con software de mejor calidad.

Ponga un UX developer en su vida

Siendo consciente del peligroso “obligocentrismo” de pensar que el trabajo propio es el más importante y necesario de la galaxia, sinceramente estoy convencido que la figura del UX developer como alguien que pueda moverse a ambos lados de la frontera entre el diseño y el desarrollo tiene muchísimo que aportar en las organizaciones software, y no me extrañaría que fuera un perfil que empezara a demandarse cada vez más en el mundo laboral.

Ahora que a los programadores se les pide en las ofertas de trabajo experiencia y conocimientos en muchos ámbitos (full stack, devops, …) y en tecnologías concretas (“5 años en Angular 2”, “Git”, …) que un buen profesional con experiencia puede aprender en poco tiempo, considero que un desarrollador con experiencia en tareas de UX puede resultar muy valioso, ya que esas habilidades requieren más tiempo y dedicación y, por otro lado, tendrán un tiempo de vida útil mucho más largo que un lenguaje o framework concretos.

Y quizás en algún momento un UX developer siga siendo una quimera como ser híbrido, pero ya no como situación imaginaria.

The post UX developers, ¿una quimera? appeared first on jordisan.net.

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.

Por eso Kathy Sierra insistía en que los desarrolladores necesitamos automatizar todas las tareas que sea posible para poder centrar los esfuerzos en el trabajo realmente creativo.

Por cierto, si no conocéis el trabajo de Kathy Sierra, solo os puedo decir que escribió algunos de los mejores textos sobre UX incluso antes de que empezáramos a llamarlo UX.

¿No os parece que desarrollar una aplicación es ya lo suficientemente complicado como para tener que dedicar una parte importante del tiempo (¡y esfuerzo cognitivo!) a entender por qué npm no hace más que encontrar vulnerabilidades, o qué comando tengo que usar en Git para no perder el trabajo de los últimos dos días?

Programadores que se las apañan

Como ya explicaba Steve Krugg en su popularísimo libro No me hagas pensar, los usuarios no se aprenden los detalles de cómo funcionan las aplicaciones o las webs que utilizan, sino que van a dedicar el esfuerzo mínimo (otra vez: porque los recursos cognitivos son escasos) para obtener el resultado que desean; simplemente “se las apañan”.

¿Alguna vez habéis visto a alguien introducir una URL en el cuadro de búsqueda de Google para después hacer click en el resultado, en vez de poner directamente la url en la dirección del navegador? Da igual que estén usando la interfaz de una manera que no es la óptima ni la que estaba planeada en un principio: si aprendo que así funciona, lo seguiré haciendo así porque no necesito más.

Ese efecto, perfectamente aceptable para un usuario típico, es peligroso para un programador. Si dedica sus recursos cognitivos a entender y usar sus herramientas, a la hora de programar “se las apañará”, lo que se traduce en que hará el esfuerzo mínimo para que la aplicación funcione. Y no hace falta decir que eso es una receta segura para un software de poca calidad y lleno de errores.

Abstracciones con goteras

Tengo la impresión de que cada vez son más autores los que se están manifestando en ese sentido; aparte de la ya mencionada Kathy Sierra, este otro artículo crítico con Git da, en mi opinión, con uno de los problemas clave con este tipo de herramientas. Concretamente, en el punto 5. Abstracción con goteras (perdón por la traducción):

Git no tiene tanto una abstracción con goteras como una falta de abstracción. No hay prácticamente ninguna distinción entre los detalles de implementación y la interfaz de usuario. Es comprensible que un usuario avanzado necesite conocer algo sobre cómo las funcionalidades están implementadas para captar las diferencias sutiles entre diferentes comandos. Pero incluso los principiantes se enfrentan rápidamente a horrendos detalles internos.

Touché.

Y lo mismo podría decirse de otros recursos usados por los desarrolladores. Por ejemplo, los frameworks JavaScript: en teoría no es necesario conocer sus detalles de implementación para poder usarlos, lo que debería simplificar el trabajo del programador que los usa. Sin embargo mi experiencia es que, una vez que uno se aparta de los ejemplos más triviales, se ve enfrentado a lidiar con sus detalles internos para cosas tan básicas como la comunicación entre componentes o el mantenimiento del estado.

Otro artículo en un sentido similar: Guido Van Rossum, el creador de Python, decía hace no mucho en una entrevista:

Hay un montón de tareas de programación que son sencillas en Python. Para alguien que no es todavía programador, que quiere convertirse en programador, para esa gente Python es particularmente fácil de entender.
[…]
Escribimos código principalmente para comunicarnos con otros programadores y, en menor medida, para imponer tus deseos al ordenador.

Así que volvamos a decirlo: programar ya es un trabajo lo suficientemente complejo como para que usar sus recursos también lo sean. Por eso los desarrolladores deberíamos hacer el esfuerzo de abandonar el esnobismo (¿o será masoquismo?) de usar herramientas que nadie parece entender completamente, y aceptar que no existe ninguna deshonra en crear y usar otras más fáciles de usar.

The post La UX de los programadores: ni esnobismo ni masoquismo appeared first on jordisan.net.

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).

Metodologías y “metodologías”

Si consideramos que una metodología es una combinación de técnicas (o métodos), herramientas para desarrollarlas y alguna guía que ayude a elegir cuándo y como hacerlo, no cabe duda de que los desarrolladores llevan mucha ventaja a los diseñadores. Desde las metodologías en cascada hasta las ágiles, en general podemos decir que las de desarrollo de software están bastante bien estudiadas y definidas: sus pasos, sus herramientas, las diferencias entre ellas, etc. Eso hace que, en general, podemos determinar si un proceso concreto sigue una metodología u otra.

Por otro lado, en los foros del diseño de interfaces se sigue discutiendo sobre qué es UX, qué es diseño centrado en el usuario, qué es design thinking; y por qué es una herejía digna de excomunión confundirlos o mezclarlos. Eso sí, cuando uno intenta hacer una comparación mínimamente rigurosa entre ellos se encuentra con que, en la práctica, no existe una definición formal de ninguno de ellos, ni de los pasos o técnicas concretas que incluyen. Son, en el mejor caso, una serie de principios generales y buenas prácticas que además son, ¡oh, sorpresa!, muy similares entre ellos. Mientras un programador puede perfectamente decir que no está usando Scrum, es difícil que algún diseñador afirme que no “hace UX”, o que no está centrado en el usuario; prueba de que, en el fondo, no significan prácticamente nada (si nos inspiramos en la falsabilidad de Popper).

Creo firmemente que sería positivo que los diseñadores de interfaces dispusieran de metodologías más y mejor definidas, que les guiaran en el proceso de diseño y a la hora de decidir qué técnicas aplicar en cada momento y cómo (sobre lo que hice un humildísimo intento). Eso sí, siempre recordando que usar una metodología en un proceso creativo no quiere decir limitar la creatividad, sino encauzarla hacia el objetivo final.

En definitiva, en este aspecto los diseñadores podrían parecerse un poco más a los desarrolladores, pero sin llegar a perder de vista (como a veces les ocurre a  estos últimos) que la metodología es un medio, no un fin en sí mismo. El objetivo final es construir mejor software o mejores diseños, no elaborar mejores entregables o poder presumir de que se ha seguido la metodología al pie de la letra.

Lo que nos lleva al siguiente punto.

Herramientas (y el amor por ellas)

Los desarrolladores se enamoran con preocupante frecuencia de sus herramientas (y que nadie saque la frase de contexto). Todavía me sorprende la pasión casi “hooliganiana” con la que muchos de ellos defienden la superioridad de su lenguaje de programación o del framework que usan sobre los demás. Que yo sepa, los fontaneros no llevan camisetas con su llave inglesa preferida, ni los electricistas hacen congresos para gritar lo avanzados que son los destornilladores de estrella comparados con los de pala. Personalmente tengo más una relación de amor/odio con ellas; son herramientas, las eliges en función de tu objetivo, y cuando las conoces acabas conociendo y amando sus virtudes, y odiando sus defectos.

¿De dónde viene entonces ese “fanboyismo” (tan poco profesional, me atrevería a decir)?. Probablemente daría para una tesis en psicología, pero puede que la receta tenga (además de nuestra tendencia a seguir las modas) un poco de Síndrome de Estocolmo, algo de disonancia cognitiva y una pizca de falacia del coste hundido. En resumen: cuando uno ha invertido mucho tiempo y esfuerzo en dominar una tecnología, racionaliza que esa tecnología tiene que ser buena por necesidad y hace que sea poco probable que la abandone en favor de otra.

El resultado es que, en ocasiones, los programadores dedican más tiempo y esfuerzo a conseguir que las herramientas funcionen (cof… cof… Git… cof… cof… node.js … cof… cof… Webpack… cof… cof…) que en realizar su verdadero trabajo. Como decía Kathy Sierra, ese tipo de tareas secundarias deberían automatizarse en la medida de lo posible para que los desarrolladores puedan concentrarse en las tareas creativas de su trabajo, que bastante difíciles son ya de por sí.

Entre los diseñadores, en cambio, mi sensación es que ese efecto es mucho menos acusado. Por supuesto, cada uno tiene sus herramientas de prototipado o editores gráficos favoritos, pero no me parece que estén tan atados a ellas como los desarrolladores, ni que el uso de una u otra despierte tantas pasiones. Parece que en el diseño se tiene más presente que el verdadero objetivo es el trabajo realizado (un diseño adecuado) e, idealmente, la satisfacción del usuario, y que las herramientas utilizadas son un aspecto secundario. Diría que, en ese sentido, los desarrolladores deberían tomar buena nota.

Mientras tanto…

… podemos seguir discutiendo sobre cómo se llama lo que hacemos, o si los diseñadores deberían saber programar, o cuánto deberían saber los desarrolladores de diseño, o qué ponemos en nuestro perfil de LinkedIn. Las discusiones semánticas tienen su utilidad, pero corremos el riesgo de quedarnos varados en ellas y que se conviertan en argumentaciones sobre el sexo de los ángeles, sin ningún resultado práctico.

Yo, por ahora, seguiré actuando como si supiera lo que hago (hasta que me descubran).

The post Un impostor entre dos aguas appeared first on jordisan.net.

Hay 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.

Problemas comunes (y cómo resolverlos)

Estos son algunos de los aspectos que suelen resultar problemáticos en este tipo de webs.

Sobrecarga de información y de opciones

La mayoría de sitios webs de viajes tienen ya claro que su buscador es la funcionalidad principal y lo hacen suficientemente visible; sin embargo, algunas incluyen demasiada información y opciones, especialmente en la página inicial: buscador, ofertas, paquetes, chollos de última hora…; muchas veces parecen “dejados caer” en la página sin que sea evidente una agrupación o estructura en secciones. Esto puede provocar que los usuarios tengan que hacer un esfuerzo para identificar el punto de inicio que les interesa; es habitual, por ejemplo, encontrar imágenes de sitios de ensueño que mejoran la estética del sitio pero pueden resultar irrelevantes para el usuario (a no ser que sean fotos de su destino concreto).

Recordemos que uno de los principales “mandamientos” de la experiencia de usuario es que la terminología y el funcionamiento del sitio web deben adaptarse al usuario y no reflejar los aspectos internos del negocio. Sin embargo, ciertos sitios web todavía parecen incluir contenidos y categorizaciones que no resultan nada obvios para los clientes.

Muchos sitios webs incluyen conceptos que pueden resultar confusos para los usuarios finales; ¿entenderán los clientes qué contenidos habrá en “Paquetes”, “Circuitos” y “Destinos”? ¿Qué diferencias existen entre ellos?

El consejo es evitar los diseños en los que todo intenta llamar la atención, y usar opciones que el usuario entienda fácilmente. Es importante que el usuario identifique un punto de partida claro en función de sus necesidades y de su perfil (más adelante hablamos un poco más de esos perfiles).

Falta información sobre precios (o poco clara)

Aunque es algo que parece que está mejorando, todavía hay sitios en los que la información sobre precios es poco clara: no se muestran desde un principio, o esconden tasas adicionales que se añaden al final del proceso. Muchos usuarios conocen ya esas prácticas y van a reaccionar de manera negativa, así que mejor ser claro y transparente con los costes desde el principio.

No adaptarse al usuario

Por su propia naturaleza, este tipo de sitios incluyen mucha información que puede adecuarse a cada usuario en función de sus características específicas (especialmente su ubicación). Entre ellas:

• mostrar los importes utilizando la moneda local del usuario
• utilizar como punto de partida del viaje uno cercano a la ubicación el usuario (por ejemplo, su aeropuerto más cercano en el caso de vuelos)

Selectores de fechas complejos

Un calendario para elegir una o varias fechas es un control prácticamente imprescindible en un sitio de viajes; sin embargo, no existe una implementación óptima y en muchas ocasiones resultan un punto de confusión para los usuarios. Es sin duda un aspecto que requiere especial atención en el diseño y las pruebas, teniendo en cuenta:

• aplicar límites lógicos; por ejemplo, no permitir seleccionar una fecha anterior a la actual para una reserva, o no mostrar fechas anteriores a la de ida cuando se está seleccionando la de vuelta
• mostrar la selección de manera clara; identificar la fecha de ida cuando se está seleccionando la de vuelta
• permitir introducir las fechas mediante teclado; para algunos usuarios es más cómodo, aunque deben tener claro el formato concreto que acepta el sistema

Este selector marca la fecha de inicio y final con dos aviones, pero… ¿están incluidos el día 16 y el 19? No queda claro. Además, no permite introducir las fechas mediante teclado.

Ojo con los cupones descuento

Los cupones-descuento (vouchers) son un aspecto que puede resultar interesante en determinados casos, pero hay que prestar especial atención a en qué punto del proceso de compra se solicitan (normalmente mejor al final), y a cómo afectan a los usuarios que no disponen de un cupón. En algunos casos pueden resultar incluso contraproducentes, así que no hay que descartar otras alternativas (ofrecer los descuentos en función del usuario autenticado o del link de origen).

Oportunidades

Además de evitar los problemas más comunes, hay aspectos que ofrecen posibilidades especialmente interesantes a la hora de destacarse sobre la competencia.

Tener en cuenta los diferentes perfiles de usuario

Algunos autores identifican diferentes tipos de usuario de comercio electrónico, que se pueden resumir básicamente en:

• browser (“curioseador”): navega por diferentes opciones sin un propósito específico; no busca comprar específicamente, aunque puede hacerlo si encuentra algo especialmente interesante
• hunter (“cazador”): tiene más o menos claro lo que quiere comprar, pero anda en busca de la mejor opción (muchas veces, el mejor precio); va a comparar y a tener en cuenta múltiples opciones antes de comprar
• buyer (“comprador”): tiene claro lo que necesita y lo va a comprar (si lo encuentra)

Un sitio web de viajes puede dar servicio a todos esos perfiles ofreciendo, por un lado, un buscador que admita datos específicos para los “compradores”, pero que permita también una búsqueda abierta, con pocos datos y que se pueda refinar posteriormente en función de los resultados para los “cazadores” y “curioseadores”. A estos últimos también les resultará útil que las búsquedas ofrezcan resultados cercanos a los especificados por el usuario (por ejemplo, en fechas, en precios o en destinos). Por otro lado, mostrar ofertas o “chollos” será interesante para los “curioseadores”.

En Kayak es posible especificar rangos de fecha en vez de fechas concretas, lo que proporciona más opciones a usuarios que tienen requerimientos flexibles. Sin embargo, eso introduce complejidad adicional en el selector de fechas.

Incluir aspectos emocionales y sociales

Como ya saben los expertos en marketing hace tiempo (y explican perfectamente los libros de Susan Weinschenk aplicados al mundo web), incluir referencias sociales y/o emocionales afecta de manera muy importante a la decisión de compra de los usuarios. También en un sitio web sobre viajes se puede apelar, por ejemplo, a:

• testimonios y recomendaciones de otros usuarios
• escasez (“solo quedan 5 disponibles”; “faltan solo 3 días”)

Expedia incluye tanto valoraciones de usuarios (“vuelo agradable”) como información de disponibilidad (“quedan 2”). Este tipo de información puede resultar útil para el usuario y favorecer la compra, siempre que se haga de manera adecuada y honesta, y no introduzca una sobrecarga excesiva de información.

A la hora de incluir este tipo de contenidos es fundamental hacerlo siempre con honestidad y con precaución; exagerar (y mucho más mentir) puede producir resultados negativos que luego van a ser muy difíciles de contrarrestar.

Combatir el abandono del proceso de compra

Un punto de optimización en cualquier proceso de comercio electrónico (también en sitios de viajes) es identificar y combatir los procesos de compra que se abandonan después de iniciados. En muchos casos se tratará de usuarios que simplemente están buscando el mejor precio, pero también podrían existir problemas de usabilidad concretos que no vamos a detectar si no hacemos un estudio porque los usuarios no van a quejarse: simplemente van a abandonar el proceso. La analítica nos ayudará a identificar en qué punto se producen esos problemas, y técnicas como los tests de usuarios nos ayudarán a comprobar por qué.

Como siempre, los móviles

A estas alturas puede resultar casi innecesario insistir en la necesidad de que los diseños funcionen de manera adecuada en diferentes plataformas, y especialmente en móviles (que representan ya más de la mitad de visitas en la mayoría de sitios web). También es aplicable a los sitios web de viajes, con un añadido especial: es probable que las compras de última hora se hagan desde un dispositivo móvil, cuando el usuario se encuentra fuera de su ubicación habitual; podría ser por tanto útil que, para un móvil, la cercanía espacial y temporal sea especialmente importante (“necesito un hotel cercano para esta noche”).

Interactuar desde el móvil con un sitio web que no adapta sus contenidos (y su diseño) a ese dispositivo puede resultar muy incómodo. En este ejemplo, seleccionar un campo específico con el dedo resulta verdaderamente complicado.

En resumen

Como siempre, no existen recetas mágicas que garanticen que un sitio web sobre viajes va a proporcionar una experiencia satisfactoria a sus usuarios; nada sustituye a la investigación y a las pruebas con usuarios reales. Aún así, sí hemos identificado algunos problemas y puntos críticos que los diseñadores deben considerar de manera especial desde un principio, así como algunos aspectos que pueden hacer que un sitio web se diferencie de los demás por la calidad de la experiencia que ofrece. Y eso es algo que no puede ignorarse en ningún caso, y menos aún en un mercado en el que existen tantas alternativas.

Referencias

• 5 User Experience Mistakes Travel Sites Make
• How to Improve Travel Website Conversion
• User Experience in the travel sector (PDF)
• Top 4 UX tips for businesses in the online travel industry
• 30 Most Perfect Online Booking Forms – You Have Ever Seen

The post Experiencia de usuario (UX) en sitios de viajes appeared first on jordisan.net.

The post No, no he trabajado con AngularJS. ¿Y? appeared first on jordisan.net.

This is the solution I have implemented in my own site:

1. Create a new .tpl template file under your theme path; I’m using /themes/themename/0globaltrans.tpl so as it appears at the top in the list of translations in PrestaShop’s backend (admin interface).
2. Insert this code in the previous file:

   {*
   GLOBAL TRANSLATIONS:
   List all possible translations below
   in order to make them appear in PrestaShop back office:
   {l s="string to translate 1"}
   {l s="string to translate 2"}
   {l s="string to translate 3"}
   *}
   {l s=$s}

3. In every template (.tpl file) where you want to insert these global translations, use this code instead of {l s="string to translate 1"}:

   {include file="$tpl_dir./0globaltrans.tpl" s="string to translate 1"}

4. Now we can manage these translations from the PrestaShop back office, through Localization > Translations > Front office translations. If you have used  the suggested file name for the global template, they will appear under the section 0GLOBALTRANS: 

How does it work?

Instead of using the usual function {l s="... , we include the global file passing the string to translate as a variable; in the included file we just take that variable and call the translation function. Since all the translations are called from the same .tpl file, they will appear all in the same section in PrestaShop’s translation tool in the back office.

We have to list all the translated strings in the top commented block; otherwise they don’t appear in the back office (at least in version 1.6).

Does it work for you? Any other functionality you would need?

The post Global translations in PrestaShop appeared first on jordisan.net.

Los usuarios más avezados están acostumbrados a ese formato, pero es evidente que la portada dista bastante de una web típica de un diario; probablemente eso hace que usuarios que la desconocen difícilmente identifiquen su funcionamiento. Además, el diseño promociona de manera muy obvia las funcionalidades sociales del sitio (votar las noticias, comentarios, puntuación o “karma” de cada noticia, etc.). ¿Cómo podríamos hacer que Menéame fuera menos árido para los visitantes ocasionales del sitio?

Aprovechando que el código fuente está accesible para cualquiera que quiera utilizarlo, he hecho una instalación propia con datos de prueba (para lo que he contado con la colaboración de la propia comunidad de usuarios), sobre la que he creado una portada alternativa que he llamado “Menéame diario“.

Menéame diario

Como se puede ver a simple vista, el look & feel de esta nueva página es similar al de las existentes (de hecho, es una modificación sobre la actual página “populares”), pero con dos características diferenciadoras:

• El diseño, además de destacar la noticia más popular de ese día, agrupa las noticias por categorías, y las funcionalidades sociales se han minimizado.
• Las noticias se refieren a una fecha determinada; esto además permite consultar las noticias de fechas atrasadas utilizando el cuadro de la zona superior, una función (hemeroteca) que no existe como tal actualmente.

El propósito de esta portada no sería sustituir a la actual (probablemente sería una mala idea desatender a los usuarios habituales), sino proporcionar una alternativa a aquellos más interesados en conocer la información diaria que en participar activamente (votar, comentar, etc.). Y quiero decir “menos interesados” al menos al principio, porque podría representar una entrada más familiar (por ser similar a otros sitios webs de noticias) a usuarios que luego se podrían convertir en participantes activos, evitando una reacción del tipo “no entiendo cómo funciona esto… me voy”.

Podéis ver que tampoco se trata de “hacer más bonita” la portada, sino de una reestructuración de contenidos, incluso “quitando” cosas; de hecho, considero que uno de los éxitos de Menéame ha sido darle más importancia al contenido que al aspecto. Y siempre está bien recordar que el “diseño web” incluye muchos más aspectos que los puramente estéticos.

Por otro lado, los que ya utilizan la web tendrían esa hemeroteca en la que tampoco tendría mucho sentido un orden puramente cronológico (es más interesante poner en primer lugar la noticia más destacada del día que la última publicada ese día).

Implementación

Como suele ser habitual en aplicaciones open source, cualquiera puede implementar y proponer mejoras al código, y yo ya he hecho la propuesta (en GitHub). Ahora los responsables del sitio web (que han cambiado recientemente) pueden aceptar o no la integración de estos cambios en Menéame.

Por supuesto, habría detalles a resolver:

• Cómo llegar a este “Menéame diario”. Yo propondría una nueva opción en el menú del sitio, aunque ese detalle sería relativamente sencillo de resolver.
• La columna lateral derecha. Con el código actual, esa zona mostraría lo mismo que la portada actual (publicidad, noticias y comentarios destacados actualmente, etc.); en caso de poner en marcha esta opción, seguramente tendría más sentido que dicha columna hiciera referencia a los contenidos de la fecha consultada, no del día actual. También sería interesante un texto destinado a que los usuarios participaran más activamente (¿quizás el cuadro de login?).
• Qué ocurre al principio del día. Durante las primeras horas de cada día el número de noticias publicadas sería reducido y el diseño quedaría demasiado vacío. Se podría estudiar una alternativa; por ejemplo, mantener también las noticias de la fecha anterior durante esas primeras horas.

Estos (y otros) detalles que se podrían resolver una vez integrada la nueva portada en el sitio principal; uno de los problemas de desarrollar en un sitio web separado es que los datos de prueba no son suficientemente completos y/o representativos como para diseñar todos los casos posibles.

Creo que hay otras mejoras que se podrían realizar sobre Menéame; por ejemplo, la actual división entre categorías/subs/ediciones resulta bastante confusa, y sería interesante simplificar y dejar más clara la estructura de contenidos; y creo que algo similar pasa con las opciones populares/más visitadas/más destacadas. Pero eso requeriría cambios más profundos en Menéame que difícilmente se pueden crear como una propuesta externa.

Como siempre, estáis invitados a dejar vuestra opinión ya sea aquí, en Menéame o incluso en GitHub (si hacen referencia específica al código fuente). Eso sí, recordad que la primera regla de la usabilidad es “no escuches a tus usuarios” (aunque en realidad es “escucha a tus usuarios, pero lo realmente importante es lo que hacen, no lo que dicen”).

The post Menéame diario (propuesta) appeared first on jordisan.net.