Entrevista con Núria Ramoneda

Núria hace años que se ha especializado en la ejecución de proyectos web en WordPress, desarrollando temas y plugins a medida, siempre en estrecha relación con el cliente y tratando de aplicar su interés por la experiencia de usuario no solo a la parte visible de la web, sino también a la administración de los contenidos de la misma. Esta semana tenemos la oportunidad de hablar con ella.

La author experience contribuye, de manera eficiente, en el proceso de comunicación y gestión de quienes crean y publican contenido a través de un CMS. ¿Puedes contarnos más acerca de esta disciplina?

Como bien has dicho, la AX persigue dar valor a la gestión de ese proceso de comunicación de forma eficaz y eficiente, tratando ese proceso desde el punto de vista de los creadores y gestores de contenido. Ese es uno de sus puntos diferenciadores respecto a la UX, ya que la AX se centra en los usuarios que crean y gestionan el contenido, no en los que lo consumen. Estos últimos son el foco de atención de la UX, que se centra en hacer que su experiencia sea más fácil y placentera, que el contenido que consumen sea útil y deseable además de creíble y accesible. Ello coincide en gran parte con los objetivos de la AX, pero los beneficios emocionales no tienen tanta importancia en la AX como en la UX, y esa es otra de sus diferencias.

Como explica Rick Yagodich en su libro Author Experience, los usuarios de la administración de los CMS (los autores) utilizan los CMS para hacer un trabajo, para realizar una tarea. No están buscando información, ni quieren hacer una compra, quieren cumplir con su cometido. Aunque también es importante que el autor se sienta a gusto haciendo su trabajo, por supuesto, la AX se centra más en que su experiencia sea «eficiente, lógica y apropiada para la tarea». En este sentido, en la misma obra, Yagodich plantea esta definición:

“La experiencia del autor, como disciplina, es proveer la funcionalidad adecuada al contexto dentro de un entorno de gestión de contenido.”

Me gusta porque introduce el concepto de «adecuación» de las funcionalidades, lo que implica que no se deben proporcionar al usuario ni más ni menos herramientas para hacer las tareas que tiene encomendadas. Se le debe proporcionar lo que necesita y de forma adecuada para que pueda gestionar el contenido de la manera adecuada para que el usuario final la consuma de la forma prevista.

Recomiendo a cualquiera que esté interesado en esta disciplina que lea esta obra. Yagodich fue quien acuñó el término author experience allá en 2010 y quien le ha dado forma y cuerpo a esta disciplina en primera instancia.

Como experta en desarrollo web, ¿cómo y cuándo empezó tu interés en la author experience?

Antes de dedicarme al desarrollo web, trabajaba en el ámbito de las aplicaciones de escritorio, creaba con MS Access y Visual Basic aplicaciones de gestión que mecanizaban procesos que muchas veces se hacían todavía de forma manual o con hojas de cálculo. Para ello tenía que hablar con los usuarios, que me explicaran su trabajo, cómo era todo el proceso, y nosotros, los desarrolladores, teníamos que programar una aplicación que les ayudara a ser más eficientes en esas tareas, les evitara tareas repetitivas, les facilitara manejar muchos datos y sacar otros a partir de ellos. Era importante también que se sintieran a gusto manejando estas nuevas aplicaciones para que su aceptación fuera más fácil y ayudara a crear nuevos hábitos y consolidarlos.

En aquella época, te hablo de la segunda mitad de los 90 y principio de los 2000, y en el entorno en el que yo trabajaba, administración pública y empresa industrial, no había diseñadores para las aplicaciones, ni se hablaba de UX ni nada parecido. Los desarrolladores lo hacíamos todo y, según el arte y la sensibilidad de cada uno, se conseguían experiencias más o menos eficientes y agradables para los usuarios.

En mi última época de esta etapa, antes de pasarme al entorno web, me dediqué a implementar un ERP en una empresa industrial. Esa fue mi primera experiencia con un software prediseñado que no permitía muchas personalizaciones o que eran complejas y costosas de hacer. Ahí conocí aún más de cerca la frustración y el desánimo de profesionales de todo tipo (contables, ingenieros y diseñadores industriales, jefes de almacén, operarios…) ante las dificultades de uso de un sistema rígido, pensado para automatizar y centralizar los procesos fundamentales de una industria, pero sin tener en cuenta a las personas que iban a usarlo en el día a día.

