CheckPlus
Increasing the flow of check users' transactions through digitization.
My context
Icalia Labs Custom Dev team 2024 | Digital Product designer/ Design Lead | Figma | Ruby on Rails | MPV design and development
The Problems
Checkplus, a payment insurer from northern Mexico, was struggling to grow its service due to a generational issue: they work with physical checks! This made their sales approval process a never-ending nightmare of calls for their sales validation department. If they wanted to expand their client portfolio without their processes collapsing, they needed to go digital. The solution is obvious: a digital platform that would process sales automatically, but the real question to solve was...
Slow expansion due low process capacity
Validation time could went from 30 min to 2 hours on bussy days
How might we transition from traditional process to a digital solution?
The methodoloy
Discovery
Understanding Checkplus
To initiate the service, we conducted 3 discovery sessions aimed at, (if I may be redundant) discovering, how does your service work? Who are the actors in the validation process? How does the validation process function? What is the best-case scenario and the worst-case scenario? During these sessions, we mapped out 2 transaction flows for those that are paid, established the necessary actions for each participant in the service, and gathered the most significant insights for product ideation from the stakeholders.
Design
Replacing the paper check
During these conversations, we studied different ways to replace the paper check with a digital item. We started with the idea of turning it into a "digital credit with a card" but this created misunderstandings with stakeholders about their service, as they are not a fintech and did not want to be associated with one. This insight cleared up many doubts and options; ultimately, we decided to use a QR code that contained the transaction data as a way to digitize a check.
QR Instead of checks
We transform the process of filling a paper check into activating a QR, this with the objective of keeping the “portability” of the check and provide control to the buyer credit line.
more of this in “MANAGING STAFF”
From 30 minutes validation
To Instantly
We transform the process of filling a paper check into activating a QR, this with the objective of keeping the “portability” of the check and provide control to the buyer credit line.
more of this in “MANAGING STAFF”
Design
Trracking the transactions
Aa mentioned before, Checkplus had a platform where they display transaction statues for their users this display was only informative and users couldn’t do any action on those transactions, like validate payments or report no payments. I design a a new transaction system where users can not only view their transactions but have control over them with out the intervening of CheckPlus.
Displaying transactions
After analyze the service flow we identified all the possible scenarios for a transaction, which was nothing more than 10 possible statues, this was a challenge in terms of information display, i wanted to keep the transaction cards informative but compacted due the amount of transaction a single sealer could have. i identified the most important information from a transaction to be displayed in the preview and categorize them in 4 different types: Expired, Due, Paid and Canceled
Categorizing transactions
I split the transactions into four categories for an easy read and understatement, this division was reinforced with a traffic light systems per transaction status
Options by status
The truth is that from the buyer side the only action they can perform is upload payment receipts for the seller to validate. But from the seller side, they can perform different actions based on transaction status.
Buyer actions:
- Upload payment receipts
- View Payment receipts
- Change payment receipts
Seller actions:
- Cancel sales
- Provide payment extensions.
- View Receipts
- Validate or reject payment receipts
- Report sales
Design
Staff members
A common scenario that came to mind while our discover sessions was that Account owners give paper checks to their employees to perform sales under their names and also the existence of cashiers from the seller side. Over this line it was obvious we have to give both buyers and sellers the feature to have a staff to help them perform purchases and sales. I set 3 state for staff members, "Active", "unactive" and "invited" and 3 main roles, "Owner" the account owner, "Admin" account admin and "Seller or Buyer" the basic role to performance sales or purchases.
Managing Staff
An owner or administrator can manage their employees, view their recent activity, and invite or deactivate them as needed. Additionally, administrators and owners on the buying side can assign purchase codes to other members of their staff.
Adjusting designs decisions
Throughout the design, planing and development phases were moments that make me do minimal changes for the good of the overall process
One platform, two experiences
Due this was a web platform and not an mobile app, we packed everything in one platform where base on your user you get to one experience or another, i also make sure they look clear different using brand colors to avoid experience mistakes not just for the users but developers know what path they were working on.
Devices without Camera?
A key moment in the final stages of development was a conversation we had regarding sub-users and portability, where we noted that some collectors are "static" Our initial proposal was for a highly portable platform that could primarily be accessed on mobile devices; however, we made adaptations to ensure it could also be accessible from a computer that does not have a camera to scan codes, starting with the addition of a numeric code alongside the QR code as another method of validation.
Launch
Adopting a new payment method
After the launch of the platform, we held conversations with 15 former users of the CheckPlus service and 5 users who were just starting with the service to gather their impressions on the new format of the service. The results were positive, but not what we expected. Despite understanding the benefits of the new service format, some former CheckPlus users faced difficulties using the platform and completing specific tasks, such as reporting a sale, requesting an extension, or validating payments, which, due to time constraints, were the workflows that received the least development attention.
72%
of historical users felt enthusiastic about the new platform
83%
of new users showed interest in the renewed service
transition helper
Despite having received good validation from the interviewees, we decided to take their recommendations to implement actions on our side that could facilitate a better transition from the old service to the new one. Since we no longer had time for development, our efforts were focused on creating "physical" materials by producing and delivering two digital user manuals, one for The buyer and the other forThe seller (both in spanish).
What would i do different
There is obviously a significant burden when developing an application solely based on stakeholders as the only reference for how the application should be. This is something very common that I regularly have to deal with due to the nature of MVPs; budgets are not very high and are completely focused on development. Without a doubt, if I were to go through this situation again, I would try to conduct additional validations with users of the platform during the design phase, not just at the end of the MVP.
Even though my entire focus was on transforming a conventional process into a digital one, I dedicated little time to onboarding within the application. This was later attempted to be addressed with a manual due to development time and costs; however, the idea of having everything within the platform without the need to leave it is the ideal for any application. This has helped me think more carefully about how to communicate the use of a new tool to a new user in future projects.
What did i learn?
Due to the development time and the complexity it posed for the developers to adapt to the system they already had, the project was delayed a bit. This prompted me to raise my hand and offer to help with the front-end layout, which allowed me to improve my technical skills with Ruby on Rails, gaining a better understanding of how to use action views and active records in Rails. Additionally, I learned how to enhance the delivery of designs and components specifically tailored for this language, improving my compositions to work better with Rails layouts and partials.