The Cathedral and the Bazaar

The shift towards agile software development models, with continuous integration processes and publication of new features, forces us as technical writers to review our own working methods. Leaving behind the model imposed by the traditional CMS and integrating documentation tasks into the development cycle is now more necessary than ever.

The Cathedral and the Bazaar

In 1999, Eric S. Raymond, one of the leading representatives of the open source initiative, published his essay entitled The Cathedral and the Bazaar. In this popular essay, Raymond writes about his experiences during the development of open code software, at the same time as he encourages programmers and companies to embrace this work philosophy.

Raymond uses the concepts of cathedral and bazaar to exemplify two quite distinct development models. The cathedral represents the development of proprietary software, where the source code is only accessible to a small group of programmers. The bazaar, on the other hand, represents the development of open source software, where the code is accessible to collaborators. The rigidity of a cathedral stands as a metaphor for a closed, centralized system, whereas the dynamism of a bazaar represents an open, collaborative system. Raymond maintains that the possibility of incorporating improvements and eliminating errors is much more extensive in a collaborative model than in a centralized one. The conclusion is that the software resulting from a collaborative model has fewer errors and is necessarily of higher quality.

The thesis explored in The Cathedral and the Bazaar has given rise to lots of discussions among those defending and criticizing open source software. The collaborative model is not free from problems, but offers advantages that make it attractive to many software development companies. It is not unusual to see such companies looking nowadays for formulas enabling them to adopt their own open source methodologies without renouncing their control of the code and intellectual property over the same.

In parallel, software development tools are incorporating more and more features that enable the principles of collaborative development to be extended to teams of workers. Together with this, the process of continuous integration and continuous delivery (known by the initials CI/CD) enables new features to be rolled out and errors to be resolved relatively quickly. Suffice to think just about the frequency with which many of the apps on our mobile telephones are updated.

The problem with content management systems

It is strange to see how this change in development methodologies has had scant repercussion on software documentation. This field continues to be founded on tasks of drafting, review, and publication that, in essence, have changed little in recent years. For writing, XML is still the standard markup language. More often than not, reviewing is still done using PDF files or, even worse, over email. And publication, which has gradually shifted to the web, often requires hours of adjustments to generate the correct PDF or HTML file.

This workflow is today sustained by complex Content Management Systems (CMS) that aim to solve the documentation needs of many different organizations at one fell swoop, but end up not entirely solving the needs of any of them.

But the fundamental problem lies in the fact that a traditional CMS understands the drafting, review, and publication tasks as actions that follow each other in orderly fashion over time and not, as so often seen in experience, all at the same time. An added problem is that the possibility of incorporating improvements from collaborators is limited to the review phase, with the documentation effectively ring-fenced for most of its development cycle.

“Ditch your CMS”

In 2014, Patrick Arlt (@patrickarlt), in the context of the Write the Docs conferences, gave a presentation titled Ditch Your CMS With Git and Static Site Generators. In this presentation, Arlt advocates abandoning the use of content management systems in favour of open code tools that favour collaboration and reduce the complexity oy documentation project.

A year later, in April, 2015, Anne Gentle (@annegentle) described the documentation process adopted by the OpenStack software manufacturer in her article entitled Git and GitHub for open source documentation. The model proposed by Gentle (subsequently developed in greater detail in her book Docs like code) proposes that technical writers should work alongside the development teams, adopting their same tools and methodologies. Because, if a software’s documentation is an integral part of the product and is produced in parallel, isn’t it more consistent to use the same workflows? In this new paradigm, writing documentation is not that different from writing code.

In summary, the Docs like Code methodology proposes:

  • Ditching the use of traditional CMS systems in favour of collaborative tools like GitHub (a code repository very popular with developers).
  • Adopting lightweight markup languages, abandoning complex languages like XML. The best-known example of these languages is Markdown.
  • Incorporating continuous review processes where reviewers can record changes at any time using pull-request mechanisms offered by GitHub.
  • Publishing product documentation regularly through the use of static page generators that enable the texts in Markdown format to be transformed into HTML code.


Millions of developers all over the world use GitHub as the repository for their application code. But what makes GitHub such an attractive environment for amateur coders, independent developers and companies? The commercial success of GitHub has been born out of its ability to simplify the use of the Git tool (a software utility originally created to manage the development of Linux) in an easy-to-use web interface. In addition, GitHub facilitates the collaboration of multiple people on the same project in a relatively straightforward way. The complexity and scalability needs of modern software have made this feature essential.

Yet this change in software development methods is not so far away from what is happening in the documentation arena. While a manual was the responsibility of a single technical writer in the past, nowadays, with growing technological complexity and the constant integration of changes, the final result requires collaboration and co-ordination involving multiple individuals. The cathedral model imposed by content management systems has not been able to respond to this change.

The time has come