Durante muchos años, el concepto de user experience ha sido estudiado y analizado por diferentes académicos y profesionales del sector. ¿Consideras que es más importante que la author experience?

No se trata de que una sea más importante que la otra. El problema es que ni la UX ni ninguna otra disciplina han tenido en cuenta a los autores, a los usuarios del back end, más bien se han olvidado de ellos, centrándose solo en los usuarios finales de la web.

Desde el punto de vista del uso del CMS, en cuanto a tipos genéricos de usuarios, podríamos hablar de dos grandes grupos. Los usuarios del front end (lo que se ve) y los usuarios de back end (lo que está detrás).

Las diferencias entre ambos grupos no son solo cuantitativas, sin duda los usuarios que visitan e interactúan con una web son muchos más que los que se dedican a crear y mantener su contenido, sino también en cuanto a sus intereses y, aparentemente, a los intereses del negocio. Son los usuarios del front end los que con sus visitas y acciones generan ingresos (monetizados o no) para la web, ya sea porque compran productos, porque ven la publicidad que se inserta para ellos, porque piden presupuestos, se suscriben a las newsletters o, simplemente, porque dejan sus datos, según cuál sea el objetivo de la web. Por eso, entre otras razones, la UX se ha centrado tradicionalmente en ellos.

Pero a medida que la era digital ha ido avanzando y los hábitos de consumo de información y productos se han ampliado, los sistemas generadores de datos y gestión de contenidos, cada vez más entrelazados, se han vuelto más abstractos y complejos. El contenido que antes solo tenía un origen, ahora puede recolectarse de múltiples orígenes y debe adaptarse a múltiples entornos, canales y dispositivos donde será servido y consumido de distintas maneras.

Son muchas las personalidades distintas que trabajan con contenido CMS de una web, incluso cuando esta no es su profesión principal. ¿Cómo pueden los desarrolladores y diseñadores facilitarles ese trabajo?

En realidad, yo diría que hay pocas personas para las que su profesión principal sea trabajar con el CMS de una web. Por el contrario, son muchas más las que deben interactuar con un CMS a tiempo parcial y más o menos a menudo. Por ejemplo, los periodistas y editores de un medio digital lo usarán a diario, porque cada día salen nuevas noticias o reportajes, pero no todo el tiempo. Los responsables de los pedidos de una gran tienda online con mucho tráfico también van a estar procesando órdenes de compra diariamente. En cambio, en webs corporativas donde el contenido se cambia muy de vez en cuando, o en blogs donde se escribe un artículo semanal o quincenalmente, el uso será mucho menor. Por supuesto, hay grados intermedios en cuanto a la frecuencia de uso y a la intensidad.

Es por ello que los diseñadores y los desarrolladores debemos pensar en los distintos tipos de usuarios del back end de cada web, en los distintos usos y en la intensidad y frecuencia de los mismos, y también en los distintos orígenes y usos de los contenidos que esos autores deben gestionar.

Si una tarea implica que un usuario tenga que hacer una misma acción compleja (por ejemplo: abrir un Excel, buscar y copiar el contenido de una celda, ir al CMS, abrir una página y copiarla en el campo correspondiente) veinte veces seguidas cada día, hay algo que no hemos hecho bien. Pero si esa misma acción la tiene que hacer una vez al mes y con cinco o diez celdas, quizás no valga la pena automatizar ese proceso.

Si un contenido debe distribuirse en la página web en forma de artículo, así como también en redes sociales con distintos formatos y requisitos o en otros medios a través de feeds o API, debemos proporcionar al autor las herramientas para que pueda crear ese contenido adecuadamente para todos esos usos, sin que deba repetirlo cuando no es necesario.

A menudo hay que tomar decisiones sobre la arquitectura, el diseño y los procesos que no serán del gusto de todos. Eso es inevitable, porque no siempre se dispone del tiempo y los recursos para desarrollar las mejores interfaces y para automatizar todo lo repetitivo. Por eso es importante, siempre que se pueda, hacer partícipes a los autores del proceso de diseño y desarrollo, hablar con ellos desde el principio de cuáles son sus objetivos y necesidades, sentarse con ellos y ver cómo realizan lo que vamos a desarrollar con su sistema actual y priorizar con ellos los puntos más críticos para poder decidir en concordancia con sus necesidades.

