Introducción del sistema | Desarrollo de software

Los tres aspectos clave de una buena usabilidad

La facilidad de uso de las solicitudes de planificación puede evaluarse en función de tres aspectos: Alcance funcional, concepto de funcionamiento y tiempo de respuesta. ¿Qué significa exactamente esto? Este artículo es una simple guía para estructurar el tema y poder clasificar la usabilidad de las aplicaciones de software.

En este artículo abordamos un tema a menudo controvertido: ¿cuándo es buena una aplicación de software? O dicho de otro modo: ¿qué hace que un software sea bueno? Formulado de manera algo informal, probablemente se diría que una aplicación "es buena cuando es útil y puede hacer bien aquello para lo que fue hecha". Más formalmente, la aplicación debe tener un alto grado de facilidad de uso o usabilidad. En aras de la simplicidad, utilizaremos el término inglés usability para hablar de estos conceptos.

Hmm, ¿qué es exactamente la usabilidad?

El término usabilidad no siempre está claramente definido y ciertamente es interpretado de forma diferente por distintas personas. Una simple búsqueda en Internet arroja una variedad de definiciones no siempre congruentes. Por supuesto, la usabilidad puede aplicarse a cualquier objeto fabricado por el hombre (no sólo al software), pero eso no nos interesa aquí. A menudo uno se encuentra con el término ergonomía del software. Lo cierto es que la usabilidad no se puede medir en una escala absoluta y precisamente por eso suele ser víctima de percepciones subjetivas. Esto da lugar a discusiones sobre quién tiene ahora razón con su valoración del software.

En este artículo tratamos de llegar al fondo del término usabilidad y, en particular, de profundizar en la mensurabilidad. Lo intentaremos de forma muy sencilla y distinguiremos únicamente los tres aspectos siguientes en relación con la usabilidad de una aplicación informática:

  • Alcance funcional(¿Qué puede hacer el usuario con la aplicación?)
  • Concepto de funcionamiento(¿Cómo puede hacer algo el usuario?)
  • Tiempo de respuesta(¿con qué rapidez responde la aplicación a las entradas del usuario?)

A continuación, aclaremos estos términos y analicemos cada uno de ellos.

La gama de funciones: ¿Qué puede hacer mi aplicación en absoluto?

El ámbito funcional de una aplicación suele estar sobrecargado y no cubre realmente lo que el usuario necesita. ¿De qué sirve una aplicación si no necesito el 80% de las funciones que ofrece para mi trabajo? Este lastre no suele estar en un segundo plano y me ha costado mucho en la compra, no, incluso puede entorpecer el uso del 20% de las funciones realmente útiles. Se rumorea que aplicaciones muy conocidas, como los productos de Office, sufren este mal. No es fácil encontrar estadísticas concretas y corroboradas. Y los que se encuentran hay que tomarlos ciertamente con un grano de sal. Sin embargo, se pueden encontrar fácilmente decenas de entradas de blog en la web ("Los 50 consejos más difíciles para Word", "Ajustes ocultos en Microsoft Office", "10 consejos prácticos para Word", etc.), que sugieren que el usuario típico de Office obviamente sólo trabaja con una pequeña parte de las funciones disponibles y no conoce el resto en absoluto.

Por tanto, una buena aplicación tiene el mayor número posible de funciones que el usuario espera y utiliza a diario. El término "exactamente estas funciones" se define, por supuesto, de forma algo diferente según el usuario. Pero si imaginamos una aplicación empresarial que es utilizada por un gran número de usuarios en la misma empresa o incluso dentro de un sector empresarial, entonces sí se puede encontrar un denominador común entre estos usuarios. Una aplicación empresarial de este tipo debe ofrecer aquellas funciones que soporten de forma óptima los procesos empresariales típicos. Y si el precio es correcto, muchas organizaciones también están dispuestas a adaptar sus procesos a un producto estándar para las pocas desviaciones de la aplicación deseada.

El concepto operativo: ¿Cómo hago ahora de nuevo...?

El concepto de funcionamiento de una aplicación determina la rapidez con la que un usuario puede encontrar y utilizar la función que necesita para una tarea. A menudo se habla de la intuición del usuario o de que la "aplicación puede manejarse intuitivamente". Por supuesto, el principio de subjetividad también se aplica aquí: lo que es intuitivo para una persona es complicado e incomprensible para otra. Al fin y al cabo, aquí hay posibilidades de medición. La sencillez de uso puede medirse y evaluarse en un grupo más amplio de usuarios. A las personas que realizan la prueba se les da simplemente una tarea para que la resuelvan con la aplicación y se mide la rapidez con la que la gestionan. De este modo, diferentes aplicaciones construidas con el mismo fin pueden incluso compararse entre sí de forma cuantitativa y compararse con cierta objetividad (porque estadísticamente). En la práctica, los diferentes productos de la competencia simplemente tienen que enfrentarse al mercado. Una operación piloto que pueda establecerse rápidamente y sea lo suficientemente larga puede ayudar sin duda.

