7 principios del diseño de aplicaciones

El diseño de aplicaciones web debe cumplir con una serie de requisitos para generar interfaces naturales, obvias y predecibles que no sólo aceleren el trabajo con la aplicación, sinó que además provean al usuario de seguridad, confianza y satisfacción en su uso. Estos requisitos los he agrupado en 7 principios fundamentales del diseño de aplicaciones:

Proximidad: Las funciones básicas deben aparecer de inmediato, mientras que las funciones avanzadas deben estar en un lugar menos para los usuarios nuevos. Los usuarios deben beneficiarse de tener más próximas las funcionalidades más utilizadas, al igual que un carpintero siempre quiere tener a mano las herramientas que más utiliza.

Familiaridad: Una de las características de una buena interfaz es que en su mayor parte no requiere un aprendizaje específico, sino que es utilizable inmediatamente porque se basa en conocimientos previos de la vida real de los usuarios. Utilizar conceptos, mecanismos e imaginería del mundo real como metáforas permite a los nuevos usuarios empezar a utilizar la aplicación casi de inmediato, porque intuyen su funcionamiento al encontrarse con conceptos conocidos. Además, emplear las convenciones típicas de las aplicaciones facilita también el aprendizaje, puesto que se aprovecha una parte del conocimiento previo en la utilización de otras aplicaciones.

Simplicidad: Una interfaz repleta de funciones avanzadas sólo distrae a los usuarios y les impide realizar las tareas comunes del día a día. Por el contrario, una interfaz que sustenta las acciones del usuario acaba desapareciendo como interfaz y se convierte en tapiz. Además, los objetos de la interfaz tienen que parecer lo que son. Los controles, los elementos y sus relaciones tienen que tener un significado obvio, claro y comprensible, de modo que de un vistazo el usuario pueda entender, sin llegar a tocar el ratón, cómo funciona la aplicación.

Transparencia: A diferencia de muchos otros sistemas como motores o máquinas de tabaco, las aplicaciones son sistemas interactivos que no hacen ruido mecánico por sí mismos. Por tanto, toda la comunicación debe vehicularse a través de la vista (ignoramos aquí aquellas que generan efectos sonoros, como aplicaciones de escritorio). Las mejores interfaces dialogan con el usuario de modo visual (y más que textual): estas pistas visuales evidencian qué está haciendo la aplicación, cuánto queda, y qué se espera del usuario. Con barras de estado, barras de progreso y técnicas como el empleo de focus y highlights, la interfaz comunica visualmente al usuario la actividad de la aplicación, que si no sería completamente silenciosa. La interfaz debe ser transparente y mostrar visualmente la acción que el usuario realiza, de modo que trabajar con la aplicación sea obvio, y que los efectos de utilizarla sean inmediatos.

Diálogo: Aparte de ser transparente en su funcionamiento, la aplicación debe comunicarse con mensajes de texto con el usuario. Mediante estos mensajes, que pueden ser de error, de alerta o de confirmación, la interfaz debe expresar lo que está ocurriendo “under the hood”, detrás de la pantalla. Estos mensajes deben estar bien redactados y ser precisos sobre el tipo de error que ha habido, sobre la acción que se ha completado o sobre el aviso que quiere darse al usuario. No deben ser genéricos sino específicos. Deben dar siempre la oportunidad de cancelar la acción, si no está hecha, o deshacerla, si ya está hecha.

Seguridad: El usuario debe tener la seguridad de que usar la aplicación no es ni peligroso ni arriesgado. Es decir, que no es posible equivocarse sin haber sido advertido previamente, ni que no es posible cometer un error sin poder restaurar el estado de las cosas antes de cometerlo, es decir, deshacerlo. Eso pasa por no situar ningún botón fatal en un sitio de paso cualquiera sino en un sitio protegido, dar el aspecto pertinente a los botones de acción fatal, pedir confirmación antes de realizar la acción, etc. El usuario debe tener la seguridad de que si va a realizar alguna acción crítica, la aplicación estará a la altura y sabrá advertirle de modo oportuno (en el momento adecuado) y pertinente (avisando con claridad las consecuencias de esa acción crítica).

