¿Testear o diseñar bien? Ese es el dilema

Escribe María Luisa Gutiérrez Ferrer.

En la industria del diseño digital circula la mítica frase de Robert Pressman, ejecutivo de IBM, que plasma muy bien las ventajas de testear en etapas tempranas de producción. La frase dice: Al invertir US$ 1 en la evaluación de un producto en su etapa de diseño, se ahorran US$ 10 si el test se hubiese aplicado durante el desarrollo y US$ 100 si éste se implementara una vez finalizado el sitio web.

Hay quienes cuestionan y argumentan ¿qué son US$ 100 hoy por hoy?, en alusión al bajo costo. El punto es que esos US$ 100 se multiplican por cada aspecto crítico o decisión tomada en relación con la manera en que concebimos las funcionalidades y contenidos, y la forma en que son comprendidas por los usuarios/clientes. Es en éste ámbito donde efectivamente el factor multiplicador puede significar ahorros significativos no sólo de dinero sino de tiempo a las empresas.

Diseñamos, no hacemos monitos

Cuando los equipos responsables de canales electrónicos o canal online de las empresas financieras alcanzan un grado de maduración, se observa cómo aumentan sus necesidades en torno a trabajar la experiencia de usuario.

Hay equipos que manifiestan su necesidad de realizar test de usuarios. Otros la de contar con la visión experta o heurística. Otros con contar con etapas previas para investigar en relación con clientes, y otros con madurar la bajada estratégica de la organización al canal electrónico respectivo.

Analizando estas necesidades, que por cierto son deseables, se observa que existen dos elementos que impiden realmente acogerlas.

1.- ¿Y el equipo de Diseño?:

Sucede que en los bancos no siempre existe una metodología habilitada que comprenda que la etapa de diseño de pantallas, armado de prototipos y navegación, no es asunto de quienes programan o desarrollan.

Es un tema que deberían abordar expertos en diseño conceptual, arquitectura de información, diseño de información, diseño de interacción, diseño visual, diseño y copy (textos), entre otros.

Esta labor consiste en comprender en profundidad el alcance del requerimiento comercial, la estrategia de los productos que se quieren habilitar en sus ámbitos de venta y post venta, para luego llegar a la mejor solución. Eso es diseñar. No es hacer monitos.

Luego, el porqué esta tarea no debe estar en los equipos de desarrollo, es obvia: porque no es su ámbito de competencia, no es allí donde agregan valor, sino en la programación. Luego, las consabidas observaciones que reciben los desarrolladores y que las asumen como afrentas a su trabajo, no debieran percibirse así. Pastelero a tus pasteles. La misión de los programadores debiese estar mucho más en ser fieles al diseño propuesto y a la capacidad de representar fielmente la riqueza de las interacciones, y ser capaces de ahorrar código, programar de forma limpia, y otros etcéteras que ellos mismos conocen.

Asimismo, los equipos responsables de los canales electrónicos nos siempre son los más idóneos para asumir la labor de Diseño. O al menos no el mismo equipo que lleva el día a día y que está viciado respecto del tipo de soluciones a las que se puede llegar, pues ya conocen lo que en materia de desarrollo implica menos esfuerzo, menos tiempo, y por tanto siempre se inclinarán por ofrecer este tipo de soluciones.

2.- La metodología:

No en todos los bancos está incorporado dentro de la metodología de desarrollo de proyectos una etapa de Test de Usuarios. Y en el caso que esté, ésta se considera más como una herramienta donde el canal le demuestra a los equipos de programación su error, cuando los test de usuario se alejan de ese objetivo.

Un test de usuario no debe entenderse como una manera de hacer ver a otros sus potenciales errores. Si se cae en el juego de egos internos, se está perdiendo un tiempo precioso que debiera usarse en algo tanto o más productivo como es comprobar (con personas de carne y hueso) si la solución a la que llegamos es o no comprendida y de fácil uso.

Por lo mismo, es crítico que se comprenda que los test con usuarios no deben emplearse tampoco como un arma para poner en juicio el parecer “con un me gusta o no me gusta, como si de Facebook se tratara- respecto de la interfaz que queremos testear. Más que ratificar si la aplicación, sitio web o interfaz mobile es “querible” por nuestros clientes, lo que debemos lograr son pruebas contundentes que demuestren el grado de comprensión y el logro de tareas concretas y objetivas.

Pastelero a tus pasteles

Testear o diseñar bien. Lo segundo sin duda. No sólo porque hay un ahorro de costos, sino porque si se deja en mano de reales expertos -diseñadores de interacción humano-computador quienes deben dibujar las interfaces-, estaremos ahorrando todas las iteraciones propias de un testeo, pues lo haremos correctamente desde un principio bien.

Esto que parece tan obvio, tan de sentido común, lamentablemente, no siempre lo es en la industria financiera. Hasta ahora existen equipos de desarrollo que creen que diseñar es hacer monitos, que no comprenden que sí se puede llegar a soluciones ultra comprobadas de buen diseño para formularios, para flujos con pasos, para crear una cuenta, para recuperar claves, etc, etc…

Existe un afán fatuo de inventar la rueda, que es comparable con cambiar todo el tiempo convenciones archi aceptadas como el funcionamiento de la circulación vial vehicular. Nadie se plantea si queda más bonito que ahora en los semáforos el color rojo esté abajo del semáforo y no arriba como lo ha estado desde la puesta en marcha de la señalización vial.

Hay un vicio por creernos más inteligentes si somos capaces de encontrar soluciones más creativas, siendo que no es necesario eso. Lo fundamental es poner a prueba si la solución o interfaz -para el particular uso de unos productos bancarios concretos, y por lo tanto para contextos específicos- se entiende de la manera en quelas áreas comerciales lo han pensado.

Testear o diseñar bien. Sin duda ambas cuando el nivel de madurez de un banco es tal que se ha llegado a la necesidad de contar con variadas precisiones. Precisiones relacionadas con el alcance de una interfaz, la interpretación y uso que hacen sus clientes/usuarios, pero no como arma para hacer pisar el palito a las áreas de desarrollo.

Por lo mismo, las áreas de desarrollo deberían abstenerse de pilotear, maquetear y dedicarse a una tarea no menor que es encontrar soluciones de código lo más eficientes para que las interacciones diseñadas estén apegadas a lo que inicialmente se diseñó, y para hacerlo con la mayor economía de código, utilizando la menor cantidad de llamados a otras aplicaciones y bases de datos.

De lo contrario, si no identificamos un área de diseño independiente del canal y de programación, el banco seguirá haciendo esfuerzos porque ambas áreas no actúen en silos, sin ir al fondo del asunto.

Los hechos parecen dar la razón. No en vano Capital One compró a Adaptive Path, consultora estadounidense líder en diseño de experiencia de usuario. Y BBVA acaba de adquirir Spring Studio, empresa californiana de diseño. La compra persigue acelerar los esfuerzos para convertirse en el banco digital líder a través del diseño y la tecnología. 

******

Compartir:

Twitter

Linkedin

Facebook