Novedad Velneo 22: Mejoras de diseño y rendimiento en vERP

Con la nueva versión Velneo 22 podremos disfrutar de la nueva versión de la plantilla de código abierto vERP, con un nuevo y más usable sistema de diseño, tanto a nivel usuario como a nivel código fuente. También se han aprovechado las novedades de Velneo 22 que ayudan a mejorar el rendimiento de las aplicaciones y se incluyen nuevas funcionalidades, como por ejemplo la conciliación bancaria. Maximiza tu desarrollo.

Ventajas principales:

  • Más ligera
  • Nuevo diseño
  • Más rápida que nunca

En el seminario online de presentación de las novedades de la versión, Rafael Cueto nos contó en qué consisten las principales mejoras de vERP:

Podéis conocer la lista de novedades más destacadas de esta versión en la página de novedades.

Si quieres conocer ésta y otras novedades en profundidad y aprender como aprovechar todas la ventajas de las versiones 21 y 22 de Velneo, no puedes perderte el Curso de actualización 2018, un curso online impartido por nuestros expertos. ¡Aprovecha la oportunidad y consigue el título de Desarrollador Certificado Velneo!

Este artículo Novedad Velneo 22: Mejoras de diseño y rendimiento en vERP es original de Velneo.

Diseño en software

Normalmente los desarrolladores no se caracterizan por cuidar el diseño de sus aplicaciones. En este divertido vídeo nuestro consultor Nicolás Osuna explica por qué los programadores deben centrar sus esfuerzos en el interfaz del software que desarrollan.

La experiencia de usuario y el diseño de la interfaz son muy importantes a la hora de programar software que interactúa con personas por la sencilla razón de que si no entienden lo que tienen delante en la pantalla no lo van a utilizar a no ser que les obliguen o que alguien dedique tiempo a enseñarles.

A menudo los desarrolladores ponen el foco en la funcionalidad que puede lograr el programa o la aplicación y se olvidan de escenarios que son muy comunes en la vida real, por ejemplo:

  • las personas que no ven bien, ven borroso o tiene daltonismo.
  • el entorno de trabajo del usuario
  • cómo esperan los usuarios que sea el flujo de trabajo
  • tendencias del usuario tales como mirar siempre a un lugar de la pantalla y evitar otros
  • tendencias del usuario con el ratón y el teclado, etc…

Por estas razones es que la investigación del comportamiento del usuario se ha convertido en algo tan importante. Hoy en día, con la gran competencia que hay en torno a la funcionalidad del software, el diseño estético y visual del software adquiere mayor relevancia a la hora de satisfacer al usuario, a la hora de destacar y hacer marca y ganar en reconocimiento e imagen de marca frente al usuario/cliente. Los iconos también son una parte fundamental del IU. Si no usas iconos estándar, las personas se van a confundir.

Otra cosa que conlleva implementar un buen diseño son las grandes micro-interacciones que se generan. Un ejemplo de una buen micro-interacción es el mensaje de error de Google Chrome que muestra un dinosaurio para comunicar que se ha perdido la conexión, en vez de mostrar un mensaje del tipo error code 163748Ahdhd2637  o también los distintivos de notificaciones (los circulitos rojos con el númerito) en los iconos de las apps de iOS.

Este artículo Diseño en software es original de Velneo.

El coste de una nueva funcionalidad en software

La mayoría de las empresas de software no tienen ni idea de como hacer que su software sea más sencillo de usar, lo que si saben es que nueva funcionalidad tienen que añadir  y eso es lo que hacen. Alan Cooper

.

Me estaba duchando y me fijé que los reguladores del agua siguen teniendo la misma funcionalidad que hace 30 años, regular la presión del agua y equilibrar la cantidad de agua caliente y fría que sale. La industria no ha parado de innovar en materiales, formas, diseños pero la cantidad de funcionalidad es la misma de hace 30 años. Cuando la informática llegue a los reguladores de las duchas aparecerán decenas de nuevas funcionalidades, última presión conocida, tiempo de la ducha en curso, cantidad de agua gastada, temperatura del agua, música,…. ¿Qué se te ocurre?

.

.

Somos verdaderas máquinas de crear funcionalidades que no valen para nada y que complican la función principal.