Consistencia: Una interfaz consistente logra una de las mayores virtudes de las interfaces: la predictividad. La aplicación debe comportarse de una manera predecible. El usuario debe poder predecir y acertar sobre lo que pasará cuando haga click aquí o allí, porque antes ha visto a la aplicación responder de ese modo en una situación parecida. Eso se logra cuando elementos de la interfaz parecidos se comportan de manera parecida, y cuando ese comportamiento se mantiene de modo consistente a través de toda la aplicación. Los mismos objetos de la interfaz deben comportarse de la misma manera en cualquier lugar. Si van a comportarse diferente, su aspecto también debe ser diferente.

Apple Mail: pequeño pero importante error

Error Apple Mail

Existe en el cliente de Mail del Mac OS X (todas las versiones) lo que a mi entender es un pequeño pero grave error de diseño. Se trata de los dos iconos que representan las acciones de “Eliminar” y “Trasladar a Correo no deseado” el mensaje/mensajes que tengamos seleccionados. El problema es que los dos iconos parece que estén intercambiados, lo que genera en algunos usuarios confusión (cuanto menos a mí me pasa, pero también he visto a otros usuarios de Apple Mail claramente dubitativos frente a la duda de qué botón deben apretar). En el Apple Mail:

Icono de Apple Mail para la acción de "No deseado"El botón de “Eliminar” es una señal de “Prohibido el Paso”, que obviamente nada tiene que ver con la acción de Eliminar y sí con el hecho de denegar el paso a mensajes de spam.

Icono de Apple Mail para la acción de "Eliminar"Por su parte, el botón de “No deseado” es una bolsa de basura convencional que, además, si nos fijamos bien veremos que es una bolsa de basura reciclable, dejando intuir que su contenido se puede reciclar (recuperar), utilizando la misma metáfora que utiliza Windos con su “Papelera de Reciclaje”.

Al ser dos iconos que parecen reflejar dos acciones que no son las que realmente realizan, esto se convierte en un fallo en la usabilidad de la aplicación, lo que en consecuencia crea a menudo errores: hay usuarios que creen prohibir el paso de e-mails de spam marcando el mensaje con la señal de Prohibido, pero en cambio lo que están haciendo es eliminarlo sin marcarlo como spam (y además legitimado el mensaje como un e-mail genuino).

Por su lado, hay usuarios que, una vez leído un e-mail legítimo de un contacto, lo quieren eliminar y por tanto trasladar a la papelera de reciclaje. Por tanto, se dejan guíar por la iconografía de la interfaz y aprietan el botón de la papelera amarilla, sin darse cuenta de que están marcando como spam ese mensaje y, por tanto, marcando también como spam los que puedan provenir en el futuro de ese remitente.

La lógica del usuario es evidente y no deja dudas: si quiero eliminar un mensaje, por qué debería apretar un botón que significa universalmente “Prohibir” y no dice nada de “Eliminar”? Con más motivo aún cuando justo al lado hay un botón con un cubo de basura, que es la metáfora más extendida en informática para la acción de “Eliminar”. El cubo de basura significa universalmente “Eliminar” y además viene reforzado por el símbolo de reciclaje, que me informa que no un eliminado definitivo, sinó que si luego quiero recuperarlo podré hacerlo (como en la Papelera de Reciclaje de Windows, o la Papelera de Mac OS X). Si por el contrario, quiero marcar como “correo no deseado” un mensaje y por tanto prohibir que no vuelva a entrar en el buzón de entrada ningún mail parecido, no debería apretar el botón de “Prohibir”???

Apple Mail icons

Lógicamente, la solución radicaría en intercambiar los iconos de lugar, como se ilustra en la imagen de arriba. Pero claro, no puedes cambiar de orden dos iconos a los que la gente se ha habituado (aunque sea en una relación tormentosa con ellos) y que ahora signifiquen cosas distintas a las que han significado hasta ahora.

Por tanto, la única opción radica por realizar una alternativa completamente nueva, como por ejemplo esta propuesta que se ve en la imagen de abajo:

Apple Mail propuesta

La ventaja de esta propuesta es que la acción de “Eliminar” queda ilustrada por un cubo de basura idéntico al que existe en el escritorio (Finder) de Mac OS X, con lo que la curva de aprendizaje, sencillamente, no existe. Los usuarios están plenamente habituados a esta metáfora. Por otro lado, el símbolo de radioactividad (aunque podría ser otro: una cucaracha, un demonio rojo, un virus, una araña…) es un símbolo universal de peligro e de infección, ideas correctamente asociadas a mensajes de spam o de virus.

Usabilidad en los peajes I – Re-diseñando los rótulos

