archivo

Archivo de la etiqueta: experiencia de usuario

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…

Pocas estrategias de desarrollo de sistemas de información han hecho más daño que orientarlos hacia sistemas tramitadores.

Esta estrategia ha añadido complejidad a procesos que durante años y años se han gestionado de manera casera o con recursos informáticos de manera más simple y que ha permitido a usuarios y gestores trabajar.

No se trata de no evolucionar hacia soluciones más productivas sino de entender que el empleo de tramitadores, salvo en circunstancias muy concretas, no proporciona valor al proceso (lo explico un poco más adelante).

En primer lugar porque el diseño de los procedimientos o flujogramas en los tramitadores se ha realizado, por regla general, de manera nefasta. ¿Por qué? Se ha considerado, en unos casos de manera más extrema y en otros de menos, que cada acción o tarea que realiza un usuario es una fase, lo que nos lleva a diagramas de decenas de fases (cuando no del orden de tres cifras).

No está mal tener esa secuencia de pasos, pero después debe adaptarse a un flujograma tramitable y eso no se consigue con tantas fases y transiciones, en las que los usuarios en lugar de realizar su trabajo lo que hacen es llevarse todo el día haciendo clicks con el ratón.

En segundo lugar los tramitadores tratan de darle uniformidad a procesos que en la realidad no la tienen ni la van a tener (lo de siempre: la informática no resuelve problemas organizativos), por lo que en el momento en haces más rígido lo que de manera natural necesita más flexibilidad provoca rechazo por parte del conjunto de usuarios, los cuales abandonarán el sistema y si no pueden hacerlo, tratarán por todos los medios de que su forma de trabajar habitual encaje en lo posible en el sistema, lo que impactará probablemente en la calidad del dato.

¿Por qué digo que salvo en casos concretos los tramitadores no proporcionan valor? Pues porque en la mayoría de los casos se ha metido con calzador, sistemas de información dentro de este paradigma por el simple hecho en muchos casos de querer controlar el estado o fase de un determinado procedimiento. Eso por sí solo no justifica el empleo de un tramitador.

Lo que sucede es que un sistema tramitador tiene por debajo un motor de tramitación y por encima una plataforma de tramitación (sea genérica o no) que proporcionan servicios de valor añadido al usuario, sin embargo esos servicios no son inherentes a un sistema tramitador sino que se han añadido a estas plataformas porque son recursos que necesita el usuario (envió de documentos a portafirmas electrónicos, almacenamiento de documentos en gestores documentales, registro y archivo de documentos, etc…) y perfectamente se podían haber definido fuera de las mismas de manera genérica en otro tipo de plataformas no orientadas a caminar dentro de un flujograma.

El sobrepeso también afecta a las aplicaciones. La mayoría de ellas son como el mando a distancia de una televisión, un montón de botones de los que solo usas un 20 o un 30%.

El sobrepeso es dañino en varios sentidos: el esfuerzo de haber desarrollado funcionalidades que no se utilizan o que tienen un uso residual, no haber invertido ese esfuerzo extra en depurar y mejorar las funcionalidades que sí resultan esenciales, la deuda técnica que se arrastra con ese código adicional y el impacto en la experiencia de usuario.

Cuesta luchar contra el origen del sobrepeso: la creación de necesidades inexistentes por parte de proveedores de software, la creatividad de los desarrolladores (y de algunos usuarios), la creencia errónea de que el software resuelve problemas organizaciones (y por tanto asumen funcionalidades que pretenden conseguir ese orden o esa forma de funcionar), etc…

En muchas organizaciones hay sistemas de información o herramientas (más de uno, más de dos y más de tres) que tras una inversión importante en tiempo y esfuerzo se quedan en una simple url o en un icono de escritorio accesible por sus potenciales usuarios pero olvidada y abandonada por estos.

Otras veces nos encontraremos con sistemas y herramientas que ni siquiera llegaron a terminar de construirse, quedando en simples ruinas cuyos vestigios puedan ser consultados, con suerte, en un sistema de control de versiones o en alguna máquina de un entorno de desarrollo o de un programador.

¿Qué nos lleva a esto? Generalmente el hecho de que se haya desarrollo o adquirido un sistema que no cumple con las expectativas del usuario a nivel funcional y/o de experiencia de usuario o bien que no cubra una necesidad real en la organización.

Hay aplicaciones que de un número potencial alto de usuarios y de uso, nos encontramos con que están infrautilizadas, para mi son tan ciudades fantasma como las anteriores, solo que en este caso hay unos cuantos héroes que de manera voluntaria u obligada hacen uso de las mismas.