Mi primer coche me lo dejó mi abuelo Victor, era un Citroen Visa, su aparato de radio tenía 3 funcionalidades, volumen, radio, casete y poco más, aquel aparato me dio grandes tardes de buena música. Ahora mismo estoy escuchando música en el spotify de mi IPAD, con funcionalidades como; amigos, buscar, radio, listas, bandeja de entrada, recomendaciones, crear listas, conectar con Facebook, descargar a local, recomendar, destacar, artistas relacionados, historia de artista,.. Y podría seguir nombrando muchas más, lo más gracioso es que cuando tengo que regular el volumen de la música que estoy escuchando me cuesta encontrarlo porque tengo que regularlo directamente en el volumen del iPad. Soy un usuario muy simple y tan sólo uso un 10% de las funcionalidades de la aplicación, el problema es que el 90% restante me hace más complicado de usar ese 10%.

.

.

La diferencia entre lo digital y lo material

Incluir una nueva funcionalidad en un regulador de ducha o en un casette análogico tiene un gran coste. Crear nueva funcionalidad en un software requiere de un usuario con ideas y un programador con ganas, su coste tiende a cero. Este es el gran problema del software y su principal virtud, añadir nuevas funcionalidades tiende a coste cero y eso acaba convirtiéndose en funcionalidades que complican las principales funciones del producto original.  Las versiones de los productos de software año tras año añaden más y más cosas, lo que los hace más feos y difíciles de usar, los reguladores de ducha año tras año son más bellos, más fáciles de usar y más agradables.

.

.

regulador de ducha

20 consejos útiles de usabilidad y diseño

usabilidad Después de más de dos meses, compartiendo con vosotros consejos útiles y prácticos y recomendaciones, sobre usabilidad y diseño de interfaces de usuario, hemos realizado este resumen que recopila todo lo que hemos publicado hasta ahora.

Temas tan interesantes como: agrupación de elementos, espacios en blanco, estructura visual clara, convenciones de estilo, jerarquía visual, foco, ruido y recarga, simplificación, diferencias efectivas, revelación progresiva, flujo de tareas, limitaciones perceptivas, affordance, la primera impresión, pogosticking, la Ley de Fitts y terminando con formularios, sencillos y agradables: conversación y ruido.

Todo ello explicado de manera concisa, útil y práctica. Lee, aprende y aplica.

20 consejos prácticos de usabilidad y diseño de interfaces

¿A qué estás esperando para mejorar la usabilidad de tus productos y perfeccionar el diseño de los interfaces?.

La entrada 20 consejos útiles de usabilidad y diseño aparece primero en Velneo V7.

El formulario de 100.000 Euros

Lo que no tiene precio no se valora.

.

 Como programadores trabajamos en solucionar problemas complejos pero no estamos educados para pensar en los interfaces que los van a solucionar. El diseño de software no se valora, se piensa que un formulario vale lo mismo que otro, puedes pasar horas con un proceso, una función, un algoritmo pero tiramos los campos en un formulario sin pensar en el usuario que los va a realizar.

.

1.-Estoy tirando mi tiempo.

Llevo más de 40 horas trabajando en diseño del formulario de alta de un contacto de Velneo vbase . En algunos momentos te llegas a sentir frustrado pensando que estas perdiendo el tiempo invirtiendo tal cantidad de esfuerzo para conseguir ciertos efectos o funcionalidad en el diseño.

.

2.-El modelo de base de datos no es el modelo de interfaz.

Estamos acostumbrados a solucionar el problema en la base de datos y con ese mismo modelo implementar el interface, es como si nos hiciéramos un traje a medida y el resto de nuestra vida usáramos el mismo, cada contexto y situación es diferente, no nos vestimos igual en una boda, en un bautizo o en funeral, cada contexto tiene su interfaz. Hay que pensar en los diferentes usuarios y escenarios.

.

3.-El formulario de 100.000 euros

En el diseño parece que no hay forma de valorar el rendimiento económico. Con un sencillo test de usuarios, puedes medir cuanto tarda el usuario en realizar una nueva tarea.

En este caso hicimos unas pruebas de usuarios para dos tareas simples:

Tarea

Completada

Tiempo

Tarea 1.

Intefaz actual

Usuario 1 > SI