Far from being a mere concept, Docs like Code is also a reality for software companies as important as Microsoft, Amazon, or Twitter. In May, 2016, Jeff Sandquist (@jeffsandannounced Microsoft’s new documentation platform in the following terms:
All documentation is designed to allow community contributions. Every article has an Edit button that takes you to the source Markdown file in GitHub where you can easily submit a pull request to fix or improve content.
A large part of the manufacturer’s documentation is already located on this new documentation platform in a clear wager in favour of the adoption of open systems. Other companies such as Amazon have followed this trend and it is now possible to see an “Edit on GitHub” button on many of the articles intended for developers.

In an article on the I’d Rather Be Writing blog, the specialist in documentation and technical writer Tom Johnson wrote a comment that goes to the root of the problem of using CMS:

No more black boxes that handle your content. No more expensive, proprietary systems to submit to. No more impossible-to-adjust-outputs. You can integrate it all simply, easily, and inexpensively.

The enormous influence these companies have in the world of software will, sooner or later, bring about the adoption of open bazaar-type documentation models to the detriment of rigid cathedral-type models. If effective and agile software development is the result of a collaborative process of continuous integration and publication, then documentation projects must necessarily adapt to this new reality.

(This article was originally published in Spanish and translated into English)

¿Es LinkedIn prescindible?

“Hay mucho talento fuera de LinkedIn”. Así resumía mi buen amigo José Manuel su experiencia con esta plataforma para profesionales en una conversación reciente. Esta afirmación no pasaría de un simple comentario si no fuera porque muchos -entre los que me incluyo- encontramos cada vez menos razones para participar en esta red.

Misión frente a realidad

LinkedIn, con más de 500 millones de usuarios, se define en su página Sobre nosotros como “la mayor red profesional del mundo”. Junto a esta afirmación, podemos leer:
Nuestra misión es sencilla: conectar a los profesionales del mundo para ayudarles a aumentar su productividad y rendimiento. Al unirte a LinkedIn obtienes acceso a personas, empleos, noticias, actualizaciones e información que te ayudará a destacar en tu campo profesional.
Pero basta un simple vistazo a esta plataforma para comprobar que la realidad dista mucho de esta noble misión. Y es que lejos de ser una red profesional, LinkedIn se ha convertido en una red social más. El problema fundamental es que en esa socialización LinkedIn está dejando de ser relevante para su masa de usuarios. Estas son solo algunas de las razones que ponen en evidencia la pérdida de valor del portal:

Las conexiones son irrelevantes. Las sugerencias de contactos se basan fundamentalmente en personas de nuestra propia empresa o de empresas en las que hemos trabajado anteriormente, pero resulta mucho más difícil encontrar contactos de nuestra profesión en otras empresas (algo sin duda mucho más interesante). Ocurre además que tras establecer una conexión de interés, rara vez se produce un intercambio de experiencias o ideas, precisamente porque la plataforma no ofrece ningún medio para ello. ¿El resultado? un simple engorde del número de conexiones sin ninguna utilidad real.

El sector tecnológico lo es todo. LinkedIn se ha posicionado claramente como una red para profesionales de IT. La explicación es sencilla si tenemos en cuenta el nuevo auge del sector tecnológico, con una demanda cada vez mayor de desarrolladores. Este factor se traduce en un número creciente de visitas (en otras palabras, impactos publicitarios) a contenidos y ofertas de este sector, relegando a un segundo plano al resto de contenidos.

Sin conexiones las publicaciones no tienen repercusión. LinkedIn da relevancia a los artículos y publicaciones de aquellas personas con mayor número de conexiones. Este hecho resulta obvio, pero tiene como consecuencia una pérdida del diferencial profesional de la red. La razón es que muchos usuarios buscan establecer conexiones con el único objetivo de incrementar el impacto de sus publicaciones, echando por tierra el valor profesional de estas conexiones, y de la plataforma en general.

El contenido de valor es casi inexistente. Si dejamos de lado las frases inspiradoras y célebres -repetidas hasta la saciedad-, los enlaces de autobombo, o las noticias que pueden encontrarse en cualquier otro sitio, los artículos jugosos o las actualizaciones que merecen la pena son casi inexistentes.

Instagramificación de la plataforma. En un intento por atraer un público más joven, LinkedIn ha introducido recientemente cambios que pretenden hacer más social su uso. El nuevo diseño, la aparición de las actualizaciones de estado, la incorporación de vídeo en directo o la ventana persistente de chat son muestras de ello. Pero es dudoso que LinkedIn consiga con esta estrategia atraer a un público más joven sin alienar su base existente de usuarios.

Titulitis y postureo. Estos son solo algunos de los títulos que podemos encontrar en esta red: Digital Transformer, Motivational Coach, Inno-Líder, Profesional 360°, Líder coach, Impulsor del bienestar integral, Über Tech Lead, etc.

Es difícil expresar la vergüenza ajena que provoca ver estos títulos en personas que -estoy seguro- son perfectamente válidas para realizar su trabajo, pero que no han dudado ni un instante en sumarse a la espiral de titulitis que inunda esta red. Lamentablemente, esta competición por el título más original esconde en no pocos casos la inseguridad de quien lo usa. Tampoco podemos pasar por alto el postureo de mostrar en el perfil un largo listado de grupos en los que jamás hemos hecho una aportación.

Me ahorro aquí muchas otras razones por las que pienso que el beneficio que se obtiene de LinkedIn es muy cuestionable, como el valor nulo de los endorsements, o una configuración de las opciones de privacidad intencionadamente abierta y confusa que consigue justo lo contrario: la falta de privacidad.


Pero si LinkedIn fuese solo eso, una red social más, no pasaría de un entretenimiento inocuo. Lejos de ser así, nuestra presencia (activa o pasiva) conlleva ciertos riesgos:

Privacidad. Exponemos una gran cantidad de información personal, sin que quede claro quién es el destinatario de esta información y qué uso se hace de ella. La sentencia resuelta recientemente por un tribunal de EE.UU. a favor de una empresa que comercia con nuestros datos en LinkedIn, pone en evidencia este peligro.

Sexismo. Las actitudes sexistas contra las mujeres dentro de la plataforma se están convirtiendo en habituales, y no son pocas las que reciben solicitudes de contacto con fines no profesionales. La orientación de este portal hacia el sector tecnológico (donde los hombres son una abundante mayoría) solo puede acrecentar este problema. Los últimos cambios en la red, con un giro evidente a lo social, no parecen ser la forma más adecuada de atajar un sexismo rampante.

Distracción. Las alertas sobre visitas a nuestro perfil, las actualizaciones de nuestra red de contactos y un largo etcétera de notificaciones, disminuyen nuestra capacidad de atención y concentración. Y lo que es peor, ponen en peligro nuestro propio desarrollo profesional. Como indica Carl Newport (autor de títulos como So good they can’t ignore you o Deep work) “el valor en la nueva Economía no está en nuestro número de seguidores o likes, sino en la capacidad para enfocarnos intensamente en nuestro trabajo y ofrecer un valor único”.

“¿Qué hacen los cazatalentos en LinkedIn?”

Una vez más, José Manuel daba en la diana con esta pregunta durante nuestra conversación. Y es que si el valor de la plataforma es dudoso para los candidatos, resulta aún más difícil entender qué hace un cazatalentos en LinkedIn. Antes de LinkedIn y la popularización de las redes sociales, estos profesionales creaban una base de datos de perfiles. El cazatalentos funcionaba así como un curator de los candidatos más adecuados para las distintas ofertas de cada cliente, alimentando su base de datos con nuevos candidatos y manteniendo reuniones para conocer mejor las inquietudes profesionales y objetivos de los mismos.

LinkedIn se ha convertido hoy esa base de datos, y las reuniones han dado paso al envío indiscriminado de mensajes desde las cuentas Premium de la plataforma. El listado casi infinito de posibles candidatos y la facilidad para contactar con ellos hacen de LinkedIn la solución más lógica. Pero si todo se reduce a dar de alta una cuenta Premium y usar las capacidades avanzadas de búsqueda y envío de mensajes, ¿para qué necesito contratar a una empresa de cazatalentos? ¿Cuál es el valor añadido? Bajo este nuevo paradigma, el cazatalentos ha pasado a convertirse en un intermediario, y si hay algo nos ha enseñado internet es que los intermediarios son prescindibles y quien sobrevive es quien aporta un valor añadido.

Maury Hanigan (@rethinkhiring), en su artículo How LinkedIn Fundamentally Ruined Recruitmentexplica en más detalle esta situación y apunta:

Lo que falta en la contratación en la era de LinkedIn es la conexión personal. Fue la profunda comprensión de los candidatos lo que hizo a los cazatalentos tan exitosos.

¿Qué hago yo en LinkedIn?

La mayoría de nosotros pensamos que mantener nuestra red activa nos deparará, más tarde o más temprano, el trabajo o proyecto soñado. Pero las posibilidades de que esto ocurra son extremadamente remotas. Si echo la vista atrás, me doy cuenta de que los cambios que han marcado mi carrera profesional han sido siempre fruto de una interacción en la vida real con otras personas. Los conocidos (o conocidos de conocidos) son casi siempre las casualidades que nos llevan a nuestro siguiente empleo o proyecto. No creo que LinkedIn sea una herramienta inútil, pero sí estoy convencido de que es un medio al que otorgamos mucha más importancia y tiempo del que merece.

Volviendo a la pregunta que abre este artículo, ¿es LinkedIn prescindible? Mi conclusión es que no es imprescindible. Si buscamos en Google una persona o empresa, es muy probable que uno de los primeros resultados sea un enlace a LinkedIn. Si estoy en una situación de búsqueda de empleo o pretendo dar a conocer mi empresa al mundo, desaprovechar el posicionamiento de esta plataforma en los motores de búsqueda carece de sentido. En cualquier otra circunstancia creo que su utilidad es muy limitada.

¿Puede LinkedIn convertirse en una red profesional verdaderamente útil? No pondría mis esperanzas en ello. Los cambios incorporados recientemente a la plataforma están claramente dirigidos a los millennials, que no parecen encontrar razones para crear o mantener un perfil en esta red. Es probable que estos cambios se traduzcan en una mayor cuota de usuarios a medio plazo, pero sin duda convertirán a LinkedIn un servicio aún más irrelevante. Los usuarios de mi generación (+40) ven cada vez menos sentido en este posicionamiento hacia lo social, y los más jóvenes necesitan establecer conexiones reales que les permitan acceder al mundo laboral y progresar en su carrera, no una mala copia de Facebook.

La catedral y el bazar

El cambio hacia modelos de desarrollo de software ágiles, con procesos continuos de integración y publicación de nuevas funcionalidades, nos obliga como redactores técnicos a revisar nuestros propios métodos de trabajo. Abandonar el modelo impuesto por el gestor de contenidos tradicional e integrar las tareas documentales en el ciclo de desarrollo es ahora más necesario que nunca.

La catedral y el bazar

En 1999, Eric S. Raymond -uno de los principales representantes de la iniciativa de código abierto- publicó su ensayo La Catedral y el Bazar. En este popular ensayo, Raymond relata su experiencia durante el desarrollo de software de código abierto, a la vez que anima a los programadores y empresas a adoptar esta filosofía de trabajo.

Raymond utiliza los conceptos de catedral y bazar para ejemplificar dos modelos de desarrollo bien diferenciados. La catedral representa el desarrollo de software propietario, donde el código fuente es accesible solo a un reducido grupo de programadores. Por el contrario, el bazar representa el desarrollo de software de código abierto, donde el código es accesible a colaboradores. La rigidez de una catedral sirve de metáfora de un sistema cerrado y centralizado, mientras que el dinamismo de un bazar representa un sistema abierto y colaborativo. Raymond defiende que la posibilidad de incorporar mejoras y eliminar errores es mucho más amplia en un modelo colaborativo que en uno centralizado. La conclusión es que el software resultante de un modelo colaborativo incorpora menos errores y es, necesariamente, de mayor calidad.

La tesis expuesta en La Catedral y el Bazar ha sido motivo de discusión entre defensores y detractores del software de código abierto. El modelo colaborativo no está exento de problemas, pero ofrece ventajas que lo hacen atractivo para muchas empresas de desarrollo. No resulta extraño ver cómo estas empresas buscan hoy fórmulas que les permitan adoptar metodologías propias del código abierto sin renunciar al control del código y de la propiedad intelectual del mismo.

Paralelamente, las herramientas de desarrollo de software incorporan cada vez más funcionalidades que permiten llevar los principios de desarrollo colaborativo a los equipos de trabajo. Unido a esto, el proceso de integración y entrega continua (conocido por las siglas en inglés CI/CD, o continuous integration/continuous deployment) permite publicar nuevas funcionalidades y solucionar errores con relativa rapidez. Pensemos solo en la frecuencia con la que se actualizan muchas de las apps en nuestros teléfonos móviles.

El problema con los gestores de contenido

Resulta extraño ver cómo este cambio en las metodologías de desarrollo ha tenido escasa repercusión en la documentación de software. Este campo sigue asentado en tareas de redacción, revisión y publicación que, en esencia, han cambiado poco en los últimos años. En la escritura, XML sigue siendo el lenguaje de marcado estándar. La revisión en muchos casos se realiza aún mediante archivos PDF o, lo que es peor, a través del correo electrónico. La publicación, que progresivamente ha pasado al medio web, requiere en muchos casos de horas de ajustes para generar el archivo PDF o HTML correcto.

Este flujo de trabajo está hoy sustentando por gestores de contenido (conocidos por las siglas en inglés, CMS) complejos, que pretenden resolver las necesidades documentales de muchas organizaciones a la vez, pero que terminan por no resolver enteramente las necesidades de ninguna.

Pero el problema fundamental reside en que el gestor de contenidos tradicional entiende las tareas de redacción, revisión y publicación como acciones que se suceden ordenadamente en el tiempo y no, como demuestra la experiencia, de forma conjunta. Como problema añadido, la posibilidad de incorporar mejoras por parte de los colaboradores está limitada a la fase de revisión, quedando la documentación efectivamente cerrada durante la mayor parte de su ciclo de desarrollo.

"Tira tu CMS"

En el año 2014 Patrick Arlt (@patrickarlt), en el marco de las conferencias Write the Docs, realizó la presentación Tira tu CMS (titulada originalmente Ditch Your CMS With Git and Static Site Generators). Arlt plantea en esta presentación abandonar el uso de gestores de contenido en favor de herramientas de código libre que favorecen la colaboración y reducen la complejidad del proyecto documental.

Un año después, en Abril de 2015, Anne Gentle (@annegentle), describía el proceso documental adoptado por el fabricante de software OpenStack en su artículo Git y GitHub para una documentación fuente abierta (originalmente, Git and GitHub for open source documentation). El modelo propuesto por Gentle -que posteriormente desarrollaría con más detalle en su libro Docs like code- propone al redactor técnico trabajar de manera conjunta con los equipos de desarrollo, adoptando las metodologías y herramientas de estos equipos. Porque si la documentación de un software es parte integral del producto y se realiza en paralelo, ¿no resulta más coherente que los flujos de trabajo sean los mismos? Bajo este nuevo paradigma, escribir documentación no dista mucho de escribir código.

En síntesis, la metodología Docs like Code propone:
  • Abandonar el uso de gestores de contenido tradicionales en favor de herramientas colaborativas como GitHub (un repositorio de código muy popular entre los desarrolladores).
  • Adoptar lenguajes de marca ligeros (del inglés, lightweight markup languages) como formato, abandonando lenguajes complejos como XML. El ejemplo más conocido de estos lenguajes es Markdown.
  • Incorporar procesos de revisión continuos donde los revisores puedan registrar cambios en cualquier momento mediante los mecanismos de pull-request ofrecidos por GitHub.
  • Publicar regularmente la documentación del producto mediante el uso de generadores estáticos de páginas, que permiten transformar los textos en formato Markdown en código HTML.


Millones de desarrolladores en todo el mundo usan GitHub como repositorio para el código de sus aplicaciones. Pero, ¿qué hace de GitHub un entorno tan atractivo para los aficionados, desarrolladores independientes y empresas? El éxito comercial de GitHub nace de su capacidad de simplificar el uso de la herramienta Git (una utilidad de software creada originalmente para gestionar el desarrollo de Linux) en una interfaz web fácil de usar. GitHub facilita además que múltiples personas pueden colaborar en un mismo proyecto de manera relativamente sencilla. La complejidad y diversidad del software actual convierten en imprescindible esta capacidad de la plataforma para escalar fácilmente.

Pero este cambio en los métodos de desarrollo de software no dista mucho de lo que ocurre en el ámbito de la documentación. Si en el pasado un manual era responsabilidad de un único redactor técnico hoy en día, con la creciente complejidad tecnológica y la integración continua de cambios, el resultado final precisa de la colaboración y coordinación de múltiples personas. El modelo de catedral impuesto por los gestores de contenido no ha sido capaz de dar respuesta a este cambio.

El momento es ahora

Lejos de ser solo un concepto, Docs like Code es también una realidad para empresas de software tan importantes como Microsoft, Amazon o Twitter. En Mayo de 2016 Jeff Sandquist (@jeffsand) anunciaba la nueva plataforma documental de Microsoft con las siguientes palabras:

Toda la documentación está diseñada para permitir contribuciones de la comunidad. Cada artículo incorporar un botón de edición que te dirige al fichero fuente de Markdown en GitHub, donde puedes crear un pull request para reportar un error o mejorar el contenido.

Una buena parte de la documentación del fabricante reside ya en esta nueva plataforma documental, en una clara apuesta por el uso de sistemas abiertos. Otras empresas como Amazon han seguido esta tendencia y hoy es posible ver el botón Editar en GitHub en muchos de los artículos destinados a desarrolladores.

El especialista en documentación y redactor técnico Tom Johnson (@tomjohnson) escribía en un artículo del blog I’d Rather Be Writing, en un comentario dirigido a la raíz del problema del uso de gestores de contenido:

No más cajas negras para gestionar tu contenido. No más sistemas caros y propietarios que mantener. No más formatos-de-salida-imposibles-de-ajustar. Puedes integrarlo todo de manera simple, fácil y barata.

La enorme influencia que estas empresas tienen en el mundo del software propiciará, más tarde o más temprano, la adopción de modelos documentales abiertos tipo bazar en detrimento de modelos rígidos tipo catedral. Si el desarrollo más efectivo y ágil del software es el resultado de un proceso colaborativo de integración y publicación continua, el proyecto documental tiene necesariamente que adaptarse a esta nueva realidad.

Por qué es difícil documentar errores

Documentar errores de software es una labor compleja. Los departamentos de soporte reclaman una gestión ágil y precisa de esta información que no siempre encaja bien con los flujos establecidos en otras tareas documentales. En este artículo expongo por qué los errores requieren un tratamiento diferenciado y propongo algunas ideas para mejorar su gestión documental.

El problema con los errores

El desarrollo de cualquier aplicación va necesariamente ligado a la aparición de errores. Cuando el número de posibles errores es pequeño -como ocurre, por ejemplo, con el software incorporado en muchos electrodomésticos modernos- su tratamiento se reduce a un breve apartado de resolución de problemas en la guía del usuario. En productos de software más complejos, la posibilidad de encontrar errores aumenta considerablemente. En su libro Code Complete, Steve McConnell, estima que la media de errores en la industria es de entre 15 y 50 errores por cada 1000 líneas de código. Cualquiera que sea la cifra final, puede llegar a ser muy alta si consideramos la extensión en líneas de código de muchos programas.

Tratar estos errores resulta complejo porque, como veremos más adelante, la naturaleza de este tipo de información es particular. Cuando el número de errores conocidos es pequeño, los redactores técnicos creamos una sección dedicada a la resolución de problemas en el propio manual del producto, o advertimos de la ocurrencia de problemas en forma de notas de texto. Pero el alcance de este planteamiento es limitado. Es, además, una solución que no contenta a nadie: los técnicos no tienen una forma directa de buscar esta información y los autores entendemos que funcionalidades y errores deben de ocupar sitios distintos en la documentación. Es por ello que muchos fabricantes de software diferencian entre funcionalidades y errores en su documentación. Vemos un ejemplo de ello en el área de soporte del fabricante Red Hat, donde estas dos áreas están claramente diferenciadas:

Otro ejemplo lo tenemos en la documentación de Microsoft, donde los contenidos de soporte (support) y funcionalidad de producto (library) son independientes:

Pero, ¿por qué resulta necesaria esta división?

Funcionalidades y errores

Hay 2 razones fundamentales que explican la separación entre la documentación de funcionalidades de producto y errores.

1. El origen y tratamiento de la información es distinto

Cuando describimos el funcionamiento de un software, los redactores técnicos lo hacemos en colaboración con el especialista (habitualmente un desarrollador o analista). La información facilitada por esta figura, junto con la documentación interna del producto (casos de uso, especificaciones de producto, wireframes, etc.) son la materia prima del artículo técnico. Nuestra función como redactores es destilar toda esta información y trasladarla a la documentación del producto de una manera ordenada.

Sin embargo, en el tratamiento de errores, el origen de la información reside en la figura del especialista de soporte. Él es -después del cliente- el primero en detectar y evaluar la gravedad del problema, y es también el primero en registrar los detalles del error en la herramienta de gestión de casos (en síntesis, una base de datos con los errores de producto reportados). A diferencia de lo que sucede con la documentación del producto, esta información no se encuentra ordenada, y puede ser difícil de encontrar por otros especialistas que trabajan con la misma herramienta. Solo la información de algunos de estos errores llega a la documentación final del producto como boletines de seguridad o artículos de soporte.

2. Los tiempos de publicación son distintos

La documentación de funcionalidades sigue un proceso de desarrollo constante, pero que viene pautado por la publicación de cada nueva versión del producto. Por el contrario, los errores se producen de forma intermitente durante todo el ciclo de vida del software. La información de soporte, por su propia naturaleza, requiere de un tratamiento ágil que le permita llegar al mayor número de especialistas de soporte posible. Esta diferencia en los ritmos de publicación explica también por qué funcionalidades y errores ocupan lugares distintos en la documentación del producto.

La siguiente tabla resume las diferencias entre uno y otro tipo de información:

Tratamiento de errores

Considerando estas diferencias ¿cómo podemos mejorar la gestión de errores en documentación? Propongo aquí dos ideas básicas.

1. Vincular el tratamiento de errores y funcionalidades

Salvo excepciones, son pocos los errores reportados que llegan a la documentación de usuario. En algunos casos, las herramientas de soporte no permiten extraer y analizar la información de una forma sencilla. En otros, no existen los flujos de trabajo para explotarla eficientemente. Este hecho resulta paradójico si pensamos en el valor que tiene esta información.

Sea cual sea la aplicación para la gestión de casos, debe permitir hacer búsquedas e, idealmente, puntuar (por ejemplo, a modo de like/dislike) el valor que cada caso tratado aporta para resolver un problema similar. El redactor técnico podrá así identificar los casos más consultados o mejor valorados internamente e incorporarlos a la documentación final del producto, que es ya accesible al usuario final. Los casos más críticos se publicarán como boletines de seguridad, mientras que los más populares se integrarán en área de soporte de la documentación (normalmente, en la base de datos de conocimiento o knowledge base).

Por último, la herramienta de gestión de casos usada por el especialista debe permitir realizar búsquedas en diferentes bases de datos y presentar un resultado unificado. Esto es esencial en grandes entornos, donde es común que cada área de soporte o país mantenga su propia solución.

La propuesta es, en definitiva, romper los silos de información y establecer flujos que permitan al redactor técnico descubrir los errores más comunes e incorporarlos, ya de una forma ordenada, a la documentación del producto.

2. Facilitar la creación de contenido de soporte

También se puede promover el desarrollo de nuevo contenido de soporte mediante plantillas de documento que el técnico pueda usar de forma sencilla. Elaborar estas plantillas no es complejo porque los artículos de soporte se ajustan a un patrón muy sencillo (normalmente Síntomas-Causa-Resolución). Los especialistas suelen agradecer estas iniciativas. Si el área de soporte puede generar la información en un formato predefinido, nuestra labor revisando, adaptando o traduciendo esa información será mucho más sencilla.

Desde hace varios años, Microsoft permite crear artículos en su Knowledge Base a cualquier especialista de soporte de la compañía. Este tipo de artículos, que pasan por un proceso de revisión interna antes de su publicación, abundan en la web del fabricante bajo el epígrafe de FAST PUBLISH (del inglés, publicación rápida):

Saber cómo tratar y gestionar la información de errores resulta más sencillo si entendemos las particularidades de esta información. Hemos visto que estas particularidades requieren de un tratamiento diferenciado pero no aislado. Bajo este escenario, los redactores técnicos debemos poner en marcha iniciativas que permitan mejorar el intercambio de información con el área de soporte.

Forma y función del artículo técnico: el meta-artículo

En la última parte de esta serie de tres (ver entradas anteriores aquí y aquí) sobre el desarrollo del artículo técnico, se introduce el concepto de meta-artículo como elemento funcional básico de la información. El meta-artículo constituye la pieza de unión entre el artículo técnico (la forma) y la tarea del usuario (la función).

El manual de usuario “electrónico”

El paso del manual de usuario físico a la documentación web que hoy acompaña a muchos productos de software no ha estado libre de problemas. Con la popularización del ordenador personal, y años antes de la generalización de internet, los fabricantes de software comenzaron a sustituir las ediciones impresas de sus manuales por versiones electrónicas. Los ficheros de ayuda de Windows se generalizaron como la forma más efectiva y económica de hacer llegar al usuario la documentación de producto. Los primeros manuales electrónicos, con un contenido escasamente enlazado y motores de búsqueda limitados, se convertían muchas veces en una mera copia digital del manual en papel.

Estos manuales de ayuda electrónicos -a los que el comunicador técnico Mark Baker llamó acertadamente frankenbooks- incorporaban todas las limitaciones de un libro físico, pero sin aprovechar ninguna de las ventajas del nuevo medio electrónico. La tabla de contenidos -y no la búsqueda- continuaba siendo clave en el descubrimiento de información y cada entrada se fragmentaba frecuentemente en múltiples subentradas. El resultado era un manual de ayuda electrónico con tablas de contenido extensas, difíciles de manejar y donde abundaban apartados con poca información.

El salto final desde el manual electrónico hasta el manual web ha obligado a los redactores técnicos a replantear la manera de agrupar y enlazar el contenido. El cambio en los patrones de lectura y descubrimiento de la información que trajo consigo internet hacen que organizar la información en la web siguiendo el modelo de libro físico carezca de sentido. Si la tabla de contenidos había sido hasta entonces un elemento fundamental, las capacidades de búsqueda en la web junto con estos nuevos patrones de lectura (que discutimos ya en el primer artículo de esta serie) convertían a este elemento en secundario.

Escritura técnica orientada al artículo

Junto con la transformación del manual de ayuda físico en manual en formato web, uno de los avances más importantes en el desarrollo de documentación técnica ha sido el paso al modelo de documentación orientada a artículos. Si anteriormente el redactor técnico trataba al manual como un todo, la tendencia ahora es, claramente, organizar el contenido en torno a bloques discretos de información a los que llamamos artículos. La popularización de modelos de información como el propuesto por la especificación DITA han cimentado esta transformación.

A pesar de este avance, modelos como DITA siguen sin dar respuesta a cómo los artículos, entendiendo estos como bloques primarios de información, se relacionan entre sí de forma lógica para el lector. De hecho, en la teoría de la escritura orientada al artículo, la agrupación de artículos se desaconseja o se considera que va en detrimento de la capacidad de asimilar información por parte de lector (en una palabra, de su usabilidad). Tal como expone el comunicador técnico Tony Self en su artículo Desarrollo de información basada en artículo (originalmente en inglés, Topic-based Information Development):
Los cambios en los patrones de lectura y adquisición de información sugieren que los lectores ya no quieren leer en profundidad textos largos y lineales. En su lugar, la investigación sugiere que quieren leer de forma superficial, y leer sólo el mínimo que les permita realizar una tarea. Las estructuras de información basadas en artículos son más apropiadas para estos lectores impacientes.
Pero si, como definen estos modelos, cada artículo representa únicamente un tipo de información (tarea, referencia, concepto, etc.), ¿no corremos el riesgo de volver a aquellos manuales electrónicos del pasado, con múltiples entradas aisladas y difíciles de manejar? ¿No tendría más sentido agrupar funcionalmente aquellos artículos relacionados entre sí, incluso aunque pertenezcan a categorías distintas?

El hecho de que los patrones de lectura y adquisición de información hayan cambiado con la aparición de internet no está reñido con la creación de contenido de mayor longitud. Muy al contrario. De hecho, la extensión de un artículo, por sí sola, no debería ser un criterio válido para fragmentar el contenido. Muchas entradas de la Wikipedia incluyen artículos extensos, lo que como lectores no nos impide navegar por su contenido en busca de la información o dato necesarios. Sin duda, esta organización resulta mucho más útil que presentar la información en bloques discretos y discontinuos, obligando al lector a moverse de un nivel de contenido a otro, y rompiendo el patrón de lectura habitual.

Modelo A frente a modelo B

Los modelos de desarrollo de información basados en DITA, en un empeño por maximizar la capacidad de reutilizar el contenido (uno de los principales objetivos de la escritura orientada a artículos) son incapaces de dar respuesta al modo en que estos bloques se agrupan (tanto es así, que algunos autores no consideran DITA como un verdadero modelo de información).

El modelo A (ver imágen) ejemplifica el modelo propuesto por DITA. Bajo esta concepción, cada tipo de artículo se presenta como un elemento final y reutilizable de información. El modelo B, por el contrario, plantea que los distintos artículos se combinan en elementos de mayor entidad, a los que me he dado en llamar meta-artículos. Si el artículo supone el elemento constructor de la información, el meta-artículo constituye el elemento funcional.

El modelo A aconseja aislar las tareas de autoría de las de presentación. En palabras de Tony Self:
El formato y presentación son consideración posteriores a la autoría, y actividades posiblemente no realizadas por el autor técnico.
Pero, ¿es esto cierto? En mi opinión, este planteamiento ignora que la presentación del contenido (el cómo se relacionan entre sí los diferentes tipos de artículos) condiciona en gran medida el acceso a la información por parte del lector. El redactor puede y debe aislarse de elementos formales como el uso de fuentes, colores, espacios entre párrafos, etc., pero no puede ignorar la estructura final del artículo.

El decidir entre un modelo u otro dependerá de factores que, como redactores técnicos, deberemos sopesar para cada tipo de contenido y audiencia. Veamos dos casos para ilustrar esta idea. Pensemos por un momento en una aplicación ofimática como Microsoft Word. Las preguntas que un usuario de esta aplicación puede plantearse se resuelven normalmente con una breve explicación (añadir formato a una tabla, compartir un documento, insertar una ecuación, etc.). En estos casos, la información de contexto resulta innecesaria porque el objetivo del usuario es muy específico y el número de posibilidades muy reducido. Pero pensemos ahora en una caso más complejo, como puede ser la instalación y configuración de un servidor web. El técnico que se enfrenta a esta tarea requiere una información de contexto suficiente para entender aquello que va a llevar a cabo y evitar errores comunes. ¿Tiene sentido aquí separar la tarea en sí de la información de contexto? Separando ambas (por ejemplo, en dos artículos enlazados) perdemos la posibilidad no solo de atraer la atención del lector, sino también de facilitarle la información necesaria en el lugar donde se lleva a cabo su acción.

Usabilidad frente a reutilización

El problema se reduce, por tanto, a cómo presentar el contenido al usuario de una forma que sea coherente con su flujo de trabajo, y que a su vez permita reutilizar la información. DITA no cierra la posibilidad de agrupar diferente artículos, pero advierte contra los peligros de hacerlo, como podemos leer en la propia especificación de DITA 1.2:
Los artículos pueden definirse dentro de otros artículos. Sin embargo, la unión requiere un cuidado especial porque puede dar lugar a documentos complejos que son menos utilizables [en el sentido de usabilidad] y reutilizables.
Como enfatiza Mark Baker, el problema es que DITA prioriza la posibilidad de reutilizar un contenido sobre la usabilidad del mismo. El argumento de que la agrupación de los artículos hace el documento menos usable no parece sostenerse. De hecho, si nos fijamos, la usabilidad de un documento (en otras palabras, la capacidad de ese documento de aportar la información relevante para la tarea del usuario) es contraria en muchos casos a las posibilidades de reusar el contenido. Pensemos en las imágenes o los vídeos. Aunque la tendencia es ahora la de incorporar cada vez más elementos gráficos en la documentación técnica, durante mucho tiempo este contenido fue relegado por los costes de producción asociados y su escasa reutilización. Pero, ¿es este un contenido usable? ¿Da soporte a la tarea en cuestión que el usuario realiza? Claramente, la respuesta es sí. Usabilidad y capacidad de reutilización son, en muchos casos, elementos contrapuestos.

El meta-artículo da respuesta a la necesidad de desarrollar documentación que sea a la vez usable y reutilizable, y comienza a estandarizarse como la forma más adecuada de hacer llegar la información técnica al usuario, especialmente en tareas complejas como las que se llevan a cabo en los departamentos de IT.

Céntrate (o cómo sobrevivir en un mundo de distracción)

Vivimos expuestos a un asalto constante de estímulos y notificaciones que, minuto a minuto, se apoderan de nuestra atención. Esta atención, necesaria para avanzar en nuestra carrera y en nuestra vida, se ha convertido en un bien escaso. Recuperar el terreno perdido no es una tarea fácil.


Observa tu respiración. Obsérvala por un instante. La mayoría de nosotros, al trabajar con la pantalla de nuestro ordenador o teléfono móvil, retenemos inconscientemente la respiración en un acto que la escritora Linda Stone bautizó como apnea del correo electrónico (originalmente, email apnea). Este hecho, aparentemente inocuo y que repetimos cientos de veces a lo largo del día, no pasa inadvertido para nuestro organismo. En su artículo Just Breathe: Building the case for Email Apnea (Solo respira: Argumentos acerca de la apnea del correo electrónico) publicado en Agosto del 2008, Stone describe en detalle algunas de las consecuencias que a largo plazo puede tener este comportamiento sobre nuestra salud. No resulta extraño que una de estas consecuencias sea el estrés y las enfermedades derivadas del mismo.

Dejando de lado el factor puramente biológico, la respiración juega un papel determinante en nuestra capacidad de atención y concentración. Las técnicas de mindfulness y meditación se basan en gran medida en un reaprendizaje y control consciente de la respiración. Estas prácticas, cada vez más populares y demandadas, llegan a la sociedad occidental como herramientas para conseguir una vida más centrada en cada momento y más plena. No son necesarias grandes dotes de observación para darse cuenta de cómo las actividades de nuestro día a día nos sitúan justamente en el extremo opuesto.

La meditación ha dejado ya de tener el estigma de práctica mística que se le atribuía hace solo unos años. Los cursos de meditación y mindfulness se han popularizado y cada vez es mayor el número de personas que incorporan estas herramientas con normalidad en su vida. La aceptación y difusión de estos recursos ha sido notable en estos últimos años, algo que solo se puede explicar como la respuesta de nuestra sociedad a una creciente ansiedad y dispersión de nuestra atención.

Una respiración controlada y consciente, como la que se realiza durante la meditación, mejora nuestra capacidad de atención y fija el marco para un desarrollo cognitivo sano, como puede concluirse de los resultados de diferentes estudios y meta-estudios. En palabras de la propia Stone, “en el corazón de la atención deliberada se encuentra la respiración deliberada. Respiración, atención y emoción, son conmutativas”.

Atención y productividad

En una sociedad donde las interrupciones son casi constantes, la atención se ha convertido en un recurso escaso. Como explica el filósofo Byung-Chul Han en La sociedad del cansancio (Edit. Herder, 2016), el exceso de estímulos, informaciones e impulsos “modifica radicalmente la estructura y economía de la atención”, y nos reduce a máquinas capaces de reaccionar a cualquier estímulo pero incapaces de reflexionar sobre sus propias acciones. Han señala además lo contradictorio de que esta fragmentación de nuestra capacidad de concentración se produzca precisamente en una época en la que “el aumento de la carga de trabajo requiere una particular técnica de administración del tiempo y la atención”.

Solo necesitamos echar un vistazo a nuestro alrededor para darnos cuenta de esta realidad. Contestamos a los correos electrónicos en el tren y el metro, interrumpimos cualquier tarea para revisar la última notificación de nuestros teléfonos móviles y pasamos frenéticamente de una reunión a otra -revisando más notificaciones por el camino- sin apenas tiempo para sacar conclusiones de aquello que hemos discutido. Este estado, que Han describe como “pura agitación que no genera nada nuevo, [solo] reproduce y acelera lo ya existente” es aceptado hoy como símbolo de productividad. Asumimos que todo aquello que nos mantiene alerta y ocupados nos hace productivos, sin pararnos a pensar en cómo repercute toda esta actividad en nuestras vidas, y llegamos al absurdo de afirmar que la ansiedad y el estrés son beneficiosos porque nos mantiene alerta y nos hace máquinas de trabajar más eficaces.

En esta situación, no resulta extraño que aquellas tareas que requieren un esfuerzo mental ininterrumpido y durante varias horas queden relegadas siempre a un segundo lugar, justo porque en ese estado de agitación solo podemos reaccionar a la crisis del momento, al último correo electrónico o a la última notificación. Nos hemos acostumbrado a ver como un hecho normal perder dos terceras partes de nuestra jornada laboral en la bandeja de entrada. Ponemos todo el énfasis en tareas puramente mecánicas como reuniones, trabajo administrativo o almacenar y compartir información, convirtiéndonos así en el animal laborans -eficiente pero irreflexivo- que la filósofa Hannah Arendt describe en La condición humana (Edit. Paidós, 1993). La actual cultura del trabajo promueve y ejemplariza esta falsa productividad provocando que para muchas personas esta actividad febril sea la única forma de demostrar su valor en la empresa. La dispersión y la multitarea son ahora la norma, pero ¿a qué coste? El estrés es solo uno de los subproductos que trae consigo la sociedad del animal laborans. La desilusión, la insatisfacción, el miedo al fracaso y en último término, la depresión, son también consecuencias naturales.

Hemos dejado de lado la reflexión necesaria para el desarrollo de nuestras capacidades y el verdadero progreso en nuestra vida y nuestra profesión. Mindfulness significa conciencia plena, y supone un estado mental en el que nuestra voluntad está dedicada enteramente a una actividad y no se ve interrumpida por ninguna otra cosa. Y es solo en este estado de atención donde la productividad bien entendida se manifiesta.

Trabajo profundo

Para el profesor Carl Newport, autor de varios libros sobre técnicas de estudio y productividad personal, el salto de una actividad profesional mediocre a una sobresaliente solo puede venir dado por la dedicación consciente y focalizada de nuestro tiempo. Esta dedicación, a la que el autor llama trabajo profundo (originalmente en inglés, deep work) require una gran fuerza de voluntad y un elevado esfuerzo. El trabajo profundo no es divertido, pero es la única forma de obtener avances verdaderos en aquello a lo que nos dedicamos. Como explica el propio autor en su libro Deep Work (Piatkus Pub., 2016), “si no has dominado esta habilidad fundamental [del trabajo profundo] tendrás dificultades para aprender cosas complejas o producir a un nivel superior” (2016, p.32) .Las afirmaciones de Newport nos llevan inevitablemente a un reflexión y un replanteamiento de nuestra forma actual de trabajar o estudiar.

Esta reflexión está en consonancia con lo apuntado por Geoff Colvin en Talent is overrated (El talento está sobrevalorado. Portfolio-Penguin Pub., 2008). En el estudio The role of deliberate practice in the acquisition of expert performance (El papel de la práctica deliberada en la adquisición de un rendimiento de élite. KA Ericsson, RT Krampe, C Tesch-Römer. Psychological review 100 (3), 363) llevado a cabo con varios violinistas de un prestigioso conservatorio alemán y ampliamente comentado por Colvin en su libro, se pone de relieve que el factor decisivo para diferenciar a los buenos violinistas de los mejores no es tanto las horas de práctica como las horas de lo que los autores del estudio llaman práctica deliberada. Se entendiende por deliberada aquella práctica repetida en el tiempo, que supone un elevado esfuerzo intelectual y que requiere de toda nuestra capacidad de atención. En definitiva, alcanzar las metas deseadas en cualquier actividad no pasa solo por dedicar más tiempo a esa actividad sino también por dedicar un tiempo de mayor calidad. Se rompe así con la afirmación -basada precisamente en el mismo estudio de Ericsson, Krampe y Tesch-Römer- del escritor Malcolm Gladwell en Fuera de serie (Ed. Taurus, 2009 y publicado originalmente en inglés como Outliers), donde se afirma que para sobresalir en una actividad son necesarias al menos 10.000 horas de dedicación. La excelencia en cualquier campo no está determinada tanto por la cantidad, como por la calidad de nuestro tiempo.

Lo cierto es que existe una relación entre la atención, la calidad del tiempo de trabajo y nuestra motivación. Poner toda nuestra atención en aquellas actividades que consideramos importantes en nuestra vida o en nuestra profesión se traduce en un tiempo de mayor calidad (trabajo profundo). Este tiempo es precisamente el que nos permite progresar cualitativamente en estas actividades y a su vez nos motiva para seguir realizándolas. Como apunta Newport, conseguir la concentración necesaria para un tiempo de calidad  nunca ha sido sencillo, pero las empresas de medios y redes sociales han hecho nuestra labor mucho más difícil. El bombardeo constante de noticias y notificaciones resulta demasiado atractivo y el temor a “perderse algo” demasiado angustioso. Saber reconocer estas situaciones y actuar contra ellas es fundamental.

Consejos para una vida más centrada

Internet y las mejoras en inteligencia artificial y robótica han hecho obsoletos muchos tipos de trabajo tradicional. Pero la realidad es que una gran mayoría de los trabajos que realizamos hoy en día no pueden ser reemplazados por máquinas o por un software. Y no pueden serlo fundamentalmente porque el valor que aportamos como individuos se realiza en un nivel cognitivo que no puede ser programado en un software. En un mundo laboral contradictorio, donde las empresas buscan la uniformidad del individuo a la vez que reclaman innovación, el trabajo deliberado y profundo en nuestra actividad profesional puede convertirse en el factor diferenciador. Este trabajo no es divertido, pero como apunta Colvin “tiene que ser así. Si las actividades que llevan a la excelencia fueran fáciles y divertidas entonces todo el mundo las haría y no se distinguiría a los mejores del resto”. Pero, ¿qué estrategias podemos poner en marcha que nos permitan avanzar verdaderamente en nuestra profesión?

Organiza tu tiempo

Enfocar nuestra vida en aquello que de verdad importa y evitar las distracciones requiere una planificación. Diariamente debemos luchar contra todas aquellas cosas que reclaman nuestra atención: redes sociales, notificaciones, televisión, videojuegos, etc. Nuestra mejor arma en esta lucha es nuestra voluntad y nuestro calendario. Si de forma rutinaria bloqueamos horas en nuestra agenda para reunirnos con otras personas, ¿por qué no bloquear tiempo para reunirnos con nosotros mismos? Si necesitas tiempo para pensar en esa importante presentación, en ese nuevo plan de márketing o en la solución para el problema que lleva meses persiguiéndote, bloquea el tiempo necesario en tu calendario para estas tareas. Bloquea ese tiempo y comprométete a cumplirlo de la misma forma que lo harías en una reunión con otra persona.

Una objeción común para no llevar a cabo esta práctica es que las actividades del día a día no permiten bloquear el periodo de tiempo enfocado e ininterrumpido necesario. Resulta paradójico, sin embargo, que en esa escasez de tiempo, sí hemos sabido encontrar el hueco para dedicar varias horas a las pantallas de nuestro teléfono móvil o televisor en una distracción que mucha veces resulta vacía.

Reduce la ingesta de información

En su libro The information diet (La dieta informativa. O'Reilly Media, 2012), Clay A. Johnson compara la información que recibimos y consumimos actualmente con la comida basura. Esta información no está hecha para hacernos conscientes de la realidad del mundo a nuestro alrededor sino que, de forma análoga a la hamburguesa de las cadenas de comida rápida, es fabricada por los grandes medios de comunicación para ser de apetitosa, de rápido consumo y -sobre todo- adictiva.

El consumo constante de información convenientemente procesada no solo distorsiona nuestra capacidad de concentración, también reduce nuestra tolerancia a medios que requieren un mayor esfuerzo intelectual. El propio Johnson relata así este hecho en su libro: “hace algunos años, me encontré completamente incapaz de leer más allá de mil palabras. No había manera de que pudiera leer un artículo extenso o un libro. El concepto de leer de un libro, mucho menos escribir uno, era completamente ajeno a mí”.

Optar por una dieta informativa supone, ante todo, cambiar la relación que mantenemos con nuestro teléfono móvil. Acciones tan sencillas como eliminar aplicaciones, borrar nuestra presencia en redes sociales, o sustituir algunas horas de televisión y YouTube por un libro favorecen nuestra capacidad de atención a largo plazo y disminuyen progresivamente nuestra dependencia del teléfono móvil. Especialmente en lo referente a redes sociales, resulta inquietante cómo en apenas unos pocos años estos servicios se han adueñado por completo de nuestros días. Pensemos por un momento si la forma en la que empleamos nuestro tiempo es la que queremos y la que nos hace sentir bien.


Afortunadamente, practicar la meditación ya no es visto como algo esotérico y está cada vez más normalizado. La meditación proporciona, entre otros muchos beneficios que están ampliamente documentados, un aprendizaje de técnicas respiratorias y una mejora de la capacidad de concentración que son claves para la ejecución del trabajo profundo.

Aprender a meditar es, además, sencillo y no requiere de ningún equipo, instalación o material especial aparte de nuestra voluntad para llevarlo a cabo. Aunque existen muchas aplicaciones para iniciarse en el mundo de la meditación y el mindfulness, mi recomendación es no utilizar estas aplicaciones como punto de partida. Existen multitud de centros que imparten cursos y organizan monográficos sobre estas técnicas donde encontraremos un asesoramiento adecuado. Iniciarnos en estas prácticas con otras personas nos permitirá también compartir experiencias y ver con mayor normalidad estas actividades.

Practica el trabajo profundo

El trabajo administrativo al que nos enfrentamos hoy en día no parece tener fin. Podríamos estar trabajando durante días sin agotar todas las tareas administrativas que se nos demandan. Pero es justamente este trabajo administrativo el que nos impide desarrollarnos en nuestra profesión. Como apunta Newport, la única escapatoria que tenemos los trabajadores es la de ser conscientemente irresponsables: decir no a ciertas reuniones, no a ciertas actividades y no a ciertos correos electrónicos. En definitiva, convertir el trabajo profundo en la prioridad y no en algo que nunca llegamos a realizar por falta de tiempo.

Bloquea periodos de tiempo ininterrumpidos de 2-3 horas en la tu agenda para pensar y profundizar en aquellos temas que resultan importantes en tu profesión -o en tu vida. Comprométete a emplear este tiempo enteramente en la actividad en cuestión, dejando de lado cualquier posible distracción. Y si la cultura de la empresa o el puesto de trabajo no nos permite realizar las acciones que nos hacen avanzar profesionalmente, es quizás el momento de plantearse si estamos en el mejor sitio para desarrollar nuestra carrera.

Planificar el contenido en el artículo técnico

Si en el primer artículo de esta serie se mostraba cómo dotar de estructura al documento técnico, en este segundo se describe un método para planificar su contenido. Como en cualquier otra labor con un cierto grado de complejidad, una preparación adecuada nos ahorrará tiempo durante el desarrollo del contenido e influirá positivamente en la relevancia del documento final.

Forma y función en el artículo técnico

La calidad de un artículo técnico depende de muchos factores, algunos de los cuales suelen encontrarse fuera de nuestro control. Si la herramienta de edición es excesivamente compleja o restrictiva, o si el gestor de contenidos dificulta las tareas de distribución y revisión, es poco lo que el redactor técnico puede hacer para superar estos obstáculos. Pero la calidad final del artículo depende, ante todo, de su capacidad para empatizar con la tarea el usuario y proporcionarle la información necesaria -o el acceso a otra información cuando la nuestra ya no es de interés. Y es justo aquí donde más puede aportar el redactor.

Mientras que en la entrada anterior de este blog se trataba la estructura del documento (su forma), esta se centra en el contenido (su función) o más concretamente, en la planificación de ese contenido. En documentación técnica la separación entre forma y función es puramente formal, ya que en la práctica ambos aspectos están íntimamente ligados. Vimos ya que la estructura de un documento es esencial en la búsqueda y el descubrimiento de la información por parte del usuario, pero una vez hemos captado su atención es imprescindible mostrar datos relevantes en el contexto de su tarea.

También se ha discutido la importancia de que los manuales describan tareas, y no interfaces. Debemos desterrar la idea de que la principal función de un manual es explicar minuciosamente la interfaz y opciones de un producto, dejando siempre al usuario la difícil labor de entender cómo encaja esa información en su tarea. Si hasta no hace mucho tiempo era habitual basarnos en la descripción de las pantallas y opciones para redactar un documento técnico, ahora debemos preguntarnos ¿es esto lo que el usuario necesita?

Estas descripciones -este contenido- siguen teniendo su lugar en la documentación, pero no como eje central de la misma, sino en la forma de artículos de referencia a los que el usuario pueda acceder desde la descripción de la tarea. Del mismo modo que las notas al pie y referencias de un libro nos ayudan a completar y entender mejor la historia, pero no sustituyen la historia en sí. La documentación técnica que no sustenta las acciones del usuario es, en gran medida, responsable de la mala fama que tienen los manuales entre muchos usuarios.

Etapas en la planificación de contenido

He dividido la planificación de un artículo técnico en 4 etapas, que pueden resumirse gráficamente de la siguiente forma:

Para cada etapa, se indican a continuación las herramientas recomendadas, los materiales de trabajo, el resultado esperado y las acciones correspondientes en esa fase.

Etapa 1: Analizar las tareas del usuario

Herramientas: Pizarra o software para elaborar mapas conceptuales (también llamados mapas mentales).

Materiales de trabajo: Ámbito de la tarea, especificaciones del producto, prototipos (lo que comúnmente se conoce como mockups o wireframes), entrevistas con usuarios y cualquier otra fuente de datos que podamos tomar como punto de partida.

Resultado: Mapa conceptual con análisis de tareas.


  • Analizamos las distintas tareas que el usuario puede completar con el software en el contexto que se quiere documentar.
  • Definimos las tareas más genéricas primero, y las más específicas después.
  • El análisis se hace sobre la base del flujo de acciones del usuario, no de las pantallas y opciones del software.
  • El foco aquí son las tareas y sus relaciones, no la jerarquía de las tareas.

Etapa 2: Definir los artículos que integran el documento

Herramientas: Pizarra o software para elaborar mapas conceptuales.

Fuentes de trabajo: Mapa conceptual con análisis de tareas (etapa 1).

Resultado: Mapa conceptual estructurado con análisis de tareas


  • Tomamos como referencia los 4 tipos de artículos definidos para categorizar cada una de las entradas que conforman el mapa conceptual.
  • Usamos un tipo de artículo para cada entrada.
  • Modificamos el mapa conceptual dividiendo o juntando elementos cuando sea necesario para adaptarlos a alguno de los 4 tipos.

Etapa 3: Crear la tabla de contenidos

Herramientas: Pizarra y editor de textos.

Fuentes de trabajo: Mapa conceptual estructurado (etapa 2).

Resultado: Tabla de contenidos.


  • Creamos una tabla de contenidos que reflejará la estructura final del documento.
  • El foco aquí es la agrupación lógica de conceptos y la jerarquía.
  • Si es preciso, cambiaremos la estructura de la tabla de contenidos durante el desarrollo del contenido (esta fase es iterativa).
  • Evitaremos exponer más allá de dos niveles en la tabla de contenidos. Es decir, nivel 1, nivel 2 y también nivel 1.1 y 1.2, pero no niveles 1.1.1, 1.1.2, etc.

Etapa 4: Desarrollar el contenido

Herramientas: Herramienta de edición o gestor de contenidos.

Fuentes de trabajo: Mapa conceptual estructurado (etapa 2) y tabla de contenidos (etapa 3).

Resultado: Borrador o documento técnico final.


  • Desarrollar nuevo contenido para cada artículo definido en la fase anterior.
  • Reutilizar secciones que son comunes a distintos artículos (como por ejemplo, explicar las acciones en la interfaz del usuario para abrir una aplicación o ejecutar un comando).
  • Actualizar la tabla de contenido si es necesario durante del desarrollo (esta fase es iterativa).

Durante la planificación, la tendencia es imaginar en nuestra cabeza el aspecto final del documento. Esto nos lleva a poner excesivo énfasis en la tabla de contenidos. Pero la propuesta aquí es precisamente no pensar en términos de tabla de contenidos hasta bien avanzado el análisis de las tareas. La tabla de contenidos nos limita porque solo nos permite movernos en dos dimensiones: de arriba hacia abajo, añadiendo nuevas entradas o de izquierda a derecha, añadiendo profundidad a cada entrada; pero durante el análisis inicial nuestro cerebro trabaja en múltiples direcciones, no solo en dos.

No he mencionado deliberadamente los integrantes de cada etapa porque estos dependerán del proyecto. En proyectos de gran envergadura, la colaboración de los equipos de diseño y usabilidad, analistas y desarrolladores, formadores y equipos de soporte técnico es fundamental y puede facilitarnos el análisis de las primeras etapas. En proyectos menores, como los desarrollados por el redactor técnico ocasional, es normalmente una sola persona quien lleva a cabo todo el trabajo.

El mapa conceptual como herramienta de análisis

Precisamente porque la tabla de contenidos nos limita en el desarrollo de ideas, resulta más eficaz usar mapas conceptuales en las fases iniciales de planificación. Estos mapas, ideados originalmente por Tony Buzan, son una representación gráfica de ideas que se van añadiendo -a modo de ramas de árbol- a partir de un concepto central. Cada una de estas ideas puede dividirse a su vez en otras de menor entidad, pasando así de los conceptos más generales en el centro del mapa a los más específicos en la periferia.

En nuestro caso el centro del mapa estará ocupado por el tema sobre lo que vamos a escribir (normalmente, una nueva funcionalidad del software). A partir de este elemento central vamos dibujando otros que representan las acciones que el usuario puede realizar con el software. Vemos que, a diferencia de la tabla de contenidos, el mapa conceptual se adapta mejor a la forma de pensamiento durante la fase de ideación al permitir desarrollar y enlazar elementos libremente.

Quien no haya utilizado antes los mapas mentales puede sentir la tentación de pasar por alto este sistema. Mi recomendación es no hacerlo. La conveniencia de usar este método frente a otros se encuentra ampliamente documentada, su aprendizaje es rápido y la inversión en tiempo se verá compensada con creces. Tampoco es necesaria ninguna herramienta especial, podemos usar un cuaderno, una pizarra o etiquetas adhesivas. Podemos también usar uno de los muchos programas que existen para elaborar mapas conceptuales, aunque no importa lo rica en funcionalidades que sea la aplicación de software, siempre nos limitará en mayor medida que una pizarra durante el análisis. Una vez el mapa mental está ya maduro, podemos utilizar un programa para almacenarlo digitalmente, editarlo y compartirlo.

La última entrada de esta serie tratará con mayor detalle el concepto de artículo. Veremos cómo los 4 tipos descritos (concepto, referencia, tarea y resolución de problemas) puede relacionarse entre sí para dar lugar a elementos de mayor entidad a los que llamaré meta-artículos. El meta-artículo constituye la pieza de unión entre el artículo (la forma) y la tarea del usuario (la función).

Organizar la información en el artículo técnico

La estructura del artículo técnico tiene un papel clave en la búsqueda y descubrimiento de información por parte del lector. Los artículos deben mostrar elementos comunes que den soporte a esta búsqueda, pero también elementos diferenciadores que permitan identificar si la información es relevante en el contexto de la tarea.

Estructura y búsqueda de información

Cuando analizamos a los usuarios -o a nosotros mismos- utilizando documentación técnica, observamos que el patrón de lectura dista mucho de el que el lector adopta con una novela. Inicialmente, con un vistazo general a la estructura, juzgamos ya si la información que contiene el documento responde o no a nuestras necesidades. Una vez hemos decidido que la información que tenemos delante puede sernos útil, hacemos un análisis -aún muy superficial- de elementos como títulos, listados, imágenes o tablas. Solo entonces centramos nuestra atención en párrafos o elementos particulares que consideramos relevantes. Este análisis está en sintonía con lo que Nielsen describió como information foraging (literalmente, tratar la búsqueda información como la búsqueda de alimento o forraje por parte de un animal).

Este mecanismo de búsqueda y descubrimiento, aparentemente errático, sigue un patrón determinado muy similar al que empleamos al leer cualquier otro tipo de información en internet. De esta observación podemos concluir que no basta con que la información sea completa y correcta, es necesario además que su estructura permita identificar dónde está el contenido de interés -informacion suculenta, siguiendo con la idea de Nielsen- mediante una organización predecible y sencilla. Recordemos que la documentación no busca entretener al lector, sino facilitarle el acceso a la información en sus propios términos.

Especialmente en el caso del redactor técnico accidental -aquel cuya principal tarea no es la redacción técnica-, la experiencia y las herramientas que permiten organizar adecuadamente la información no siempre están disponibles. Este artículo, el primero de una serie de tres, propone una forma estandarizada y sencilla de estructurar un texto técnico, independientemente del método y herramienta de desarrollo.

Tipología del artículo técnico

La clasificación que aquí se presenta está basada en DITA, una especificación XML muy popular en el desarrollo de documentación. Pero esta clasificación no pretende llegar al nivel de complejidad y detalle que alcanza DITA sino, bien al contrario, servir de referencia rápida y accesible para el redactor.

Al analizar diferentes artículos técnicos, observamos que la inmensa mayoría responden a uno de los siguientes tipos:

  • Concepto
  • Tarea
  • Referencia
  • Resolución de problemas

Estos 4 tipos constituyen la base sobre la que se articula la información. No entraremos aquí en cómo estos elementos se combinan entre sí para construir artículos de mayor entidad. Esta explicación se deja para el último artículo de la serie, donde se desarrolla en más detalle el concepto de artículo. Es suficiente con decir ahora que la mayoría de los escritos técnicos resultan de combinar estos tipos. Veamos un ejemplo. Supongamos que nuestro encargo consiste en redactar un artículo sobre cómo configurar una solución de alta disponibilidad para un sistema en el que nuestro departamento de IT está trabajando. El texto final podría tener el siguiente esquema:

  1. Introducción a la solución de alta disponibilidad (concepto).
  2. Explicación sobre el modo de instalación y configuración (tarea).
  3. Lista de comandos especiales para operar la solución (referencia).
  4. Problemas más comunes (resolución de problemas).
Vemos en este ejemplo que el trabajo final está conformado por los 4 tipos de artículos descritos, siguiendo un orden lógico de acciones.

Elementos básicos del artículo

Cada tipo de artículo está compuesto por un conjunto ordenado de elementos. Varios elementos son comunes a los 4 tipos, otros son particulares. El siguiente esquema muestra los elementos comunes:

Los elementos con un asterisco (*) son necesarios en la estructura del artículo, mientras que aquellos con un signo de cierre de interrogación (?) son opcionales. El siguiente listado es una descripción de los elementos comunes:

  • title: título del artículo.
  • shortdesc: breve introducción a la información que se va a tratar en el artículo. Puede ser una frase o un párrafo.
  • keywords: términos o palabras clave en el artículo que son normalmente empleados por los motores de búsqueda.
  • toc: tabla de contenidos. Aunque opcional, es recomendable en artículos extensos compuestos por varias partes.
  • body: representa el cuerpo del artículo, donde se encuentra la información que lo compone (texto, imágenes, tablas, listas, etc.). El elemento body marca la diferencia entre los distintos tipos de artículo.
  • related-links: enlaces a otros artículos relacionados.
Veamos ahora con más detalle los 4 tipos de artículo mencionados.


El concepto proporciona la respuesta a la pregunta Qué es. Este tipo de artículos presenta la información necesaria para entender otros conceptos o realizar una tarea. Es común incluir este tipo antes de explicar tareas complejas o que requieren información de contexto para poder ser completadas. Un artículo de este tipo muestra la siguiente estructura:

En este caso el contenido se desarrolla dentro del elemento descbody. El concepto es además el único tipo de artículo que puede incluir todos los demás tipos. Un ejemplo esquemático de este artículo sería el siguiente:


La tarea da respuesta a la pregunta Cómo. Este tipo de artículo muestra paso a paso cómo completar una acción determinada. Los artículos que describen tareas incluyen los siguientes elementos:

Como podemos ver en la imagen, las tareas pueden a su vez incluir otras tareas. El contenido particular de este artículo se encuentra en el elemento taskbody. Cada tarea se compone de una serie de pasos ordenados (steps) que pueden venir o no precedidos de uno o más requerimientos (req). Los requerimientos hacen referencia a otras acciones que han de completarse con anterioridad o a materiales necesarios durante el proceso.

El artículo debe contener la información necesaria sin extenderse en explicaciones. Un error común es el de incluir información en la descripción de la tarea. En la medida de lo posible, esta información debe desarrollarse en el artículo de tipo concepto. Este artículo muestra la siguiente estructura:


Una referencia incluye un listado de opciones y parámetros que son útiles para completar una tarea o para usar una función específica de un software. Ejemplos de referencia son los artículos donde se muestran las opciones de un comando, los parámetros de configuración de un determinada aplicación o la descripción de una API (interfaz de programación de aplicaciones). En muchos casos se utilizan tablas o listados para presentar la información. Estos elementos se incluyen en el apartado refbody. Los artículos de referencia se componen de los siguientes elementos:

Al igual que ocurre con las tareas, un mismo artículo puede contener varias referencias, aunque los artículos de referencia demasiado extensos son difíciles de usar incluso con una tabla de contenidos. El artículo de tipo referencia atiende la siguiente estructura general:

Resolución de problemas

El artículo de resolución de problemas detalla información de un problema o error en el software. La información debe permitir al lector identificar el problema con el que se encuentra (symptoms), entender las causas que lo originan (more-info) y mostrar los pasos requeridos para eliminar o mitigar el problema (tasks). Este tipo de artículo se caracteriza por incluir los siguiente elementos:

y muestra la siguiente estructura general:

Tanto la clasificación como los elementos discutidos aquí son comunes a una gran cantidad de documentos técnicos. No se busca en ningún caso ofrecer un planteamiento original, precisamente porque las estructuras familiares y comúnmente aceptadas son clave en el descubrimiento y consumo de la información.

El manual no es un hotfix

La documentación de software es un recurso esencial para el usuario -tanto más cuanto mayor es la complejidad de ese software-, pero que el propio usuario entiende como su último recurso. Desde esta observación resulta fácil comprender por qué la solución a los errores de un producto de software tienen que darse en el propio producto y no en su documentación.

La escritura no puede solucionar el mal diseño

En su artículo Writing can’t fix bad design (La escritura no puede solucionar el mal diseño), Beth Aitman muestra el ejemplo de una puerta automática con un mecanismo de cierre tan confuso que se acompaña de instrucciones para su manejo. La autora utiliza este ejemplo para explicar por qué cuando el diseño de un producto no es acertado la solución no es explicar cómo usarlo. La solución es arreglar el diseño. Basta con prestar un poco de atención a nuestro alrededor para descubrir casos similares donde el diseño enrevesado de un objeto se intenta solucionar arrojando información al usuario. Desde parquímetros con un largo listado de instrucciones de uso hasta puertas donde nunca parece estar claro el sentido de giro, el mundo está lleno de ejemplos de mal diseño.

No solo coincido plenamente con el análisis de la autora, sino que además creo que el mismo argumento se puede trasladar fácilmente a un producto de software y a los errores que se derivan de su desarrollo. Si exceptuamos los problemas graves (por ejemplo, de seguridad) donde la velocidad para informar a los usuarios es crucial, dar solución a un problema con un producto en un documento no es una buena opción.

Y no hablamos solo de errores en el código, que afectan al funcionamiento del programa, sino también de aquellos que afectan a su uso. Porque una usabilidad mediocre quizá no nos impida continuar con nuestra tarea, pero puede dificultarnos innecesariamente la misma, como ocurre cuando la disposición de botones en una interfaz no sigue un orden lógico y nos obliga a pararnos para entender su funcionamiento. Esto es lo que en desarrollo de software se ha dado en llamar error estético -un nombre desafortunado, porque reduce la usabilidad a un aspecto puramente ornamental.

La gente lee novelas

La gente lee novelas. No lee documentación. -Mark Baker
En el momento de utilizar un programa de software por primera vez, el usuario no recurre a la documentación, sino que intenta descubrir el funcionamiento del mismo basándose en su experiencia previa con programas similares y en las indicaciones que le da la interfaz. Normalmente, el usuario solo recurre a la documentación en dos situaciones: cuando encuentra un error o cuando no es capaz de completar una tarea. Para el usuario la documentación es un recurso necesario, pero es siempre su último recurso.

Si entendemos esta idea de último recurso, no nos costará entender por qué el manual no es el lugar indicado para resolver errores de software o de diseño. Si una interfaz no es intuitiva y dificulta completar una tarea, añadir una explicación al manual es una solución, pero no satisface las necesidades del usuario y lo que es peor, disminuye su percepción sobre la calidad del producto. Cubrir las deficiencias de un programa en el manual puede parecer inicialmente una solución más rápida y económica que desarrollar un parche (hotfix), pero a la larga puede salir cara.

Por qué documentar

Si un buen diseño simplifica el uso de un software cabe preguntarse, ¿sigue siendo necesario acompañarlo de un manual? Invertir en la usabilidad de una aplicación no solo incide positivamente en su calidad final, además reduce la dependencia del usuario en el manual. Pero a partir de un determinado nivel de complejidad, consultar la documentación resulta inevitable. En aplicaciones como las que tenemos instaladas en nuestros teléfonos móviles no se espera que hagamos uso de un manual de instrucciones. Son aplicaciones sencillas que cumplen una única finalidad y donde las instrucciones se limitan a una pequeña introducción durante el primer uso o consejos (tooltips) para familiarizarnos con los controles en pantalla.

Pero en el mundo fuera de nuestros teléfonos no todo resulta tan sencillo. Pensemos por un momento en un paquete de software de ofimática o de diseño gráfico. Estas aplicaciones no solo son más complejas de usar, también más complejas de desarrollar, aumentando la posibilidad de encontrarnos con errores. Y es que todos entendemos que no es lo mismo el mecanismo de apertura de la puerta de casa que de la compuerta de un avión -la del avión es más compleja y viene acompañada de instrucciones.

En otros casos la documentación es fundamental para explicar no tanto cómo funciona una aplicación, sino cuál es el conjunto de tareas que debemos completar en ella. Una cosa es que un programa de software sea fácil de usar y nos permita realizar las tareas sin demasiadas complicaciones y otra muy distinta que entendamos qué tareas se espera que realicemos y en qué orden. La documentación tiene un papel esencial explicando procesos, y no solo interfaces

Si los fabricantes de software quieren evitar la frustración de sus usuarios es imprescindible que dediquen recursos a mejorar la usabilidad y reducir los errores. Pero cuando los errores -inevitablemente- aparecen, es necesario solucionarlos en el producto, y no en el manual. Porque el usuario no quiere leer manuales o descifrar interfaces, quiere completar su tarea.

Apple frente al Diseño Material

La ausencia de una propuesta coherente en el diseño de sus interfaces debe hacer reflexionar a Apple. Si la compañía aspira a que su software siga jugando un papel clave en la compra de sus dispositivos, tiene que hacer de la usabilidad de sus sistemas operativos y aplicaciones una prioridad.

La forma sigue a la función

MacOS, el sistema operativo originario de los ordenadores Macintosh, puso en escena ideas revolucionarias en un mundo dominado por la monotonía de los PCs y las pantallas monocromas. Años después, Apple volvería a marcar el pulso de la telefonía móvil con el lanzamiento del iPhone y el sistema operativo iOS. Movida por la necesidad de potenciar la venta de sus primeros modelos de iPhone -antes de que este dispositivo se convirtiera en un objeto omnipresente-, la compañía impulsó el desarrollo de aplicaciones e interfaces móviles, aportando soluciones a los problemas derivados de mostrar información en un espacio reducido. Este impulso innovador en el diseño de software parece hoy agotado.

Son varios los factores que permiten llegar a esta conclusión, pero el ejemplo más notable de este agotamiento es, sin duda, su servicio de música en línea Apple Music con su aplicación para dispositivos móviles del mismo nombre y las versiones más recientes de iTunes. Desde su aparición el pasado año, Apple Music ha sido ampliamente criticado en foros de usuarios y publicaciones especializadas por incorporar un diseño confuso y una usabilidad mediocre. Este hecho resulta especialmente llamativo en una compañía para la que la experiencia de usuario ha sido siempre una prioridad, y lo es aún más cuando hablamos de aplicaciones que son clave en la venta de servicios en línea.

A este factor hay que añadir lo que parece una pérdida de rumbo en el diseño de sus aplicaciones para móviles. Mientras que aplicaciones como Calendario mantienen su aspecto original, el rediseño de nuevas aplicaciones como Notas insiste en ideas pasadas como el skeumorfismo (dotar a las aplicaciones con la apariencia de objetos físicos, en este caso, la apariencia de papel), pero las combina torpemente con otras dando lugar a un resultado desigual. Fijémonos, por ejemplo, en el botón añadir (+). No es ya solo que los botones tengan aspectos y ubicación diferentes, sino que además la función que cumplen es distinta: añadir un nuevo evento al calendario en un caso y añadir un acción a una nota en el otro, y no una nueva nota como cabría de esperar. Estos ejemplos no son casos aislados. El ecosistema de aplicaciones en iOS es como un museo con obras de arte de gran belleza, pero donde los cuadros de arte abstracto se mezclan con los de arte barroco y resulta difícil entender el recorrido por las salas.

Apple parece haber renunciado a sus principios de usabilidad en favor del diseños efectistas que cumplen con la forma, pero no con la función. Sus interfaces, con fotografías muy cuidadas, un uso prominente de los espacios vacíos y tipografías de gran tamaño, no tienen una traducción clara en términos de usabilidad. Microsoft nos demostró con Metro que un diseño de interfaces atractivo es insuficiente si no se apoya en principios de uso claramente definidos. Metro, la iniciativa de diseño que hizo su aparición en el escritorio de Windows 8 y Windows Phone, introducía elementos novedosos en la interfaz de usuario a los que Microsoft no supo dotar de una identidad clara, y que prácticamente han desaparecido en las versiones más recientes de sus sistemas operativos.

El Diseño Material

En la creación de experiencias de usuario simples y atractivas Apple parecía ser la única respuesta, pero los esfuerzos realizados por Google durante los últimos dos años pueden cambiar esta tendencia. En el año 2014, durante su conferencia de desarrolladores Google I/O, Google presentó su iniciativa de diseño de interfaces Diseño Material (originalmente en inglés, Material Design). El objetivo de esta propuesta se describe así:

Crear un lenguaje visual que sintetiza los principios clásicos del buen diseño con la innovación y las posibilidades de la tecnología y la ciencia.

Esta iniciativa no es rupturista. No propone nuevos modelos sino que, basándose en conceptos asentados en el campo del diseño, establece unas líneas bien definidas para el desarrollo de una experiencia de usuario unificada, sin importar el tipo de aplicación o dispositivo. Como se ha señalado, esta propuesta no es necesariamente mejor, pero es bien cierto que el esfuerzo realizado por Google para promover el uso de sus principios materiales es enorme cuando lo comparamos con el de sus competidores. Artículos, guías de estilo, tutoriales y vídeos sobre Diseño Material inundan la red. Las charlas acerca de este tema cuentan con su propio espacio en la conferencia anual de desarrolladores de Google, y la página web donde se detallan los aspectos de esta iniciativa es rica en detalles y ejemplos de implementación. Esta abundancia de información contrasta con lo limitado de la guía de estilo de Apple para el desarrollo de interfaces en iOS.

La propuesta de Google pretende llegar a cada rincón del ecosistema Android, con la incorporación de un número creciente de aplicaciones móviles. Cada vez son más los desarrolladores que hacen uso de elementos característicos del Diseño Material como el panel deslizante, las tarjetas o el botón de acción superpuesto. Estos elementos no son arrojados al azar a la interfaz, muy al contrario, su ubicación, aspecto y comportamiento se basan en reglas bien establecidas. Las aplicaciones mejoran porque, como señala Meng To, cuando las reglas de estilo son estrictas es difícil salirse de ellas y hacerlo mal. Las aplicaciones muestran mayor coherencia sencillamente porque, al contrario de lo que ocurre con iOS, el desarrollador cuenta con más herramientas y mejor información.

Lo Material como estándar

Lejos de ser algo reducido al entorno del sistema operativo Android, los principios materiales se hacen también un hueco en las aplicaciones para iPhone y iPad. Google publica incluso guías para a aquellos desarrolladores que quieren trasladar sus aplicaciones entre uno y otro entorno manteniendo las señas de identidad de cada uno. En contra de lo que algunos analistas han criticado, Google no pretende imponer su estándar de Diseño Material en iOS, sino crear uno donde actualmente no existe.

En un momento en el que las aplicaciones de nuestros móviles incorporan cada vez más funcionalidades, la necesidad de un estándar es crucial. Para hacernos una idea de esta creciente complejidad, pensemos en la integración de Google Maps con Uber y servicios de Taxi o las inclusión de asistentes personales en servicios de mensajería como Facebook Messenger o Google Allo. Si bien es cierto que establecer un estándar en el diseño y usabilidad puede hacer las aplicaciones móviles más parecidas entre sí, esto no tiene por qué ser necesariamente aburrido. Tal y como apunta Michael Horton en su artículo de Wired, todas las aplicaciones comienzan a parecer la misma, pero esto no es algo malo si con ello se consigue simplificar la experiencia del usuario.

Pero el interés de Google en extender su iniciativa no finaliza en el móvil. Con la presentación de su proyecto Polymer, los principios materiales se trasladan a las aplicaciones web, permitiendo que los desarrolladores se centren en el creación de servicios y no de interfaces. De nuevo, este hecho contrasta con la ausencia de Apple en lo que a desarrollo web se refiere. Las aspiraciones por parte de esta compañía de hacer de la venta de servicios en la nube un eje de su negocio chocan con un aspecto pobre y excesivamente simplistas de aplicaciones web como iCloud Drive, Photos o las versión en línea de Pages, Numbers y Keynote.

Apple Watch y watchOS

La falta de unas directrices claras de diseño y usabilidad por parte de Apple están originando una fragmentación en iOS muy similar a la que existe todavía en el ecosistema Android. Cada desarrollador parece buscar la forma más original de interactuar con su aplicación, muchas veces en contra de lo que tiene sentido. Es precisamente esta disparidad de criterios la que ha minado durante años la evolución de Android, y a la que Google pretende hacer frente con su iniciativa material. Esta situación, unida a una presencia aún tímida de Apple en servicios web, puede hacer peligrar el atractivo que los dispositivos de la marca tienen para el consumidor. No podemos olvidar que Apple es fundamentalmente una compañía de hardware, y que su objetivo -como ha declarado su director ejecutivo Tim Cook en varias ocasiones- es el de usar el software como elemento conductor a la compra de dispositivos.

Pero no toda la esperanza está perdida. El sitio web para el diseño de interfaces con Apple Watch y watchOS -el sistema operativo que da vida al reloj inteligente de la compañía- muestra un notable esfuerzo por encontrar una forma coherente y eficaz de interactuar con este dispositivo. Quizás Apple, que en las últimas versiones de su sistema operativo de escritorio ha incorporado elementos propios del iPhone -Siri, como ejemplo más destacable-, pueda seguir el mismo principio con su reloj inteligente, utilizando watchOS como base para una renovación de su software móvil.

No estamos hablando aquí de implementar las soluciones adoptadas en un dispositivo de 3 pulgadas a una pantalla de un móvil o un ordenador, sino de adaptar y ampliar aquello que funciona a otros dispositivos, dotando a todo el ecosistema Apple de una identidad y uso común. Los cambios anunciados en su pasada conferencia mundial de desarrolladores parecen indicar una apuesta por trasladar elementos de usabilidad incorporados inicialmente en watchOS a iOS. El cambio en el centro de notificación, con alertas enriquecidas y el uso de tarjetas deslizantes en el centro de control, se asemejan notablemente al funcionamiento del reloj inteligente.

Pero esto no es suficiente. Apple debe definir con más y mejor información sus principios de diseño y usabilidad, poner en relieve la importancia de seguir estos principios y dotar a los desarrolladores de más herramientas. Es necesario además apoyar aquellas aplicaciones que hacen buen uso de estas normas (por ejemplo, dándoles un lugar relevante en su tienda de aplicaciones App Store) y ayudar económicamente a los desarrolladores más pequeños (por ejemplo, reduciendo las tarifas de acceso y comisiones de su Store), que no cuentan con la posibilidad de invertir en diseño y usabilidad.

(este artículo fue publicado originalmente en LinkedIn el 28 de Agosto de 2016)