Helping a finance team to speed-up
Company
Adamo Telecom
Role
Product Designer & UI Developer
Duration
Q3-Q4 2019
Why is this case study relevant? 💬
This project was done after my first year at Adamo and a lot of time has passed since.
Still, I wanted to include it as it showcases my ability to take on multiple roles—from research to front-end implementation. It also highlights my experience in qualitative research, requirements gathering, and my aspirations of design systems, all of which reflect my traits as a designer.
Finally, I wanted to include it as it is a good example of how when the user's needs are understood and properly addressed, the results can make people's lives easier.
Project Overview
I was tasked with the design of a tool dedicated to streamlining the Wholesale monthly billing process of a growing telecommunications company. They had a team of 2 people in charge of reviewing all orders month after month and things were getting harder to handle due to the growing number of orders.
A year after release, the Wholesale billing team had moved from +80,000 monthly orders to +220,000 while still being only 2 people and with a smaller number of incidents.
Discovery
For starters, I needed to understand the context. I didn't have the opportunity to conduct extensive benchmarking, as most similar applications required some form of subscription. Fortunately, I had easy access to all business knowledge and all the potential audience right down the hall.
Setting the scope
The wholesale infrastructure involved many actors. I needed to learn what parts of it should go into our tool and who were the rest of stakeholders.
Requirements gathering
Many business rules needed to be gathered and translated: from contracts to order exceptions, custom charges, and invoice generation. The thrilling world of finance!
User interviews
Finance team members were really supporting and on board, becoming the most valuable source of information and showing the actual ropes of the process.
Journey mapping
With all the information gathered, I defined a user journey to keep track of the user's path to the goal and the critical points they might face on their monthly billing process.
It became obvious that the main pain points for the user was the need to easily locate and approve or reject changes to orders, whether it was for an exceptional change in prices (a common selling strategy), a late addition from the previous months or any custom extra that could be added.
They needed a reliable tool that would bring them flexibility to overrule the system when necessary and ignore it the rest of the time.
Definition and development
With all the context now available, it was time to make sense out of it and start creating flows and defining the Information Architecture of the billing tool.
When it comes to visual design of the tool, we had already developed an in-house UI toolkit for all the internal projects the Product Team was involved in. This was the second project in which said toolkit was used and it filled most of the needs of the projects. For those cases where it didn't, we took the chance to scale the existing components to cover all the missing gaps (complex table cells with nested elements).
For the next few months we worked on the development of the tool. I was in charge of the design and the HTML & CSS development, but also of translating the requirements that I had been gathering during the Discovery phase.
I collaborated with the back-end team in the definition of the data modeling to ensure that the creation of new entities accurately represented the project needs and their reality.
Design improvements and missed opportunities
While the tool was being developed, we had periodic meetings with the finance team to ensure that the tool was covering their needs. These meetings helped keep the project lean and lead to some relevant changes on the design, like modifying the navigation to improve efficiency or show only orders with changes filter.
There were other things that were not included due to technology limitations, like bulk selection or real-time order status changes, requiring a more complex development effort, like inline editing instead of modal based interactions or simply because I missed them, like placing orders with changes on the top of the table.
However, I consider this project a success as it allowed the finance team to reduce the time spent on reviewing orders and reduced the number of incidents. Also, it was a great learning experience for me, since it allowed me to take as many roles as I have ever had within a single project.