Usuario 2 > SI

Usuario 3 > SI

Usuario 4 > SI

Usuario 5 > NO

Usuario 1 > 1.10

Usuario 2 > 3.02

Usuario 3 > 1.24

Usuario 4 > 1.00

Usuario 5 > 2.53

Tarea 2.

Interfaz actual

Usuario 1 > SI

Usuario 2 > NO

Usuario 3 > NO

Usuario 4 > SI

Usuario 5 > NO

Usuario 1 > 2.30

Usuario 2 > 5.10

Usuario 3 > 4.56

Usuario 4 > 2.26
Usuario 5 > 2.57

Tarea 1.

Interfaz prototipo

Usuario 1 > SI

Usuario 2 > SI

Usuario 3 > SI

Usuario 4 > SI

Usuario 5 > SI

Usuario 1 > 0.21

Usuario 2 > 0.31

Usuario 3 > 0.29

Usuario 4 > 0.25

Usuario 5 > 0.16

Tarea 2.

Interfaz prototipo

Usuario 1 > SI

Usuario 2 > SI *

Usuario 3 > SI

Usuario 4 > NO

Usuario 5 > SI

Usuario 1 > 1.36

Usuario 2 > 1.54

Usuario 3 > 1.45

Usuario 4 > 1.10

Usuario 5 > 1.46

.

Se puede observar como el tiempo mínimo medio que estamos ahorrando en las dos tareas a cada usuario es de un minuto. Calculamos que Velneo vbase está generando un mínimo anual de 300.000 contactos nuevos de usuarios al año, si aplicamos el coste de 21€/hora de coste laboral en España, estamos ahorrando la friolera de 100.000 Euros/año en costes laborales en el uso Velneo vbase para la gestión de contactos.

.

4.-KISS (Keep it Simple Stupid)

La tarea más complicada es solucionar problemas complejos de base de datos con un interfaz simple. Velneo vbase soluciona todos los problemas de la base de datos de una manera completa y eficaz, ahora cuando hay que aplicarle un interfaz simple la cosa se complica. Aquí os dejo los mockup del interfaz actual y el nuevo prototipo.

Interfaz Actual:

interfaz actual1

Interfaz Prototipo:

nuevo1

interfaz2


(D/I) Diseño de interacción, técnicas

En los anteriores post sobre personajes, objetivos / tareas y escenarios expliqué como se articulan cada uno de estas herramientas. Llegó la hora de ponerlas en práctica, para ello os resumiré lo que debéis tener en cuenta.

Brainstorming

El brainstorming o lluvia de ideas. Para generar ideas y conceptos asociados a los escenarios, personajes, etc..

Las puntos importantes para llevar la sesión a buen puerto son:

  • La norma Nº 1 que no se debe romper NUNCA es no criticar o juzgar las ideas de cada uno de las personas que participan en el método, ya que unas ideas/conceptos se van “alimentando” de otras.
  • Antes de comenzar habrá que describir cual es el objetivo de esa sesión (Crear un personaje para la web tal, o las tareas a realizar para la APP cual, etc.)
  • Es importante que todos participantes aporten, aquí el buen royo y el no criticar es la base, todas las ideas tienen cabida.
  • Para que no se nos vaya de las manos, habrá que poner un límite de tiempo.
  • Una forma cómoda de partipar es usar post-it y que cada persona vaya pegando en la mesa, soltando ideas… que nadie haga de secretario…  se dice la idea en alto, se escribe y se pega sobre la mesa… y así consecutivamente. Si no se disponen de post-it usar boli y papel o una pizarra.

Refinado de ideas

Una vez tengamos muchas ideas, deberemos hacer selección de las mismas. Primero las agrupamos las ideas por afinidad y vamos descartando las que no cuadran o las que se repiten.

Documentación

Una vez tengamos las ideas seleccionadas y agrupadas es momento de dar forma a un documento que recoja esas ideas de forma ordenada y digerible.

Siguiendo estos pasos tendremos unas herramientas (personaje, escenarios, objetivos y tareas) que nos permitirán dar forma (tomando decisiones apropiadas) a la interfaz.

Prototipado

Existen muchas herramientas en internet, pero si no queréis complicaros la vida la herramienta más sencilla suele ser el lápiz y el papel.

