Cualitativo

Si bien el producto estaba diseñado para que cualquier persona de un extracto social bajo y que con acceso a tecnología pudiera completarlo, empezamos a descubrir nuevos dolores en el registro en este caso, de la voz del usuario. Realizamos un operativo de llamadas y entrevistas para poder identificar de manera cualitativa, la opinión de ellos al utilizar el producto.

Dolores por contexto del usuario:

• La mayoría de los usuarios poseen teléfonos inteligentes, pero no son los últimos modelos.

• Los datos móviles son escasos y en algunas localidades el internet es lento.

• La mayoría no tiene una clave de seguridad para el bloqueo de su celular.

• A pesar de tener cierto dominio con la tecnología, no poseen conocimientos en detalle de las funcionalidades/configuraciones de su teléfono celular.

Estos datos representaban dolores poténciales a nivel de negocio ya que en su implementación:

• La aplicación no funcionaba en ciertas versiones de Android y IOS, y en la mayoría de los casos los usuarios no actualizaban su sistema operativo como de costumbre.

• Este Target de usuarios, mayormente utilizan los paquetes de datos móviles por día.

• Se requería que el usuario contara con un método de seguridad habilitado (Huella, patrón, PIN) a modo de seguridad, para poder utilizar la aplicación, y en algunos casos los usuarios no lo utilizaban por temor a no recordar su contraseña o no sabían como configurarlo.
  

Cómo también a nivel del producto:

• Los pasos del onboarding tardaban en cargar, lo que provocaba que el usuario abandonara el proceso o tuviera que iniciar de nuevo.

• Para abrir la aplicación era necesario tener una clave de seguridad en el bloqueo del celular y como se comentaba anteriormente, la mayoría no  sabían como generarla.

• Algunos mensajes de error no correspondían a un error real, lo que provocaba una sensación de frustración en los usuarios.

• Los microservicios a los que estaba conectado el sistema, en ocasiones eran inestables, lo que provocaba de cara al usuario una sensación de inseguridad con el producto.

→The solution

Luego de comprender el problema, a nivel de dirección se optó por realizar las modificaciones de manera paulatina, de manera que no representara un cambio drástico repentinamente y que afectara la operativa del día a día y comportamiento a nivel de los usuarios.

De cara a las limitaciones tecnológicas se optaron por revisar los microservicios con los proveedores para estabilizar y lograr mejoras en el rendimiento/tiempo de respuesta del aplicativo.

A nivel de producto revisamos los pasos más críticos donde los usuarios no completaban el proceso y aprovechamos para realizar unos leves ajustes que pudieran dar más contexto al usuario de que hacer en cada paso:

La nueva propuesta contenía:

1. Reubicar y agrupar datos similares en una sola pantalla, lo cuál ayudaría que a nivel del usuario, no tuviera la percepción de que el registro conllevaba muchas pantallas.

2. Nos apoyamos de elementos visuales para ejemplificar los pasos solicitados y que el usuario tuviera más contexto de lo que haría, cómo stepper y help text, así como ilustraciones más modernas y descriptivas.

3. A nivel directivo se optó por cambiar de proveedor del SDK utilizado para el escaneo del rostro y del documento de identidad. Esto nos favoreció ya que el nuevo proveedor contaba con una solución más simple y más customizable.

4. Optamos por evaluar la incorporación de Google Maps API para que las personas no tuvieran que completar su dirección completa, y que fuera el servicio que se encargara de suministrar la información, todo de manera transparente al usuario.

5. Revisamos los mensajes error, para incluir los que podíamos en el momento y no tener que desplegar modales innecesarios.