Si trabajamos con clientes pequeños o medianos, que no pueden invertir en procesos de diseño con equipos interdisciplinares que hagan entrevistas, que definan personas, customer journeys o storyboards, también podemos ayudar. De hecho, la mayoría de las veces no nos encontramos en grandes equipos, ni pequeños, a menudo en un proyecto hay un diseñador y un desarrollador, si es que no falta el primero.

Se trata de hablar con el cliente y, además de averiguar los objetivos y las funcionalidades que debe tener la web, preguntarle quién va a ocuparse del mantenimiento de la web, cuánto tiempo le dedicará, si tiene experiencia ya en otros CMS y todo aquello que pueda ayudarnos a entender quién y cómo va a usar el CMS.

Con todo ello, cuando decidamos la arquitectura del sitio y la forma en que se van a introducir los datos y a maquetar las páginas, debemos pensar en el usuario que se va a ocupar de ello y en cómo se lo podemos poner más fácil: ordenando los campos adecuadamente, con un diseño consistente en todas las páginas del back end (que los mismos tipos de elementos sean iguales y estén en la misma posición), etiquetando ayudas en los campos que lo requieran, agrupando campos con información textual de su cometido, etc. Y ocultando lo innecesario según el tipo de usuario.

Lo importante es pensar también en el usuario del back end y en cómo va a poder introducir esa información de la forma más fácil y eficiente para él y, a la vez, de la manera en que no se pueda romper el diseño del front end.

Porque este es el otro gran reto, sobre todo cuando hablamos de webs de negocio, con diseños más complejos y libro de estilo propio. Es trabajo de diseñadores y desarrolladores no dar más opciones de estilos o de maquetación que las que el diseño haya previsto que puedan manipular los propios gestores del contenido. Si los colores de la web son el negro para el texto, el púrpura para los encabezados y el verde para los enlaces y los destacados, no podemos dejar que el usuario escoja los colores, porque entonces arruinaría la consistencia de estilos de la web. Pasa algo parecido con los encabezados, no podemos dejar que escojan el encabezado que quieran en cualquier lugar, porque, sin quererlo, estarán desbaratando la estructura correcta de la página.

Mantener una buena estructura y la calidad semántica de la misma es responsabilidad del CMS y de nuestro trabajo configurándolo y adaptándolo para mantener la coherencia del diseño y la estructura. Es lo que hablábamos al principio de la «adecuación», ni más ni menos.

¿Cuál crees que es la primera barrera con la que se topan estos usuarios no-técnicos cuando deciden trabajar con un CMS?

Depende del CMS, pero en general diría que los editores de texto para crear artículos son uno de los principales retos a superar, aunque por suerte van mejorando. Tiene mucho que ver con lo que comentaba antes. Por ejemplo, en el caso de WordPress, que es el CMS con el que trabajo, aún se puede usar el editor clásico para crear un artículo o una página nueva. Mediante este editor, si no intervenimos los desarrolladores, el usuario medio se encuentra ante un único campo de texto, donde puede usar una serie de herramientas y nada más, sin posibilidades de elegir cómo quiere que se vea esa página, ni ver cómo quedará, hasta que lo vea en el preview.

La nueva versión del editor de WordPress, llamado Gutenberg, tiene una nueva perspectiva. Inicialmente es un lienzo en blanco, pero ya nos indica, en el idioma que tengamos configurada la instalación, que podemos escribir o escoger un bloque y nos proporciona menos opciones para estilizarlo, siendo estas personalizables para adecuarlas realmente al contexto.

¿Qué características consideras que son esenciales a la hora de escoger un CMS?

Por supuesto dependerá del proyecto, de su magnitud y sus objetivos. Como decía Caleb Mellas en su artículo What does an optimal CMS user-experience look like?: «no es posible la existencia de un CMS óptimo, porque las necesidades de todos son diferentes».

Pero analizándolo solo desde la perspectiva de la AX, las características más importantes para mí serían que la administración sea configurable, que se puedan crear tipos de contenidos, taxonomías y campos para extender la arquitectura por defecto, que el editor sea configurable, trabaje en modo preview por defecto y permita trabajar con bloques.

Se trata, como comentábamos antes, de que el CMS sea flexible para darle al cliente una herramienta que le permita crear y mantener el contenido sin comprometer el diseño y la arquitectura del sitio, y permitiendo que ese contenido se adapte a los diferentes entornos en los que será servido.

¿Cómo ha ido evolucionando la author experience a lo largo del tiempo?

