VSLA Mobile App Considerations and Requirements

 Objective

• To design and develop a Android-based mobile app that can be used by users who manage and administer VSLAs

 Success metrics

 Assumptions

• iPhone shall not be supported as majority of Self-Funded Group Leaders/Members may not be able to afford iPhones. iPhone users may use the browser based responsive web-app to view reports, dashboards and group / member profiles.

 Functional and Technical Design considerations

1. Mobile app should be capable of being used in various countries across South America, Africa and India

2. Common user profiles:

   1. Group Leader - depending on the Geography, semi-literate to moderately-literate, responsible for the functioning of a group, but may not be very savvy with tech and extremely comfortable in using devices. The person is considered trusted by others in the Group and outside the Group. High usage of the App.

   2. Data Entry operator - hired specifically for ensuring that the data is fed into the MIS. Is usually comfortable with smartphones, speed of entry is critical, accuracy of data entry is very important.

   3. Group Member - with limited literacy and limited digital-literacy, simplicity is important and their main usage would be to look up their own profile, performance and status / balances. Intermittent app usage.

   4. NGO user / Field officer - dashboards are important, monitors, advises and may do data entry for multiple groups. Such users may be linked to an organizational hierarchy (like one or more blocks or villages or small towns)

3. Should support Multiple Local Languages / Localization - allow user to select language and also switch language

4. Simple Navigation - preferably via icons, reduce text and manual typing wherever possible. Design for Low Literacy and pleasing layout and UI/UX (icons / color / structure)

5. Meeting mode UI / UX

   • Sequence of logical steps (For example: go to “new meeting”, review last meeting, start meeting, take attendance, record all money-in-flows, record all money-out-flows, action items, review meeting summary, close meeting)

6. Visual dashboards that give clear picture

7. Offline first - with clear indication of what is not yet synced - Intermittent or poor internet - especially in remote rural areas in India or Africa. Offline app throws up its own set of challenges, like:

   1. How to ensure that at the time of syncing - the data is not already outdated. For example: data downloaded to mobile shows member balance as 1,000 and after that member has done a deposit / withdrawal via another channel and the server has the balance as 900. Mobile will still show the balance as 1,000. During sync process any such errors or discrepancies have to be handled

   2. Loan partial-payment or pre-payment - the logic needs to be built into the mobile app and cannot always be a server side business-logic implementation

   3. Partial-syncing or handling errors during syncing

8. Low-end Android Devices may be used (small screens / low RAM) - as usually they use their own personal phones

9. Should optimize storage and battery / power usage - as when the field officer / data entry operator is in the field, it may not be possible to easily charge a phone. Space requirements will include: size of app, offline data for groups and all members of group (including photos and IDs) , offline data for 3-4 meetings)

10. Others - Good to consider:

    1. Shared Devices - there is a possibility of the same phone being used by multiple users. Hence, when switching users - other user’s data should not get removed

    2. Voice-assisted navigation (local languages)

       1. “How to” content

       2. “Help” content / Videos for each screen

       3. Links to digital and financial literacy

    3. QR code / Member ID scanning - for identifying members

    4. Gamified Savings Progress

    5. Approach on how voting can be achieved - without making workflow hard to manage

 Requirements

 Out of Scope

• In this relase, mobile app will not support users at higher-levels (head-office or organisation-level or branch-level) viewing of data will not be supported. It will be restricted to Gorup leaders or data entry operators at the Group level

 UI/UX Design

For Dashboards (at Organization, Group and Member-Levels):

A dashboard view is needed for Groups and Members for Group Leaders and other users at Branch or Organization-Level to view the status and progress of Groups.

Functional scope for dashboard view, please refer: Dashboards for Self-Funded Groups

For the Group meeting flows:

Rough mobile app screen mock-ups: VSLA - Meeting - mobile app screen mock-ups

A typical meeting will go through the following logical screens:

1. Review Previous Meeting

2. Take Attendance

3. Record Cash-Inflows

   1. Deposits to Savings by Members

   2. Loan Repayments by Members

   3. Penalties / Charges from Members

4. Record Cash-Outflows

   1. Withdrawal from Savings of Members

   2. New Loans

5. Manage Members

6. Meeting Minutes / Action Items from Meeting

7. Review Meeting and Close Meeting

Another key aspect of the design is to also consider possible approaches for the following and to decide on the most feasible and practical approach for each of them:

• Assuming that “Offline first” is the right approach for the mobile app - for early repayments, late repayments, partial payments or excess payments etc. the interest / fees / penalties will need to be recomputed. Making the mobile app compute this would mean that the mobile app would also need majority of the loan transaction processing logic inside it. Another option would be that the mobile app does not do any computations. It will only capture the amount that the customer is paying. During the syncing with the backend server - the backend will do all computations and any excess, shortfall, penalties etc. would be computed and made due in the next meeting / next repayment

• Similar issue will exist for Savings penalties, profit-share computations and attendance penalties.

Open questions

 Reference Links