La forma más rápida de avanzar es definir varios prototipos y cotejar el resultado con el personaje, los objetivos, sus tareas y escenarios de tal forma que nos permita ir mejorando esos prototipos, hasta llegar a uno óptimo que pasaremos a real.

En esta fase el look and feel todavía no es importante, y aunque para el prototipo más definido sí que hay que tenerlo en cuenta, podremos omitirlo pues nuestro objetivo debe ser saber si nuestro personaje entenderá el proceso, las etiquetas, la posición, etc…  Es decir debemos focalizar nuestras acciones en el esqueleto de la interfaz y omitir su piel.

Los prototipos esqueléticos debemos dotarlos de piel y músculos pasándolos a real y para ello deberán especificarse y es importante que lo hagamos de una forma secuencial y documentando hasta los mínimos detalles (valores por defecto, píxeles, iconos, alternativas, acciones dinámicas, etc..)

Probar

Una vez tengamos el prototipo en real, el siguiente paso será probarlo con usuarios reales (aunque lo hayamos hecho antes con los prototipos esqueleto), para este tema reservaré mi próximo post en donde explicaré las formas más prácticas, rápidas y sencillas de hacer test de usuario.

La entrada (D/I) Diseño de interacción, técnicas aparece primero en Velneo V7.

5 verdades sobre el diseño de software

¿Que es diseño? Un plan para colocar elementos de la mejor manera para logra un propósito en particular..

Charles Eames

.

1. La ingeniería de software es importante y difícil pero la experiencia de usuario es más  importante y algunas veces más complicada.

.

2. La funcionalidad y la experiencia de usuario son conceptos dependientes.

.

3. Tarde o temprano tendrás que testear tus ideas con usuarios reales para saber si lo que estás desarrollando realmente tiene valor y es usable.

.

4. Desarrolla un prototipo que te permita de una manera rápida  y frecuente probar con usuarios reales

.

5.  Necesitamos identificar un producto mínimo viable que cumpla los objetivos y tenga valor para el usuario, sea flexible, usable y factible minimizando el tiempo de puesta en marcha y la complejidad.

.

.

.


(D/I) Los escenarios

Para que se entienda que son los escenarios, voy a recurrir a una analogía muy socorrida para explicarlos:

Pensad en vuestra casa, en ella, cada una de las habitaciones (o zonas), se destina a cumplir un objetivo particular, a lo sumo dos (o tres…). Cada habitación cuenta con muebles, utensilios y los elementos necesarios, ordenados de una forma coherente y accesible, para realizar las tareas que os permitan alcanzar objetivos particulares asociados a esa habitación. Así por ejemplo, la cocina es para cocinar, el comedor es para comer o el despacho es para trabajar. Ocasionalmente podemos realizar las tareas que habitualmente se realizan en una habitación en otra, así podemos comer en la cocina, dormir en el salón (o en el despacho), o lavar la ropa en el baño. Si estas tareas se realizan en forma permanente y continuada en una habitación distinta que la original, veremos como la nueva habitación anfitriona se transforma para albergar los utensilios, herramientas y elementos necesarios para desarrollar la nueva tarea. Así, si por ejemplo el comedor lo usamos para trabajar, el ordenador, los elementos de escritorio, los documentos de referncia y demás elementos pasarán a la corta, o a la larga, a formar parte de ese decorado.

En definitiva, nos movemos por nuestra casa en la medida en que nos proponemos nuevos objetivos prácticos, pero no es sensato -ni cómodo- tener que cambiar de habitación para desarrollar las tareas necesarias para un sólo objetivo práctico. Imaginaros, teniendo que sacar los alimentos del congelador en el garaje, mezclar esos alimentos en el comedor y cocinarlos en la cocina para luego acabar lavando los utensilios en el lavavajillas situado al lado del pilón, junto a las lavadora y la secadora, desplazándose de un lugar a otro para preparar nuestra comida.

Pues bien, en una aplicación los escenarios son lo que para una casa son las habitaciones. Las áreas con utilidades que deben contar con todas las herramientas para que uno de los personajes alcance uno de sus objetivos prácticos.