Hay ciudades fantasmas recuperables pero para ello se requiere un esfuerzo importante y un compromiso de todas las partes: desarrolladores y área usuaria. Los primeros para tratar de ir mejorando de manera progresiva las condiciones de habitabilidad y los segundos para ir priorizando sus necesidades y soportar durante un tiempo unas condiciones de vida duras dentro de la ciudad.

Habrá veces donde lo mejor será buscar otro emplazamiento para la ciudad. Esta decisión es muy complicada de tomar ya que hay una inversión importante detrás y otra inversión importante que se tendrá que hacer de nuevo. No obstante si hay una necesidad que cubrir cuanto antes se tome la decisión mejor porque se corre el riesgo de seguir invirtiendo en algo que tarde o temprano se terminará convirtiendo en un montón de escombro.

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.

Hasta que el usuario no interacciona con el producto software no comprueba si sus expectativas están satisfechas.

Las expectativas van más allá de una visión funcional del software ya que es absolutamente fundamental que el usuario tenga una buena experiencia de uso. Tal vez usuarios con una gran capacidad de abstracción y que hayan dedicado mucho tiempo al proyecto puedan atisbar antes de interactuar con el producto si funcionalmente les satisface, pero la experiencia de uso no se tiene hasta que se utiliza.

Por ese motivo las metodologías clásicas no terminan de producir buenos resultados, ya que entienden que es posible acertar con todo desde el análisis y que si no, ya vendrá el mantenimiento. El problema que suele producirse en estos casos es que el presupuesto de mantenimiento no existe o de existir suele ser inferior a la envergadura de los cambios que van a ser necesarios.

El feedback del usuario es fundamental desde las etapas más tempranas posibles del desarrollo, de ahí la necesidad de ir construyendo y liberando el producto de manera progresiva.

Ordenador personal, ordenador personal con interfaz gráfica de usuario y revolución en el campo de la animación por ordenador. Tres grandes hitos a las espaldas de Steve Jobs, en los casi cuarenta y dos años con los que volvió a Apple.

Muchas cicatrices, interminables horas de trabajo.

Y seguía con hambre.

Volvió a Apple y tomó decisiones esenciales que permitieron sobrevivir a una empresa que estaba en profunda decadencia y con un futuro más que incierto.

Jobs seguía sintiendo a Apple como suya, como algo inseparable de él y así fue hasta el final. De hecho ese fue otro de sus grandes secretos, su identificación con una marca, a la que asoció a su causa, la continua innovación proporcionando nuevos productos a la sociedad que a su vez fomentaron a la competencia a ser cada vez mejor.

Tuve que hacer un importante recorte de gastos que tuvo como eje, la reducción del portfolio de productos a solo cuatro, un ordenador de sobremesa y un portátil dirigidos por un lado al ámbito doméstico y por otro al ámbito empresarial.

Se focalizan los esfuerzos en menos productos pero con el objetivo de centrar en ellos toda su atención. En este caso, menos es más, menos productos más calidad y más innovación.

Se rodeó de un equipo de confianza, esperaba una larga travesía en el desierto y para ello necesita contar con personas que compartieran sus decisiones. Eso lo llevó tanto al ámbito del Consejo de Administración como en los principales responsables de área.

Llevar la calidad a su máxima expresión, introduciendo el diseño como parte del propio producto y no solo como su envoltorio e innovar para sacar productos que no tengan competencia.

Para ello confió en una figura que en esta etapa sería relevante tanto para Jobs como para Apple. Jony Ive al frente del diseño industrial trabajando codo a codo con Jobs, desarrollaron diseños innovadores y transgresores para los productos, que si bien trajeron de cabeza a los ingenieros de Apple, proporcionaron una experiencia de usuario, en muchos casos incomparable al de otros productos similares.

Se intentó recuperar su imagen de marca, esa imagen que hacía que contase todavía con infinidad de incondicionales dado que debería pasar todavía bastante tiempo para enderezar el rumbo (cuesta mucho trabajo dar la vuelta a una deriva negativa), era necesario que esa masa de fieles se sintieran identificados con la causa y confiasen en que más pronto que tarde se recuperaría el espíritu que se estaba perdiendo.

Para ello puso en marcha la campaña Think Different, que trataba de expresar los valores de la compañía y de sus seguidores.

Jobs fue un revolucionario en la aplicación de las técnicas de marketing, ya lo hizo con el famoso anuncio de presentación del Mac en la Super Bowl y llevó esa práctica a lo largo de toda su carrera, si bien fue en su segunda etapa en Apple donde la explotó al máximo, no solo en los anuncios, sino en las propias presentaciones de los productos tanto en los meses previos a la misma como en su puesta en escena.