A pesar de que en Internet se pueden encontrar opiniones y análisis sobre cualquier tema imaginable, me ha sorprendido un poco no haber encontrado ninguna referencia sobre la usabilidad de los peajes, ni siquiera en inglés. Ya sé que no es un tema tan interesante como para hablar de él largo y tendido, pero cuanto menos es curioso. ¿O quizás es que yo soy el el único del mundo que necesita un pequeño esfuerzo mental para entender los rótulos y la caótica iconografía que los acompaña? ¿Seré yo el único al que no le gusta nada la interfaz de las máquinas de cobro? O quizás sea sólo desviación profesional…

Lo bueno de esto es que nadie ha hablado sobre esto antes y por tanto soy el primero que entre a explorar este territorio virgen. Con esta idea en mente y dado que tengo un esguince que me tiene impedido y no tengo nada más que hacer, voy a hacer una pequeña serie de artículos con propuestas sencillas y económicas de mejorar la usabilidad de los peajes.

En esta primera parte me centraré en exclusiva en el rotulado, que lógicamente incide en mucho en la usabilidad percibida de un sistema. En otro post intentaré escribir una pequeña crítica sobre la usabilidad de las máquinas de cobro de los peajes, que ese es un tema que merece también su propio post.

El primer problema de los peajes es la rotulación. Cuando nos aproximamos con el coche, nos encontramos con carteles de este tipo, al menos en Cataluña: MANUAL y AUTOMÁTICO.

Usabilidad en los peajes

Como todo buen profesional de la usabilidad sabe, el rotulado debe ser auto-explicativo por un lado y por el otro no llevar a confusión. Sin embargo, tanto las vías señalizadas como “MANUAL” como las de “AUTOMÁTICO” son todas manuales, no automáticas. Pagues con billetes y monedas o con tarjeta, ambos modos de pago son completamente manuales y no tienen nada de automático, en tanto en cuanto requieren que pares, que bajes la ventanilla, que pagues y que una vez se efectúe el pago se suba la barrera. No es pago automático porque no es que la máquina cobre por sí misma, quee s la definición de una máquina de pago automático. Esto viola uno de los principios más elementales de la usabilidad: la correcta rotulación a nivel semántico.

Adicionalmente, “AUTOMÁTICO” puede inducir a error a los usuarios del Teletac, que sí es un sistema de pago realmente automático en tanto en cuanto no requiere ninguna acción del conductor aparte de bajar un poco la velocidad. Un usuario del Teletac con toda la razón del mundo podría pensar que los carriles de “AUTOMÁTICO” son sus carriles, y que los de “MANUAL” son para los que no tienen de un sistema de pago automático porque manualmente, ya sea con billetes y monedas o con tarjeta.

En realidad, lo que distingue unos carriles de los otros no es otra cosa que el modo de pago. A diferencia de un supermercado en el que tanto los que pagan con billetes y monedas como los que pagan con tarjeta pasan por los mismos carriles o cajas, en los peajes se distingue a unos y otros, porque el dispositivo de cobro es diferente. Por tanto el rotulado debería expresar esto sin ambiguedades y los carteles sobre las vías deberían ser “AL CONTADO” y “TARJETA”. De este modo, se comunicaría fielmente e inequivocamente que se distingue a los conductores por cómo van a pagar.

En realidad, ésta tampoco sería buena opción, ya que en los carriles señalizados como “AL CONTADO” siempre hay un operario, y a éste se le puede pagar también con tarjeta. Por tanto, los rótulos deberían ser “AL CONTADO O TARJETA” y “TARJETA”. Lo mejor, por supuesto, es acompañar estos dos rótulos de iconos sencillos que apoyen y confirmen el mensaje para no dejar lugar a dudas. Con un sencillo icono de monedas y billetes, y otro sencillo icono de tarjeta es suficiente para acabar de comunicar que se distingue los carriles por cómo se puede pagar en ellos. Además, estos icono son necesarios para los extranjeros si el rótulo no está traducido, como es el caso aquí.

Por tanto, si antes tenían este aspecto:

Usabilidad en los peajes

Ahora tendremos éste otro:

Usabilidad en los peajes