Para definir escenarios, y relacionar estos con los personajes y sus objetivos prácticos, existe una base lógica de correspondencia, pero es necesario probar, abrir la mente, proponer ideas antes de alcanzar un conjunto de escenarios adecuado. Definir los escenarios no es una tarea mecánica, sino una tarea de diseño y por lo tanto requiere al mismo tiempo técnica y creatividad.

Los escenarios son el modelo de representación, que luego llenaremos de botones, menús y todo tipo de artefactos del Framework que decidamos usar. Definir correctamente los escenarios pensando en el/los personaje/s y sus objetivos prácticos, nos asegurará que la interfaz estará adaptada a su modelo mental, y no al modelo de implementación.

Tipos de escenarios

Es necesario saber que existen diferentes tipos de escenarios para posteriormente poder priorizar su importancia.

1. Escenarios de uso diario

  • Los personajes desarrollan la mayoría aplastante de su tareas.
  • Por aplicación suelen ser uno o dos, a lo sumo tres.
  • Los usuarios aprenden rápidamente trucos para dominarlos y los recordarán en la siguiente “visita” debido a su uso frecuente.
  • Puede ser que una aplicación, debido a su objetivo, no tenga escenarios de uso diario.
  • Los defectos y deficiencias en la interacción de este tipo de escenarios generan un experiencia de usuario dañina.
  • Deben reflejar el modelo mental
  • Es muy importante dedicar mimo y tiempo a diseñar este tipo de escenarios pues en ellos los usuarios se sentiran satisfechos o infelices con las consecuencias que ello conlleva a nivel de éxito de la aplicación.

EJ: Cuando se usa Word, pasamos el 99% del tiempo delante de la pantalla de edición (escenario 1). Puede que utilicemos a veces la función de combinar correspondencia (escenario 2), o la de crear nuevos estilos (escenario 3), pero hagamos lo que hagamos el escenario de uso diario de Word será el de la pantalla de edición (escenario 1).

2. Escenarios de uso periódico

  • Los personajes logran aquí objetivos concretos de manera esporádica.
  • Suele responder a un objetivo de un tipo de usuario determinado.
  • Es posible que una aplicación sólo tenga escenarios de tipo periódico. Por ejemplo un programa de copias de seguridad o un antivirus.
  • Su uso esporádico hace que los usuarios accedan a estos escenarios como si fuera la primera vez y se olvidan de los “trucos” que aprendieron la vez pasada.
  • El foco en este tipo de escenarios es realizar la tarea lo más rápido posible.
  • Deben reflejar el modelo mental

EJ: En Word, un escenario de uso periódico sería la función combinar correspondencia. Para la mayoría de los usuarios no es una funcionalidad que se utiliza más de una vez al mes.

3. Escenario de uso necesario

    • Estan hechas para satisfacer las necesidades de la aplicación.
    • Los sistemas de archivos y las pantallas de configuración son los máximos exponentes de este tipo de escenarios.
    • Los personajes no logran objetivos prácticos en este tipo de escenarios.
    • Son de uso muy esporádico.
    • Reflejan el modelo de implementación, exponiendo al personaje al sistema de archivos, las características del equipo y a otros detalles técnicos totalmente ajenos a los objetivos reales de estos.
    • Hay dos reglas básicas respecto a estos escenarios:

1. Tratar de eliminarlos.

          Tomar decisiones valientes por los usuarios. Programando para averiguar la información que necesita en vez de preguntarla. Incluyendo valores por defecto adecuados. Si no es posible esto:

2. Versión light.

        El software debe funcionar razonablemente bien sin necesidad de pasar por ningún escenario de uso necesario. Colocando unos valores por defecto que permita trabajar con la aplicación en una primera instancia y si es preciso poder modificar alguna configuración más adelante.

EJ: Los usuarios no suelen cambiar las pantallas por defecto que traen sus navegadores web. No es que no sepan como cambiarlo, es que no saben que se puede hacer. Para hacerlo usarían la pantalla de configuración, cosa que siendo sinceros la mayoría nunca ha usado, sólo los “frikis” por la tecnología.