Desde que Rick Yagodich acuñó el concepto de author experience en 2010, en un artículo titulado «The experience alphabet: AX comes before UX», hasta hoy, han pasado apenas 10 años.

En 2014 el propio Yagodich publicó el libro que ya hemos mencionado y que hace las veces de manifiesto de la AX, pero desde entonces sigue sin haber demasiada literatura en torno a esta disciplina, que parece encontrarse con las dificultades de adopción que también tuvo la UX en sus inicios. Esta obra sigue siendo válida y de obligada lectura para cualquiera que se interese por la AX.

La AX se ha concebido, incluso sin mencionarla como tal, en gran parte desde el terreno de la «estrategia de contenidos» (content strategy). De este ámbito las voces de Eileen Webb y Karen McGrane, junto a Rick Yagodich, han sido y siguen siendo las más destacadas. Por suerte también se han unido al interés por esta disciplina profesionales del desarrollo como Rachel Andrew o Caleb Mellas, por destacar solo un par.

Quien se ha unido más recientemente a la palestra son los desarrolladores de nuevos CMS, que han integrado los conceptos de la AX y están haciendo propuestas muy orientadas a los autores y a los desarrolladores (existe también el interesante concepto de DX, developer experience), como es el caso de Craft CMS.

Desde mi punto de vista, aún le falta reconocimiento e implantación a esta disciplina, su evolución será lenta, pero sin duda acabará calando en todos los actores implicados.

¿Crees que los usuarios no-técnicos preferirían trabajar, directamente, desde el front end?

No lo creo, la edición en el front end directamente es útil cuando solo tienes que modificar algunos textos, pero no cuando debes crear una nueva página, con varios bloques, campos y propiedades por establecer. Si desarrollamos una interfaz y un workflow adecuados, no creo que los usuarios prefieran hacerlo desde el front.

¿Qué reto futuro crees que afrontaréis los desarrolladores y diseñadores web?

Creo que, ante todo, el mayor reto será la adaptación a la vida posCOVID-19. La pandemia ha cambiado las vidas de todos y ha convertido la digitalización de los procesos en una necesidad básica, ahora ya inaplazable. Todo lo que ha pasado este 2020 ha acelerado tendencias tecnológicas y ha contribuido a crear nuevos hábitos de consumo digital. La inteligencia artificial, la nube distribuida, el internet de los comportamientos o los asistentes de voz son algunas de las tecnologías que van a seguir acelerando su crecimiento e implantación en esta nueva era poscoronavirus. Y también la ciberseguridad.

En esta aceleración de los procesos, ahondar en la eficiencia y en mejorar la experiencia de usuario va a ser fundamental. Así que tenemos mucho trabajo por delante.

En el ámbito de los CMS creo que los headless CMS y las webs estáticas, la optimización de la carga, la accesibilidad y la seguridad van a seguir siendo algunos de los retos más cercanos.

Por último, ¿qué consejo les darías a esos autores que deciden trabajar con un CMS?

Que busquen el CMS que mejor encaje con sus necesidades de entrada, sabiendo que con el apoyo de profesionales del sector podrán sacar de cualquiera que elijan mucho más de lo que llevan por defecto. Y que no duden en alzar la voz para pedir que se tengan en cuenta sus necesidades al crear y gestionar contenido, porque los CMS se deben a los autores, sus principales usuarios.

Enlaces relacionados

En el texto:

YAGODICH, Rick. Author Experience: Bridging the gap between people and technology in content management. XML Press, 2014.

MELLAS, Caleb. What does an optimal CMS user-experience look like? [en línea]. Webinsation (2016).

Más enlaces de interés:

FRITZ, Katie. Priotizing Author Experience [vídeo en línea].
Craft CMS (2018). Disponible en: https://dotall.com/sessions/prioritizing-author-experience

HALLAHAN, Christopher. Designing a user-friendly web content management system [en línea].

 Chrishallahan (2018). Disponible en:

https://chrishallahan.com/blog/how-to-make-a-user-friendly-web-content-management-system

WEBB, Eileen. Building a Better Authoring Experience [en línea]. Webmeadow (2015). Disponible en:

http://webmeadow.com/presentations/authoring-experience.html

WEBB, Eileen. Training the CMS [en línea].

A List Apart (2014). Disponible en:

https://alistapart.com/article/training-the-cms/

Cita recomendada: MOSAIC. Entrevista con Núria Ramoneda. Mosaic [en línea], marzo 2021, no. 191. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n191.2111