• Sábado, Mayo 27, 2017

Diseño software centrado en usuarios, no en desarrolladores

Tradicionalmente el diseño de los ERP’s, CRM, BI, … ha estado orientado a los desarrolladores, dejando de lado ciertas peticiones, no tanto funcionales, sino operativas de los usuarios. Ello ha provocado sistemas difíciles de manejar en cuanto a complejidad y con un requerimiento de formación muy importante para los usuarios. La demostración más fehaciente la tenemos en las aplicaciones que nos instalamos cada día en nuestros smartphones y tablets con tiempos de formación y aprendizaje muy reducidos. Siendo la tendencia cada vez más actual de simplificar estas aplicaciones y hacerlas más intuitivas para los usuarios, los ERP, CRM, BI, … cada vez tienen menos de intuitivos y más de complejos. Si bien es cierto que hay procesos que lo son y por tanto difíciles de simplificar para el usuario, estoy seguro que siempre los desarrolladores podemos hacer algo más para cambiar esta tendencia realizando un diseño software centrado en los usuarios. Y entonando un mea culpa he de decir, que en mi caso, hay mucho margen de mejora.

También es cierto que simplificando simplificando, algún avezado usuario ha solicitado el botón mágico que una vez pulsado nos diga la situación económico-financiera de la empresa con un valor único.

A mi no me cuentes de balances, ni márgenes ni ratios. 
Yo solo quiero saber si gano o pierdo.
Un botón de esos que tiene el Bush que al pulsar 
me diga si gano o pierdo.

 

(Esta frase síntesis máxima de la simplificación -y simplismo- es real, oída hace unos años al gerente de una empresa, imaginar como terminó la implantación).

Bajo mi punto de vista, las reglas que ha de cumplir un ERP cualquiera para un diseño software orientado al cliente, son totalmente análogos a los que podamos exigir a una web. Y aunque es bastante habitual hablar de ello en el desarrollo web, no se hace el suficiente hincapié en otros tipos de software.

No es lo que hace el software, es lo que hace el usuario.

No es lo que hace el software, es lo que hace el usuario. (Fuente: Gapingvoid)

Veamos algunas de estas reglas que debe cumplir el diseño software.

Usabilidad

Podríamos resumirla en la eficiencia en la realización de las diversas tareas y en la percepción del usuario de éstas. La usabilidad debe estar dirigida, es decir, no puede satisfacer a cualquiera que se siente delante de la pantalla, pues sería imposible, pero sí de tratar de satisfacer las necesidades de la inmensa mayoría de usuarios que vayan a manejar la herramienta.

Accesibilidad

No exclusión de ningún usuario por limitaciones del software. Un ejemplo muy sencillo de entender sería: si el software no posee una
interfaz multiidioma, excluirá a un gran número de usuarios.

Visibilidad

Sistemas de búsqueda que nos permita localizar cualquier información. Formularios de consulta que permitan localizar cualquier dato
esté donde esté.

Utilidad

Todo proceso o tarea ha de estar orientada a un objetivo con un valor añadido. Ejemplos inútiles son todos aquellos que requieren intervenciones periódicas para corregir o regenerar ciertos datos. Si estos procesos necesariamente han de existir, mejor que sea el sistema capaz de realizarlo automáticamente y no requiera esa intervención humana.

Lógica y comprensibilidad

Igual que en una web no podemos exigir a un usuario que realice un proceso incomprensible e ilógico, podemos extrapolarlo a un ERP. Cualquier operación ha de ser coherente y lógica desde la perspectiva del usuario.

Entendimiento

Hablar en los mismos términos el software y el usuario no generará a éste una afinidad con el primero debido al uso del mismo lenguaje sino a evitar fallos de comprensión. En estos casos, los mejores sinónimos son los inexistentes. Por ejemplo, si el concepto es “Cliente”, siempre será “Cliente” y no “Entidad”, “Tercero”, …

Reducción de errores y/o malas prácticas

Muchos controles pueden realizarse sin un coste elevado para el desarrollador, evitando así errores descontrolados
que en ocasiones pueden provocar otros efectos indeseados. Un ejemplo muy sencillo de aplicar y que evita multitud de errores son máscaras de formato de fechas, números, etc.

Interactividad

Si el sistema va alertando al usuario de determinados eventos, deja a éste su tiempo para la realización de tareas de mayor valor, ofreciendo a éste avisos solo cuando requiere su atención. Esta interactividad es importante pero a su vez puede ocasionar un exceso de información al usuario y en ocasiones también un entorpecimiento de sus tareas habituales, por lo que debe ser medida adecuadamente.

Teclas de acceso rápido

Éstas permitirán agilizar las tareas cuando sean conocidas por el usuario.

Clarificación de mensajes

Diferenciar claramente mensajes informativos, restrictivos, de error, de decisión, de aviso, de progreso, etc. Categorizar estos avisos y que sean para el usuario lo suficiente explícitos en cada momento para evitar dudas por parte de éste.

Trazabilidad

Trazar cualquier dato a través de los flujos de información y de forma bidireccional. Ejemplo muy simple: saber en todo momento la relación entre un pedido, albarán, hoja de carga, factura, etc.