Hemos eliminado los conceptos de “AUTOMÁTICO” y “MANUAL” porque, como hemos visto, son incorrectos y se prestan a confundir. Por otro lado, al integrar arriba los iconos de pago al contado y de pago con targeta, podemos eliminar los otros rótulos fluorescentes que están más abajo y que sólo añaden ruido visual. Las redundancias, en el caso de un sistema en el que hay pocos segundos para escoger, son negativas. También aprovechamos para quitar el rótulo verde con el icono de tarjetas que hay debajo del rótulo también verde para vehículos pesados, porque ahora es también redundante. Con lo cual la cosa nos queda así:

Usabilidad en los peajes

Pero aún hay muchas cosas que mejorar. Como bien sabe cualquier diseñador, los códigos cromáticos se suelen hacer servir para con diferentes intenciones. Pero lo que está claro es que los códigos cromáticos, si se utilizan, deben utilizarse siempre y bien. De otro modo, no sólo pierden su sentido, sino que confunden en vez de ayudar. En la imagen anterior a ésta última, hay un código cromático que identifica a los mensajes dirigidos a los vehículos pesados, el verde. El verde agrupa a 3 rótulos dirigidos a este tipo de vehículos.

Pero cualquier diseñador algo avezado en psicología humana sabrá que mucha gente, ante estos cuatro rótulos, deducirá con toda lógica que si el fondo verde se utiliza para significar “Vehículos pesados”, entonces por fuerza los fondos azul y blanco de los otros rótulos deben querer significar otros dos tipos de vehículos. Este tipo de razonamiento no es sólo completamente lógico, sino que además es también consecuencia del aprendizaje de las señales de tráfico, que son probablemente el mejor ejemplo de una señalética excelente que se basa, precisamente, en este tipo de códigos cromáticos. En el caso de las señales de tráfico, los fondos se combinan con la forma, con el borde y con iconos para expresar diferentes conceptos combinados. La gente ha aprendido a leer este tipo de códigos al estudiar para el carnet de conducir y los aplica también frente a la rotulación de los peajes.

En este peaje, parece que se ha utilizado el azul y el blanco con la intención de querer distinguir mejor un carril para pago con tarjeta y otro para pago al contado (y con tarjeta), pero es un error. En el código que estamos diseñando, los tipos de pago se comunican a través del icono y sólo a través del icono. Hacerlo de dos modos distintos, con color y con icono, como bien se sabe en usabilidad, es redundante y genera confusiones. “Dínoslo de una manera correcta, y de sólo una manera”, sería la frase.

En cambio, el color de fondo, lo estamos utilizando para identificar tipos de vehículos distintos. Verde para vehículos pesados, y por tanto el blanco o el azul, pero nunca ambos, para vehículos ligeros. En este caso prefiero utilizar el blanco, con lo cual la foto nos quedaría así:

Usabilidad en los peajes

Parece que queda más claro las dos famílias que hay, la blanca para vehículos ligeros y la verde para vehículos pesados. Pero aún queda un pequeño detalle. Dado que la redundancia es negativa como norma general en usabilidad y como norma particular cuando sólo se tienen unos cuantos segundos para tomar una decisión, como cuando uno se aproxima a un peaje, aún queda un pequeño detalle: eliminar el cartel verde con el dibujo del camión.

Finalmente, si lleváramos al extremo los principios del buen diseño y de la usabilidad, corregiríamos una asociación visual que es traicionera: el verde que identifica vehículos pesados es muy parecido al que hay en las balizas de los refugios entre carril y carril. Por supuesto, en este caso sería difícil que alguien entendiera que los vehículos pesados, identificados en verde, deben pasar por los carriles “señalizados” con balizas verdes, pero vamos a pasarnos de rosca e intentar resolver algo que no porque no nunca tendrá mayores consecuencias deja ser un error. Por tanto, cambiaremos el color verde de las balizas por uno que no se relacione en nada con los rótulos, ya que no tienen nada que ver. Hay que romper esta asociación cromática utilizando otro color.

Podríamos pintar las balizas de cualquier color excepto el blanco o el verde (ya que se asociarían con los rótulos), pero para ir a por nota, no escogeremos un color al azar, sinó que ayudaremos a distanciar más las balizas respecto de los rótulos asociando las balizas a las cabinas pintando las balizas de color azul. De este modo, ordenaremos el paisaje visual uniendo las balizas a las cabinas, comunicando por tanto que las balizas no tienen ningún significado, sino que forman parte de la estructura del peaje.

Operando estos dos cambios la cosa queda de la siguiente manera:

Usabilidad en peajes