4. Escenarios de caso límite

    • Los personajes se los encuentran en situaciones límite (el disco está lleno, el documento de un nombre tienen 1024 caracteres!, el modem no encuentra línea.
    • Son situaciones de borde, en las cuales la aplicación trata de rebasar la frontera de las capacidades y hay que tomar una decisión al respecto.
    • Desde el punto de vista de los usuario estas situaciones tienen una importancia mínima mientras se cumplas estos dos requisitos:

Primero.

          Conserven el trabajo realizado hasta el momento.

Segundo.

        Den la oportunidad de llamar a un técnico que resuelva el problema.

EJ: El personaje Antonio compró un PC con Windows XP que utiliza en su oficina hace ya tres años y jamás tuvo el menor cuidado del espacio en disco. Cuando el procesador de texto dio el mensaje de error de “disco lleno”, salvó el documento, cerró el editor, vació definitivamente la papelera de reciclaje y volvió a abrir el editor y a trabajar en el documento, como si nada hubiera pasado. Para ese personaje la situación límite fue intrascendente, ignora que quien programó el editor hizo maravillas para que cuando él apretara el botón guardar, el documento se guardara íntegro como todos los días, a pesar de que no había en el disco espacio suficiente para ello.

Agrupación y dedicación

Debemos agrupar los escenarios por tipo y como guía priorizar dedicando:

  • 75% del tiempo a los escenarios de tipo diario
  • 20% del tiempo para los de tipo periódico
  • 5% del tiempo para los de uso necesario
  • 0% del tiempo para los de caso límite.

No debemos confundir estos porcentajes de dedicación, con los porcentajes necesarios para la programación. Puede darse el caso que para implementar un escenario de tipo diario se consuma un 10% de tiempo de toda la fase de implementación, uno de uso periódico 20% o uno de uso necesario 30% y uno de límite 40%. Son dos fases distintas, una cosa es “desarrollar” la interacción y otra programar para que esa interacción se haga realidad.

En le próximo, y último post sobre el método de “Diseño de la interacción”, me pararé a hablar de técnicas prácticas para aplicar este método.

Hasta el próximo post!.

(D/I) Los objetivos

“El necesario reposicionar el foco y pasar de software que hace cosas a software que ayuda a quien lo usa a conseguir sus objetivos.”

Al igual que con la herramienta del personaje es importante que todos los implicados en el proyecto estén alineados en expectativas. Definir los problemas antes de empezar y alinear las expectativas de todos los participantes es la única forma de evitar sobre costes y  sobredimensión de trabajo.

Por lo tanto, después de determinar el personaje, el siguiente paso en el proceso de “Diseño de la interacción” es definir cuales son los objetivos de ese personaje.

Objetivos vs Tareas

Para definir los objetivos del personaje debemos comprender la diferencia que existe entre objetivos y tareas. Hay una relación profunda entre tareas y objetivos. Los objetivos se desdoblan en tareas y las tareas son a lo que dedicamos el tiempo, pero realmente lo que queremos son los objetivos.

Existen diferencias clave entre objetivos y tareas:

Y la última diferencia es que los objetivos son abstractos, intagibles y las tareas son precisas y vinculadas a la tecnología. Hace tal vez cientos de años que se barre el polvo en las casas, pero la forma en la que se hace ha variado radicalmente. Antes se usaba una rama con paja atada a un tronco y ahora en le mejor de los casos se usa una aspiradora robotizada, y el objetivo no ha variado “Trabajar para mantener un hogar agradable y limpio para vivir” como sí lo ha hecho la tecnología, que ha facilitado la tarea en gran medida para alcanzar el objetivo.

Funcionalidades vs funcional

Otro aspecto importante que debemos tener en cuenta es que no es lo mismo los features de una aplicación que los objetivos.

Esta tabla refleja un resumen de los “topicazos” sobre lo que piensa el programador y sobre la realidad de las features o funcionalidades de una aplicación.

Debemos hacer un diseño basado en objetivos y no en features, porque al desarrollar en base a una lista de features, se pierde el foco en los objetivos de los futuros usuarios, ya que los features se relacionan con las tareas, y se crea un software que hace cosas (funcionalidades) en vez de un software que ayuda a quien lo usa a conseguir sus objetivos (funcional).

Qué hay que tener en cuenta para definir objetivos y tareas

1. Se debe navegar entre los objetivos de los personajes, de modo que encontremos aquellos objetivos para los cuales la aplicación que estamos diseñando será una herramienta útil a la hora de alcanzarlos.

EJ: El objetivo de Juan es enviar propuesta a sus clientes con una presentación profesional.

2. Olvidarse del modelo de implementación, que no tiene en cuenta el personaje, y sustituirlo por el modelo mental.

EJ: Juan, el personaje del ejemplo anterior, entiende que al imprimir de alguna manera lo que imprime “pasa” por el driver, de allí al cable y de éste a la impresaora. En su modelo mental imprimir, driver, cable, impresora y cartucho son una unidad, un todo. Por el contrario, para la empresa de drivers son un costo muerto: se regalan. Las impresoras son solo un medio para vender cartuchos. Es posible imponer el modelo interno de la empresa y forzar al Juan a entenederlo, reformulando su modelo mental. Pero es imposible hacerlo sin que el Juan gaste un montón de energía.

3. Teoría de los 30 balines
Imaginar que el personaje tiene un rifle con 30 balines y que cada vez que se le presente una tarea para alcanzar su objetivo deberá gastar una balín, es un truco que ayuda a tomar decisiones. A más complejidad más balines.

EJ: El color estándar de los links “azul subrayado” no suele encajar con muchos diseño gráficos estilizados, pero también es cierto que no ponerlos en azul subrayado obligará al usuario a gastar un balín para encontralos. Y aunque no tiene nada de malo , usar links que no sean azul subrayados, si a ese balín le suma el balín que hay que gastar para que la página descargue en 1 minuto, y otro para leer los textos rojos sobre fondo azul, otro para entender la estructuras de productos diferente a la que el usuaro tiene en mente… entonces ya ponemos en peligro el éxito del desarrollo.

4. Comprender los tipos de objetivos del usuario. Existen 3 tipos:

  • A. Objetivos personales. Ser felíz es el objetivo personal por excelencia, pero no aporta nada al diseño de la interacción. Por eso debemos concretar. No es muy dificil encontrar a personas insultando duramente al ordenador, y esto se debe a que en las situaciones en las que se fuerza a las personas a actuar contra sus objetivos personales, estas se vuelven extremadamente violentas. Por lo tanto el software debería evitar a toda costa obligar a sus usuarios a caer en este tipo de situaciones y tener encuenta los objetivos personales como pueden ser:
    • Busqueda de la autoestima, sentirse útil
    • Crecimiento como persona
    • Cometer pocos errores
    • No sentirse tonto
    • Mostrar capacidad y competencia ante sus pares y superiores
    • etc.

    Los objetivos personales suelen ser comunes a todo tipo de personajes y no está de más recordarlos en el “diseño” de cada personaje.

  • B. Objetivos corporativos. Ninguna empresa adquirirá o desarrollará software con una expectativa distinta que la de acercarse a sus objetivos empresariales, por lo que diseñar software que no tome en cuenta estos objeitovs es un suicidio.
    De todas formas hay que tener en cuenta que si los individuos que usan el software no están satisfechos, harán todo lo que esté a su alcance para dejarlo fuera del negocio, incluso si la aplicación es capaz de alcanzar alguno de los objetivos corporativos:

    • Eficiencia
    • Reducción de costes
    • Mayor productividad
    • Reducir ciclos de negocio
    • etc.
  • C. Objetivos prácticos. Estos son los objetivos que actuan de bisagra entre los objetivos personales y los corporativos, y ayudan a definir el diseño de la interacción. Un objetivo corporativo “ganar participación de mercado” no dice demasiado, y el objetivo personal de “no sentirse tonto, cometer poco errores y realizar un cantidad adecuada de trabajo”, tampoco ayudan, el objetivo de “procesar en el día todos los pedidos recibidos” o ” enviar todas las propuestas en menos de 48 horas” si que dan pistas.Los objetivos prácticos son los que guían el diseño de la interacción, ya que son estos los que se alcanzan con la interacción hombre/ordenador.

5. Para el número de objetivos en más del 90% de los casos con uno o dos objetivos por personaje es lo correcto. Teniendo en cuenta que cuanto más objetivos más complejidad.

Y esto es todo. En el próximo post explicaré como ensamblar los personajes, sus objetivos/tareas y los escenarios.

Hasta el próximo post “(D/I) Los escenarios”