Estoy seguro que hay muchos más requisitos que debe cumplir el diseño software para considerar que está diseñado centrado en el usuario. ¿Cuáles se te ocurren a ti?

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly
Seguir en Feedly
 
Puedes compartir en ...
VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)
Diseño software centrado en usuarios, no en desarrolladores, 4.0 out of 5 based on 1 rating

Related Posts

10 Comments

  1. El modelo de capas de Gartner Mundo.erp | Tecnologías ERP
    15 Marzo, 2015 at 8:01 PM Responder

    […] un difícil equilibrio entre las necesidades de los usuarios y lo que los desarrolladores de sistemas informáticos están dispuestos a proporcionarles. Si bien los primeros tienden a percibir sus necesidades como […]

  2. ERP opensource | itblogpress
    2 Abril, 2014 at 7:29 PM Responder

    […] en software privativo. XYZ debe valorar si partir de un software ligeramente inferior en prestaciones y usabilidad pero con gran proyección frente a un software superior con menor […]

  3. El fenómeno de la verticalización - sectorización del ERP
    7 Enero, 2014 at 11:02 PM Responder

    […] de la sectorización del ERP, lo haremos a través de algunas características (solo algunas) de funcionalidad y usabilidad que deberían considerarse en un sector económico […]

  4. Ventajas e inconvenientes del software privativo en la gestión empresarial
    8 Diciembre, 2013 at 8:52 PM Responder

    […] Profesionalidad. Los consultores están altamente cualificados y poseen conocimiento del negocio al que se dirigen. Además, pueden ayudar a dar soluciones a ciertos procesos “enquistados” en la empresa. […]

  5. La intangibilidad del software. ¡Ah! ¿Pero eso cuesta dinero?
    14 Julio, 2013 at 7:58 PM Responder

    […] va a incorporar al estándar. Además, te pediría que hablaras con tu personal, y si aceptáis que determinadas especificaciones se realicen bajo un planteamiento distinto, el nuestro, estoy dispuesto a reconsiderar el precio, aunque quizá no cambie la fecha de […]

  6. Principales características para la elección de un software ERP
    4 Julio, 2013 at 12:04 AM Responder

    […] que denominaríamos usable en un término más amplio de la palabra. Acorde a los procesos y lógica de la empresa. Ágil, […]

  7. La relación entre cliente, analista y programador: ¿condenados a no entenderse?
    2 Junio, 2013 at 9:20 PM Responder

    […] Programador. Aquel que transforma la necesidad del cliente en código ejecutable para el ordenador, lidiando con las carencias de las especificaciones dadas por el analista y la falta de concreción del cliente. Resultado, un producto más orientado a sus necesidades que a la del cliente. […]

  8. Diseño software centrado en usuarios, no...
    26 Mayo, 2013 at 6:50 PM Responder

    […] Si bien el diseño web es un ejemplo de diseño software centrado en los usuarios, no suele ser así en otros software más complejos como los ERP, CRM, BI, …  […]

  9. Benjamín LIberman
    24 Mayo, 2013 at 7:12 PM Responder

    Es interesante reflexionar sobre estos conceptos que muchos desarolladores y empresas no tiene presente. Creo que la mejor manera es que quienes desarrollan “operen” el sistema en entorno real, para que ellos mismos perciban las dificultades que genera la forma en que el mismo fue diseñado.

    Otra idea que considero de valor, y pocas veces vi aplicada, es la necesidad de disponer de ayudas on line a nivel de cada campo, ya no solo como elemento que entregue el proveedor, sino la posibilidad de complementar dicha
    ayuda con comentarios (observaciones, recordatorios, etc.) que cada uno de ellos genere.

    Un punto no menor es identificar con precisión cada pantalla / reporte / mensaje / punto de menú, etc., con un código específico que permita mejorar la precisión con la cual se informen inconvenientes o errores a la mesa de ayuda del proveedor, o simplemente se solicite auxilio para operar.

    Creo que muchas de estas soluciones contribuirían a facilitar el uso de los aplicativos y, si hacemos bien las cuentas, representarían una ecuación “ganar-ganar” para clientes y desarolladores.

    • Sergio Martínez
      24 Mayo, 2013 at 9:11 PM Responder

      Gracias Benjamín por tu comentario.

      Como dices, ponerse en “la piel” del usuario es clave para realizar un diseño que sea operativo y funcional para éste. En ocasiones se busca la comodidad en el desarrollo en detrimento de los procesos del usuario y esto es una condena al fracaso a medio plazo por parte del software.

      Sin embargo, también es cierto que el usuario tiende a querer simplificar en exceso los procesos. Hace unos días me decía un cliente que porqué el ERP mostraba tantos mensajes al usuario incomodando al usuario. Cuando le dije que me mostrara algunos ejemplos, todos eran en la línea de cuestiones que el sistema no podía resolver por sí solo y que requería la intervención del usuario. Es decir, el software hacía preguntas al usuario para determinar el camino a seguir, sin embargo éste quería tal agilidad que cualquier pregunta le parecía improcedente. Y esto hay que hacerle ver al usuario que el software no puede tomar decisiones por sí solo y que requiere un mínimo de intervención humana para ir resolviendo esas cuestiones.

      Gracias de nuevo. Te animo a comentar cuanto quieras. Un abrazo.

Leave A Comment