OK, ahora queda más claro. Lo que hemos hecho ha sido rediseñar la rotulación de este peaje, de modo que esté más ordenada, más clara, tenga menos ruido visual,  y exija menos esfuerzo para ser comprendida. Para poder comparar este resultado con lo que teníamos al principio del rediseño, recupero la imagen original:

Usabilidad en los peajes

En el caso de un peaje, una buena rotulación no es una cuestión baladí, y de hecho puede tener un impacto notable. Por un lado puede ahorrar un gran número de errores como los que todos hemos visto muchas veces de coches que tiran marcha atrás porque se han equivocado de carril, y por el otro lado puede reducir el número de maniobras de último momento que algunos conductores  hacen cuando por fin localizan el carril por el que tienen que ir. En algunos casos, este tipo de maniobras provocan accidentes.

Hasta aquí el rotulado. En el próximo capítulo, cuando pueda, me centraré en las máquinas de cobro con tarjeta de los peajes.

Las capas del diseño web

Desmenuzar el proceso de diseñar en varias capas es una manera muy útil de asegurarnos de que el diseño que produzcamos será completo e integral. El proceso del diseño se divide en capas. Hay diseñadores que dividen en capas su trabajo de un modo diferente, pero para mi ésta es la opción con la que me encuentro más cómodo:

  • Arquitectura de Información – Empieza decidiendo o planificando qué información está disponible, y dónde, cuando y bajo qué condiciones.
  • Comportamientos de interfaz – A veces se requieren o son aconsejables comportamientos de interfaz específicos. Estos comportamientos suelen afectar el diseño tanto desde el punto de vista funcional como desde el visual.
  • Jerarquía visual del contenido – Suele ser beneficioso para aportar pistas sobre lo que es más importante del sitio web, qué es lo siguiente en importancia, y así con el resto de elementos.
  • Layout – La parrilla visual fundamental en la que se alojan los elementos mencionados anteriormente.
  • Estilo – El look&feel del sitio web debe soportar y dar un aspecto a todo lo anterior y relacionar todos los elementos anteriores de una manera limpia y armónica

Cada capa es importante y, cuando se trabaja bien, contribuye a la totalidad del diseño. Olvida una de las capas y el diseño se resentirá y no alcanzará su potencial. En general, los diseños que ignoran alguna de estas capas son, simplemente, diseños pobres.

Por qué hay tan mala usabilidad en el open-source

¿Por qué las aplicaciones open-source suelen tener tan mala usabilidad? He aquí algunas de mis razones:

– Hay pocos incentivos para que haya una buena usabilidad. Los fabricantes de productos comerciales tienen que ganar dinero para pagar los sueldos de los desarrolladores, y eso significa que se deben esforzar en que sus productos sean usables, para maximizar ventas. En el open-source no existe esta obligación.

– Muchas aplicaciones open-source se entregan “as it is”; no suele haber un sistema de soporte técnico que colapse ninguna centralita si el producto tiene una mala usabilidad. En cambio, en el software comercial se intenta evitar al máximo las llamadas al soporte técnico y ello significa que se cuida la facilidad de uso. En el open-source los problemas de usabilidad en una aplicación no suelen tener ningún impacto en sus desarrolladores.

– Por su propia naturaleza, las personas involucradas en el open-source suelen estar centradas en el código. Cualquier otro aspecto es secundario. Ello incluye el diseño o la usabilidad, que son aspectos que quedan relegados. El resultado son aplicaciones con interfaces bastante caóticas, sin orden, jerarquía o estructura visual.

– Cualquier producto open-source necesita diseño, pero en cambio suele haber pocos diseñadores en el software libre. Tal como está pensado el open-source, no es lugar para un diseñador. Por ejemplo, mientras que un desarrollador puede identificar un bug y contribuir un patch para solucionarlo, un diseñador que encuentre un fallo de diseño o de usabilidad no puede más que indicarlo, y esperar que alguien de mala gana lo intente arreglar.

– Al no haber muchos diseñadores, muchas decisiones de diseño y usabilidad se deciden sin el criterio necesario. Al igual que los mejores intérpretes de música suelen ser pésimos compositores, los mejores programadores suelen ser pésimos diseñadores. La ausencia de criterio propicia decisones erróneas y, en consecuencia, en el desarrollo de aplicaciones con las que trabajar no suele ser muy ergonómico. En segundo lugar, al no haber diseñadores las decisiones se toman a modo de compromiso entre las sensibilidades de todos los programadores, lo que resulta en una interfaz sin unidad, integridad y consistencia.