Un buen concepto de funcionamiento es siempre coherente, es decir, lo más coherente posible en todas las funciones: las mismas acciones se realizan de la misma manera. Buscar objetos, fijar visualizaciones, abrir y editar elementos de datos, borrar objetos,... Todo funciona siempre según un principio uniforme. Es precisamente al evaluar el concepto de funcionamiento cuando se pone de manifiesto si los desarrolladores de la aplicación han perseguido un enfoque aplicable genéricamente desde el principio, o si simplemente la aplicación se ha hecho algo más grande con el tiempo y las funcionalidades tienen que ser llamadas de forma diferente una y otra vez porque simplemente no hay un hilo conductor en la aplicación.

El tiempo de respuesta: ¿Cuánto tiempo tarda?

Por último, pero no menos importante, está el tiempo de respuesta. La aplicación más adecuada (¡conjunto de características!) e intuitiva (¡operación!) pierde una enorme cantidad de valor y aceptación del usuario si es lenta. Y no hace falta mucho para ser considerado lento. Al menos desde el punto de vista de usuarios a menudo muy exigentes. El tiempo es dinero. Y a nadie le apetece pasar mucho tiempo esperando delante de la pantalla cada día hasta que los datos esperados aparezcan por fin delante de mí. Unos pocos segundos ya son demasiado tiempo cuando se trata de una función que el usuario llama cada poco tiempo. El rendimiento inexistente de una aplicación suele ser la muerte en las ventas. "Por suerte", aún puede decirse, "el producto de la competencia tampoco es más rápido". Pero en los tiempos que corren, en los que las nuevas tecnologías se sustituyen casi anualmente, los anchos de banda de las redes y sobre todo de Internet son cada vez mejores, y el rendimiento de los ordenadores también se duplica aproximadamente cada dos años según Moore, en estos tiempos ya no hay excusas para un mal rendimiento.

¿Cómo consigue una aplicación de software una alta usabilidad?

A menudo se habla de diseño centrado en el usuario o de diseño orientado al usuario. Con esto nos referimos a la inclusión del futuro usuario en todo el proceso de desarrollo. Lo ideal es comenzar con la primera descripción de la futura aplicación, es decir, en la ingeniería de requisitos: ¿Qué debe hacer realmente la aplicación (alcance funcional)? Según nuestra experiencia, una descripción puramente textual de estos requisitos es de poca utilidad. En cuanto a las formulaciones en prosa, los participantes en el proyecto se ponen rápidamente de acuerdo. Pero el meollo de la cuestión radica en el diseño de la pantalla. Aquí es donde el usuario se sienta realmente frente a la pantalla y hace aquello para lo que la aplicación fue construida. La mejor manera de empezar es con bocetos sencillos en una pizarra o en un programa de dibujo adecuado. En caso de necesidad, también se puede utilizar PowerPoint. Más tarde, estos diseños de pantalla tienen que plasmarse en maquetas clicables. Para que los usuarios puedan jugar con ellos y desarrollar una sensación de usabilidad. Sólo en una fase posterior del proyecto puede comenzar la construcción de un prototipo . Aquí es donde entra en juego por primera vez el rendimiento, es decir, el tiempo de reacción de la aplicación. Por supuesto, esto sólo se hace realmente evidente (o no) cuando se simula la estructura cuantitativa final (mayor número de usuarios, stock de datos realista, latencia de red real, etc.).

Existe suficiente literatura sobre el proceso de desarrollo de una aplicación informática y la inclusión de los usuarios. Nos abstenemos aquí de empezar siquiera con una lista de referencias. Sin embargo, volveremos con gusto a las posibles y buenas metodologías y procesos de desarrollo en un próximo artículo. No te muevas de ahí.

Sobre el autor


Director General de INTRASOFT AG

El Dr. Daniel Hösli es director general y consultor principal de INTRASOFT AG, cuya solución SaaS PQFORCE es la plataforma líder para la gestión empresarial ágil y orientada a proyectos. Lleva 15 años participando en el desarrollo de sistemas de gestión de proyectos a diario en calidad de consultor y gestor de proyectos -tanto desde el punto de vista organizativo como técnico-, por lo que cuenta con la experiencia adquirida en innumerables contactos y tareas de una gran variedad de empresas y diferentes niveles de gestión.

No se pierda

Con PQFORCE Insights recibirá nuestras últimas noticias, mejores prácticas, consejos y ofertas directamente en su buzón.
Sólo le enviaremos correos electrónicos relevantes y libres de spam.
Siempre puedes darte de baja con un solo clic.
Pruébalo ahora