Project 1 : Predictive Covid Model
Project 2 : Volunteer Management Tool
PROBLEM STATEMENT
The iSPIRT team comprises of an approximate ~100 active volunteers at any given time. However, the cumulative number of individuals who have contributed to iSPIRT’s efforts over the years, without filtering against length of commitment, is much larger. Currently, the volunteers are identified via a Google Sheets database. However, this makes it impossible to track volunteer movements across the plethora of projects and internal roles over a long period of time.
SOLUTION OVERVIEW
To solve for the lack of an internal database, I developed a volunteer management system for the iSPIRT team. The tool is currently undergoing extensive beta-testing.
WORK SUMMARY
1. Understood the logistics and design behind the iSPIRT Volunteer Platform
2. Noted the pain points in the current system and outlined a high-level design for the tool via Trello Boards. The outline was edited and re-edited with feedback from the iSPIRT Leadership.
3. Designed a working prototype of the tool on Figma. This, too, was edited time and again with feedback from the iSPIRT Leadership and UI / UX specialists
4. Identified and researched the technology stack (Next.js, MongoDB, Azure Active Directory, OAuth 2.0) to build the volunteer management system
5. Developed the frontend in accordance with the Figma prototype
6. Designed the database schema and mapping between the frontend and backend (highlighting the backend process triggered when interacting with each component in the frontend)
7. Developed the backend in accordance with the frontend-backend map and database schema
8. Beta tested with iSPIRT Leadership (ongoing). Developing iterations with added features and edits to the system based on feedback received.
CURRENT SYSTEM
iSPIRT Volunteer Platform
iSPIRT is a not-for-profit think-tank where volunteers come together to build public goods for India. To maintain and manage a volunteer system, iSPIRT classifies its volunteers based on volunteer type, code of ethic level, rooms, pillars, and playgrounds to list a few.
The volunteer types used by iSPIRT include: 1. Balloon Volunteer, 2. Balloon Volunteer Alumni, 3. Volunteer, 4. Core Volunteer, 5. Anchor Volunteer, and 6. Volunteer Alumni. These are “states” a volunteer can go through during their iSPIRT journey.
There are 4 code of ethics levels: 1, 2, 3, and 4. These are analogous to security clearances that determine which “room” a volunteer can volunteer in, and are used to ensure the community’s interests are placed above any volunteer’s private interests.
Rooms, pillars, and playgrounds are metaphors used to classify projects. Volunteers work in rooms — this is where public goods are built. Each room is divided into four pillars (policy, market catalysts, playbooks, platforms). Playgrounds are where entrepreneurs use the public goods built in each of the four pillars.
The platform is governed by the Volunteer Fellowship Council (VFC).
Pain Points (for the VFC)
1. No data is present to track a volunteer’s history ie the volunteer’s journey through the different states, code of ethics levels, rooms, pillars, and playgrounds over time.
2. Changes in a volunteer’s state need to be manually updated on the excel database and on the iSPIRT website.
3. Every state change needs to be approved by each member of the VFC. This is done via social media channels before any edits are made to the database.
4. Comments can’t be associated with a volunteer’s progress.
5. The excel database captures only active volunteers and alumni. The platform does not track balloon volunteer alumni.
Pain Points (for Volunteers)
1. No public database is available that captures all the active and inactive volunteers. This makes it difficult to network with other volunteers when assistance is required.
2. No data is available surrounding volunteers’ expertise and specializations. This makes it difficult to network with other volunteers when assistance is required.
3. No single-sign-on (SSO) across the iSPIRT resources
DESIGN
1. High-Level Designs
Before designing the product, I first mapped the high-level volunteer journey:
2. Figma
DEVELOPMENT
1. Next.js: frontend and backend solution
Pages (click to see a screenshot of the page)
> login
> onboarding
> onboarding > home
> onboarding > volunteer_directory
> onboarding > volunteer_profile
> onboarding > personal_profile
> home
> volunteer_directory
> volunteer_profile
> personal_profile
> volunteer_handbook
> admin > analytics_activity
> admin > approvals
> admin > global_settings
> admin > global_settings_email_template
> admin > new_volunteer_profile
> logout
> api (hidden)
2. MongoDB: database solution
A NoSQL database has been used to store the variety of data available. Given below are a few schemas used to store data.
The volunteer schema is used to store volunteer information. The data format is slightly different depending on volunteer authentication (VFC Activity is shown solely for Volunteer Operations and VFC members).
The email templates are used to automate emails sent to volunteers when certain events occur.
The general settings allow dropdown options to be easily modified — a single modification to the settings updates the dropdown menus throughout the application.
The rooms are used to autocomplete volunteer rooms.
The admin control keeps track of users with admin access.
3. Active Directory: sso & identity and access management solution
Azure’s Active Directory solution has been used for identity and access management purposes. To that extent, the application functions as a user interface to the Active directory.
When a user is created on the application, a user is initialised on Active Directory as well. Depending on the volunteer’s type, the active directory enables SSO on Workplace by Facebook and Google Suite.
REFLECTION
My contribution
Over the last few months, I've been an active balloon volunteer with iSPIRT, helping develop Zastra, a volunteer management tool.
As the product designer, UI UX designer, and software engineer, I wore multiple hats throughout the creation of the tool.
My first role, as a product designer, involved the high-level mapping of the software solution. Before designing the tool, I first conversed with a few iSPIRT volunteers, including the VFC, Volunteer Operations, and regular volunteers. These conversations enabled me to understand the purpose driving the tool from different perspectives while also functioning as a foundation for the tool.
My second role, as a UI UX designer, involved the creation of working prototypes for the software. I fulfilled this role via using Figma and Adobe Creative Cloud. I interacted with the iSPIRT leadership throughout the design process, making minor and major modifications to adapt the designs for the primary audience. I also gleaned powerful insights from UI UX specialists who volunteer with iSPIRT.
My third role, as a software engineer, involved the development of the software. I utilized an extensive tech stack, including Next.Js, MongoDB, Active Directory, OAuth 2.0, Workplace by Facebook SSO, and Google Suite SSO. I began with the frontend, an area of old familiarity, and then sketched a mapping between frontend functionality and backend APIs before writing API routes for the backend. Amidst this process, I also created multiple schemas for the non-relational database, although I continued optimizing these schemas until the very end.
What I learned
The months I spent working on Zastra, the volunteer management tool, were packed with a plethora of learnings, some of which are encapsulated here:
1. Interacting with the most brilliant software engineers, data scientists, designers, journalists, and thought leaders in India, I learned how to create and deliver a solution that benefits the community.
2. This was the first full-stack application I made; I was new to the entire design and tech stack. Self-learning and understanding the stacks through documentation, existing source code, and other resources available on the internet, I developed the tool from the ground up. It took longer and resulted in me dedicating all my waking hours to the tool, but I learned how to self-learn and create for the real-world.
3. The opportunity to build a software solution, from design to development, really opened my eyes to different aspects of the process of creation. Undertaking these vastly different roles, with mentors to guide me through each role, I grew to understand and adopt the mental models and frameworks underlying each of these facets.
CIRCLE OF LIGHT
traditional art
KATHAK
traditional art