– Los bugs son objetivos, los fallos de diseño o usabilidad son en su mayoría subjetivos. Cuesta mucho más aceptar un error de diseño que un error de funcionamiento, porque aquél es mucho menos obvio. También cuesta mucho más que el grupo de desarrolladores se ponga de acuerdo sobre si algo es un fallo de diseño o esa una “feature” especial. Al ser los errores de diseño o usabilidad más subjetivos, es más dificil llegar a su identificación.

– Se programa antes de diseñar. El software suele ser mucho más usable si se diseña antes de programar, pero los entusiastas voluntarios de muchos proyectos open-source tienen tantas ganas de escribir código que prefieren saltarse los wireframes, los prototipos y los mockups. Sin embargo, estos elementos inciden directamente en el flujo de trabajo y uso de la aplicación, por lo que afecta al modelo de datos, a los algoritmos, al orden en que las acciones se realizan, etc. Programar antes de diseñar es cómo construir una casa sin planos.

– Al ser programadores, los desarrolladores suelen ser también power users. En consecuencia, las aplicaciones están pensadas para usuarios avanzados como ellos, para los que los problemas de usabilidad de una aplicación pueden ser superados sin mayores esfuerzos, pero eso no ocurre con los usuarios normales. Ejemplo de esta mentalidad de power-user es la ausencia casi total de asistentes o de prompts que guíen la navegación, elementos que en cambio suelen ser habituales en los programas comerciales.

– Los programadores open-source, al ser voluntarios, trabajan en aquellos proyectos que les interesan. Eso suele resultar en una falta de capacidad de abstracción. Al estar tan metidos en ese proyecto, a los desarrolladores les falta distancia y visión global, y la empatía necesaria para ponerse en el lugar de los usuarios. Los árboles no suelen dejarles ver el bosque.

– Por su propio carácter libre, el open-source facilita el intercambio de código y la reintegración de componentes, por lo que a menudo muchos módulos de diferentes orígenes se integran en una única aplicación. Ello suele resultar en inconsistencias en el diseño, en el manejo, o incluso en el léxico empleado de las aplicaciones de software libre, perjudicando por tanto la usabilidad.

– Todos los programadores voluntarios quieren que su pieza de software o la funcionalidad que han desarrollado aparezca en la aplicación, y cuánto más aparezca, mejor. Para aplacar ese deseo y asegurar la continuidad del voluntario, esa funcionalidad suele meterse donde quepa y de la mejor manera, pero a menudo sólo estorba y añade caos a la aplicación, tanto a nivel de diseño como de uso. Del mismo modo, quitar componentes de la aplicación para poder mejorar la ergonomía de la aplicación suele poner furioso al desarrollador que los hizo, con lo que a veces continúan aunque sean un estorbo o rompan completamente el uso lógico de la aplicación.

– Las aplicaciones open-source suelen competir unas con otras por el nivel de features que tienen, no por su diseño o por su facilidad de uso, mucho menos por obtener una cualificación mayor en la capacidad que tienen de ser usadas por los usuarios. Ello significa que la featuritis suele primar por encima de la experiencia de usuario. La simplicidad se ve como una carencia de features, no como una virtud.

– Los programadores no suelen distinguirse por su sensibilidad estética, por lo que muchas aplicaciones tienen un aspecto visual que ellos dan por bueno pero que a menudo horrorizan a cualquier usuario normal y corriente. Que las aplicaciones aparezcan bien es tan o más importante que el que funcionen bien. Un diseño pobre no sólo decepciona estéticamente al usuario, sino que perjudica sobremanera su usabilidad.

– Detalles como informar al usuario del progreso de una acción con una barra de progreso, explicar lo que  ocurrirá al presionar un botón determinado, rotular correctamente los botones y las secciones, redactar con propiedad la mensajería del sistema o la ayuda, ilustrar la interacción del usuario con el sistema con estados como hover o focus no suelen ser muy excitantes para los programadores, por lo que suelen faltar en las aplicaciones realizadas por voluntarios. Sin embargo, tienen un efecto crítico sobre la experiencia de uso de la aplicación.

Open source no es lo mismo que software gratis (freeware), ni que software libre. Estas razones no pueden aplicarse a todas las aplicaciones open-source (por ejemplo, hay aplicaciones open-source de pago con muy buena usabilidad), sino a muchas aplicaciones que aparte de ser open-source son también gratuitas.