BONX: una herramienta para toda la compañía

Equipo de UX de NaranjaX
UX Naranja X
Published in
4 min readOct 7, 2021

--

Desde adentro hacia afuera

¿Escuchaste alguna vez esa frase? Bueno algo así nos estaba resonando, por eso pusimos el foco en el área de Operaciones, es un equipo fundamental dentro de la compañía, todo lo que ellos hacen tiene un gran impacto en la experiencia de quienes usan Naranja X. Operaciones trabaja con una gran variedad de herramientas y como ocurre en muchas empresas, la mayoría son de proveedores externos. Por eso, frente al crecimiento del negocio, se nos presentó el desafío de construir una solución que sea escalable, centralice varias funciones y nos permita mitigar la mayor cantidad de riesgos operacionales. Así, nació el BONX.

Una herramienta facilitadora

Te preguntarás, ¿qué es el BONX? Sus siglas indican: Back Office Naranja X. Es una solución diseñada y desarrollada enteramente de manera interna para cubrir las necesidades de los equipos internos y facilitar algunos procesos de trabajo. Nace en un escenario donde, por un lado, teníamos poco control y libertad en los cambios dentro de las plataformas que veníamos usando y, por otro, debíamos responder a las necesidades del negocio y cumplir con normativas reguladoras.

Para empezar nos planteamos un objetivo claro: queríamos que el BONX funcione como una herramienta disponible para que cualquier equipo pueda integrarse en poco tiempo y con bajo esfuerzo. A su vez, buscábamos remarcar el impacto que significa la mejora de los procesos internos para la experiencia de las personas usuarias de Naranja X.

Avanzando sobre una hoja en blanco

Antes de arrancar a diseñar trabajamos de manera colaborativa con las áreas de Producto y de Tecnología para pensar cuáles iban a ser las características del BONX. Además, implementamos la técnica de shadowing, método de observación que sirve para entender cómo trabaja una persona, y realizamos un benchmark de distintas plataformas.

Como resultado de todo este proceso nacieron los módulos. La herramienta necesitaba que cada módulo funcionara como un contenedor independiente a los demás, asociado a las tareas que realiza un equipo.

Después, acordamos cómo se iba a llamar cada bloque de información dentro de esos módulos y cuáles eran sus características, así al momento de escribir requerimientos, definiciones o historias de usuarios podíamos entendernos mucho más fácil.

Elección de nombres para la estructura del módulo

Una de las ventajas más grandes de diseñar herramientas internas es que las personas a las que queremos llevar nuestra solución son parte de la mesa de trabajo, o al menos así decidimos hacerlo.

Empezamos con dos encuentros semanales, donde a medida que íbamos relevando los procesos actuales del equipo de operaciones, dejábamos a grandes rasgos los primeros wireframes armados.

Los wireframes empezaron a tomar forma de manera rápida y consistente. Para esta etapa fue fundamental el equipo de UX Ops ya que Equis, nuestro sistema de diseño, aún estaba tomando forma, por lo que muchos componentes fueron armados desde cero. Hasta el momento, diseñamos cinco módulos, seis secciones y más de doce flujos. Estos módulos responden a las necesidades de múltiples equipos que realizan distintas tareas.

Retomando la característica de escalabilidad que queríamos que tenga el BONX, nos centramos en la funcionalidad de definir roles dentro de la herramienta para ajustar las vistas dependiendo de los permisos que tenga cada persona usuaria.

Veámoslo con un ejemplo: a la herramienta acceden dos colaboradores con roles distintos. Cada rol tiene asociados ciertos permisos que le permiten acceder a un módulo u otro, visualizar determinada información o ejecutar alguna acción.

Comparación de permisos asociados a un rol
Comparación de un mismo componente para dos roles distintos. Para el rol “A” la card muestra dos botones habilitados. Para el rol “B” no muestra los botones porque no tiene permiso de hacer esas acciones.
Un mismo componente para dos roles distintos

Nos pusimos a prueba

Armamos distintos tipos de pruebas de usabilidad, la mayoría de carácter evaluativo de los diseños propuestos. Luego, convocamos a quienes iban a trabajar con la solución para que el cambio en sus procesos de trabajo no sea tan brusco y puedan conocer la herramienta con anticipación para despejar sus dudas. Esto nos permitió hacer algunos ajustes antes de pasar la solución al equipo de desarrollo. Este modelo lo replicamos con los distintos equipos con los que trabajamos hasta el momento.

Finalmente, una vez que salimos a producción con una nueva funcionalidad, generamos canales de intercambio con los equipos. Fue un recurso que nos permitió mitigar errores de manera rápida y fomentar espacios de propuestas para mejorar la herramienta por parte de los protagonistas.

Seguimos trabajando en esta solución para hacerla cada vez más robusta. Varios equipos ya están sumándose de manera fácil y segura, reutilizando mucho de lo que ya tenemos construido y aprovechando las funcionalidades transversales que tenemos.

¿Qué aprendimos?

Diseñar una herramienta para toda la compañía es un proyecto enorme que pone a trabajar a muchos equipos en pos de un mismo objetivo. El BONX nos enfrenta a desafíos constantemente, tanto de usabilidad como de seguridad y de desarrollo, entre muchos otros. Nos invita a ser creativos y eficientes en cada una de las iniciativas para poder responder a las distintas necesidades que detectamos en la compañía.

--

--