Designing a collaborative book-keeping experience
Manual tallying of ledgers (business-accounts) is a tedious and time-consuming process for business owners. Typically, business owners maintain separate logs (of accounts due and accounts receivables) with one-another, meaning they have to tally these logs at the end of each month. To solve this pain-point, we designed a collaborative experience, where both parties maintain a shared-log, increasing transparency and reducing misalignment.
.png)
Duration
4 months
October 2022 - January 2023
Responsibilities
Product Designer
UX research, UX design, Testing,
UI
Team
4 members
1 Researcher, 2 Product Designers, 1 PM
Background
Company Background
CreditBook is a book-keeping app that helps MSMEs (Micro, Small & Medium Enterprises) manage their business finances. Currently, the app is focused on helping entrepreneurs improve cash-flows by helping them maintain accounts receivables via a digital ledger.
.png)
CreditBook landing screen
Problem Context & Opportunity
Maintaining ledgers is conventionally a solo activity. Two business owners (who conduct business with each other) record business transactions against one another on their individual ledgers (paper-based or in our case the CreditBook app). Then, at the end of each month, both people go through the process of manually tallying their ledgers with one another in order to align on discrepancies and settle dues. This process is not only time-consuming and tedious but also repetitive and redundant work.
Given this background and problem context, we saw an opportunity to increase transparency and reduce logistical hassle (of tallying) for business owners by introducing a book-keeping experience that is collaborative.
An example of a paper based ledger that a business owner will typically maintain. The counter party he does business with maintains a ledger of the same transactions on his end and the two tally with each other at the end of the month
An example of a digital (app-based) ledger that a business owner maintains using the CreditBook app. This is a huge move up from paper-based registers in terms of convenience and ease, but is still a solo-activity and requires tallying and sorting out at the end of each month.
My role and design process
For this project I served as the Sr. Product Designer, working together with the product manager, I worked cross-functionally with a team of engineers, designers, and user-researchers. My role entailed:
-
Driving clarity on the user why, i.e. what user-problem are we trying to solve and does it really exist?
-
Balancing user-needs with the business needs and strategy.
-
Synthesizing research and user-feedback to help the team make better and more informed design decisions.
-
Working closely with the engineering manager to consider and make decisions on technical trade-offs during prototyping and design.
Defining the Whys
Before investing time and resources into any initiative it is important to be clear around the key reasons for pursuing said initiative. In my role as a Sr. Product Designer, I am responsible for clearly defining the user-why and ideating how user's why can help the business-why.
User-why
The entire process stared with the observation that the current ledger tallying process is tedious and time-consuming, and perhaps a more collaborative experience would help mitigate for this. In this vain, it was clear that the user-why was around reducing the logistical hassle of tallying and increasing transparency amongst business-partners. All competitor ledger apps in the market were single-entry ledgers, thus were all tedious and time-consuming.
Business-why
CreditBook is a financial technology company with the aim of providing helping MSMEs business-management and access to capital (i.e. businesses financing). In order to do that responsibly it is imperative for the us to have high-quality data on businesses so that we can offer them customized financial products, at the right-time in their business journey.
User Research
No. of Users
15 users interviewed
7 in Lahore (involved), 8 in Karachi (not involved)
Supply Chain Position
Wholesale and Retail
10 Wholesalers, 5 Retailers
Age Bracket
28 - 60
Before going into user-research we needed to be clear about the specific questions and hypotheses to test. Since we were working with the broad theme of turning solo book-keeping into a more collaborative and shared experience, here are the key questions that I outlined for us to look into:
-
Is tallying even a pain-point for users?
-
How open are users to actually maintaining a shared-log with their counter-parties?
-
Are there any concerns around privacy and data-security?
-
What does a shared-experience mean to users?
-
What language should we use when communicating to users about a shared-experience?
Methodology
During this first phase of exploratory research, we split up into two pairs. I teamed up with our product manager and together we conducted exploratory research in Lahore. The second pair consisted of user-researchers who conducted research in Karachi.
To conduct qualitative research, we started off by talking to users to understand their perspective on the concept of a shared ledger experience as a whole and their experience around the tallying process. After that we showed them two prototypes (as shown below) that tested different levels of sharing with the other party. The use of these prototypes was not to test the user flows, but instead to understand the user sentiment towards the concept of shared experience for book-keeping.
Prototype #1: Focused on testing user reactions on sharing entire ledger with other person. The text on the pop-up says:
Tally your ledger
Share your entire ledger with Ghulam Rasool to tally all your entries.
Prototype #2: Focused on testing user reaction to individual transaction (entry-wise) sharing. The text on the pop-up says:
Ghulam Rasool has tallied this specific entry
Results
10/15 of the users we spoke to said that a more collaborative experience would help them save time. Upon digging deeper on how they saw such an experience saving them time, users cited the following:
-
The feature would provide both parties constant transparency over their transactions.
-
Would spare users from having to deal with the trouble of calling their suppliers, customers, or other stakeholders to tally data.
-
Would save hassle and back-and-forth caused by mis-alignment when maintain separate logs.
5/15 users expressed some concerns around the concept.
-
They thought that having a shared ledger might result in more confusion for both parties in terms of understanding balances due.
-
There were concerns around accountability and responsibility, i.e. who would be responsible for the shared log?
-
Suppliers and customers users work with are sometimes not digitally savvy, how would such counter-parties be able to participate in this collaborative experience?
-
Some only wanted to maintain logs privately and not did not want a shared experience.
-
Users also expressed concerns around privacy and that ledger-data is private and not meant to be shared.
Key takeaways from research
-
There was a clear need for a shared ledger experience amongst users. Such an experience would save them time, effort, and sometimes even travel costs that users incur while traveling to get their ledgers tallied with counter parties.
-
A majority preferred a fully-collaborative shared experience as opposed to sharing at an individual transaction level. They found the latter to be too time consuming.
-
“Tally” is a widely understood word in the market and should therefore be kept in mind as a key UX wedge when designing the feature!
-
Users were more comfortable and familiar with the term “Joint ledger” as opposed to “shared ledger”.
-
Some users did not want to share their ledgers. This was particularly interesting because sharing ledger-reports with customers is one of the more popular features (screenshot attached below for reference) of our app which was actually also used by the business-owners who had apprehensions around privacy. So while some users might have expressed apprehensions around sharing data, that was a behavior they were already engaging in!
-
On probing why these users did not want to share, they cited privacy as the main reason and that ledgers are meant to be private and not to be shared. More on this later.
Through this research, we were able to build conviction for the feature and were now more confident in taking this to the design phase.
Design kickoff: Journey map
Excerpt from the journey map for one of the core-flows in the feature. This is the core journey for User 1 who starts off by initiating the shared-ledger experience and then loops in User 2 by sharing a URL.
Mid-fidelity flows and Usability testing
With all the learnings up-to this point we went into the design phase. Here I created the core journeys of the feature (inviting existing customers to the shared-ledger experience, chat and voice note interactivity, the webapp flow for customers who were not CreditBook users already, deletion journey). Once the basic journeys were set, I closely coordinated with the junior designer, product manager, UX writer and illustrator to make sure that we clearly articulate the value proposition to the users, the “why” behind this feature and key constraints and considerations through designs:
-
We were going to design for a fully collaborative and shared experience as opposed to individual transaction sharing. The reasons being:
-
Most users preferred the fully shared experience over the individual transaction sharing.
-
Users who did prefer transaction level sharing did so out of concerns around privacy. However as cited earlier, these same users (and more) already engaged in data-sharing behavior to the extent that the app currently allowed.
-
Furthermore, individual transaction sharing also did not make sense given the high-level objective of reducing hassle and effort. Any model that focused on transaction level sharing would require a-lot of repetitive actions from the user.
-
-
We needed to cater to both users, those would want to opt for a shared model and also those who would want to maintain separate ledgers.
-
Needed to put a lot of focus on educating users about what it means to be on a shared model in language they are familiar with.
-
We had to be particular about the UX writing for the feature, use terms like “tally” and “joint” which have come up repeatedly during research.
-
We then came up with two core flows to test with users. The main difference being the point in the journey where we asked the user to choose between a shared and a private ledger.
For usability testing, we created the prototypes in mid-fidelity because we realised that using low-fi screens in the prototypes confused the user.
Share your joint khata with Ahmed and rid yourself from the hassle of tallying. Ahmed will be able to view this ledger and also make entries in it.
Second key step in flow 1, after selecting “Joint Khata” user was shown a pop-up educating them about the flow. The text in the pop-up says:
Share your joint ledger with Ahmed and rid yourself from the hassle of tallying. Ahmed will be able to view this ledger and also make entries in it.
First key step in flow 2 where the user was shown the option of normal vs joint at the first step of the journey (right when they start the process of adding a contact and creating a khata).
Second key step in flow 2 where after selecting Joint Khata the user was shown a pop-up educating them about what this means. The text says:
You and your customer will run this ledger together. Your customer can see this ledger and also make entries in it.
Usability Testing
No. of Participants
12 Participants
8 in Lahore, 4 in Karachi
Responsibilities
Moderator for Lahore based participants
Method
In-person testing with contextual setting
For usability testing we went out in two pairs again as before. During this phase I went out with both the product manager and user-researcher and the insights we gathered were primarily focused on how easily users were able to understand each flow. The key takeaways were:
-
75% of the users preferred flow 2. The first flow was confusing as it asked them to select between the two options way too early in the journey as opposed to flow 2 where they were at the last step of the journey and already selecting other relevant information about the ledger type.
-
85% users were able to understand the term "joint".
-
30-40% of the users missed the option selection in the first flow initially, it was too subtle for them and they needed something that stood out more.
-
More than half users also missed out the selection option in flow two initially, once again because it was too subtle.
Picture taken during our visit to an arcade-shop owner for usability testing ~ Ferozpur Road in Lahore.
Final UI
.png)
*placeholder video used in designs
Onboarding
-
Videos, tool tips and overlays were used to educate the user about the new feature
-
Over time, I have learned that short, quick videos are best to educate the user base that we were targeting because it requires less visual and mental load
-
For the onboarding journey, we had to inform user clearly that the ledger they create will be shared and both parties could see the entries
User A could create a customer in CreditBook app
User A would then share the link to joint (shared) ledger over WhatsApp
User B would be able to view the entries in the ledger by user A by clicking on the shared link and opening the web-view
User B would be then prompted to download the CreditBook app if they wanted to make entries or chat with user A
Creating and sharing a "Joint ledger"
-
If user A wanted to create a joint ledger with user B, then they were prompted to add user B as a contact first
-
Once user B was added to user A's ledger, user A was prompted to share the link to the ledger to user B (if they were not already on CreditBook platform)
-
User B could then click on the link and view transaction details added by user A
-
User B was also prompted to download the app so that they could make entries or chat with user A
Whenever user B makes an entry or edits/deletes an entry in the ledger, user A is notified
Red banner informs user A that an entry has been deleted
User A can click on the banner in the previous screen. Clicking on the banner leads to the entry deleted by user B
Users can also react to entries made
Entries to the joint ledger
-
User A is informed of all the actions (edit, delete, unlink, react, etc) performed by user B through notifications, and vice versa
-
Giving complete visibility to both parties over the actions performed by the other person was important for the success of the feature because ultimately, it impacted the final calculations of these businesses
Users could use the chat box to message each other
The text box was differently coloured to set it apart from the transaction boxes
Users could also send each other voice notes
Text boxes and voice note boxes were coloured same to keep the distinction between transactions and communication
Integrated chat feature
-
During research, we noticed that users switched between CreditBook app and WhatsApp to communicate with their customers. To facilitate this behaviour, I added a chat feature in the joint ledger flow
-
To use the feature, both users should be CreditBook users
-
Since a lot of our users belonged to low-literacy group, a voice note option was also included
Project Learnings
Ask them to fill the gaps
Instead of showing the complete prototypes to users for complex features, show them a snippet of the journey and allow them to narrate the missing gaps. This allows you to understand how the user sees a complex journey in their mind
Speak in their language
Words like "sharing" and "collaborative" are confusing to the user. Instead, we should use the language that they use in their day to day life in our designs for communicate
Not everything needs to be perfect
This was a complex journey to ideate, research, wireframe and design. The complete journey had 50+ screens. During the process, I realised that complex systems such as this are not made in one iteration. They need improvements.
When in doubt, use a video
Usage of videos during onboarding helped us explain a large feature in few seconds. It was easier and more effective to use videos instead of tooltips or extra text
Future Considerations
The joint-ledger feature was recently launched and we have initial user feedback
-
Users have requested a de-linking option of a shared ledger. I have started working on this
-
Users have appreciated the feature since it saves them time, so now the feature will be launched to complete user base (it was launched as an experiment to 10% user base)
-
Few users have also requested the ability to share a ledger without allowing the other user to make entries in the ledger