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

Mis tropiezos con Google App Engine

¿Es Google App Engine una plataforma suficiente para desarrollar aplicaciones "serias"? ¿O son sus limitaciones demasiado restrictivas en algunos casos?

Logo 'roto' de Google App EngineHace bastante tiempo que tengo en mente una idea para desarrollar una aplicación web y, cuando me decidí por fin a implementarla, elegí Google App Engine, a pesar de que no conocía Python, el único lenguaje que soporta ahora mismo (aunque ha sido una buena excusa para aprender) y a pesar de algunas limitaciones propias de un servicio gratuito y en pruebas.

Al fin y al cabo, esos inconvenientes parecían quedar ampliamente superados por las ventajas de usar la misma infraestructura que usa Google para sus propias aplicaciones: robustez, existencia de un entorno de desarrollo, APIs de gestión de usuarios, de almacenamiento de datos, etc.

(more…)

METAeuFORiAS: Dijkstra, las metáforas y sus límites

Como ya se explica en la página descriptiva del blog, las metáforas y analogías son una potente herramienta para entender algunas ideas y descubrir otras nuevas. Sin embargo, siempre es necesario tener en cuenta que toda metáfora tiene sus limitaciones,…

Como ya se explica en la página descriptiva del blog, las metáforas y analogías son una potente herramienta para entender algunas ideas y descubrir otras nuevas. Sin embargo, siempre es necesario tener en cuenta que toda metáfora tiene sus limitaciones, así que hay que saber cuándo no llevarla más lejos, o cuándo, simplemente, es necesario abandonarla.

Edsger W. Dijkstra, una de las figuras contemporáneas de referencia en la informática y, más concretamente, en la programación, escribió hace ya 20 años el artículo “Sobre la crueldad de verdaderamente enseñar ciencias de la computación” en el que expone uno de esos casos en los que, en su opinión, es necesario abandonar una metáfora que afecta a las computadoras actuales y su programación.

[…] seguir leyendo en METAeuFORiAS (1.513 palabras)

METAeuFORiAS: Desarrollar software es como realizar una película

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada…

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada vamos a reunir esas analogías, así como descubrir algunas nuevas.

Rodaje grabando a un programador

 

[…] seguir leyendo en METAeuFORiAS (1421 palabras)

Programar y escribir para la web: no tan diferentes

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede…

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Código fuenteRicardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental (“¿de qué se trata?”; “¿qué hace?”), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

  • Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
  • Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
  • Simplicidad: Si un programa es complicado de entender no puede tener belleza.
  • Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
  • etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

(more…)