Case Study: CBIT Study Buddy

⚡ THE QUICK RECEIPTS (TL;DR)

The Problem: CBIT has a 70:1 student-to-faculty ratio, so professors don't have the bandwidth to answer everyone's questions — but students had already found their own workaround: clustering together before exams to teach each other.
What I Did: Ran a competitive analysis of existing study-matching apps, then designed and prototyped (paper → Figma) an app that turns that informal habit into something findable and repeatable.
Headline Outcome: A validated design direction — buddy-matching + a shared notes repository — with usability testing as the clear next step.

01. The Scene // "70 people, one professor"

Picture a lecture hall built for 70 students per professor. That's not a typo — that's the actual ratio at Chaitanya Bharathi Institute of Technology. When you're one of 70, "raise your hand and ask" isn't realistic, and professors are optimizing for getting through the syllabus, not for making sure everyone follows along.

So students adapted. Around midterms and finals, you'd see it everywhere — small clusters on the lawn, in hallways, wherever there was space, students explaining concepts to each other because nobody else had the bandwidth to. It clearly worked. It just only happened when the stakes were high enough to force it, and only among people who already knew each other.

"Finding people to study with is hard. Is there a place to find study buddies?" — framing question that shaped the design direction

That gap became my research question: how can we promote collaboration among CBIT students and make peer learning a consistent practice, not just a pre-finals scramble?

02. What I Actually Did // "Doing the real homework"

Three directions came out of thinking through the problem space: paper fliers for students to post contact info, designated open study spaces around campus, or an app to help students find study buddies and share notes. I moved forward with structured research to figure out which — if any — was actually worth building.

Research Question: How can we promote collaboration in CBIT students and make peer learning a consistent practice in their academic journey?
Competitive Analysis: Evaluated four existing tools in the studying/note-sharing space — StudyStream, Navigate360's Study Buddy feature, StudyBuddy.it, and Tirimiri — to see what already works and where they fall short for a single-campus, shared-course-catalog use case.
Prototyping Progression: Paper prototype first (to test structure before touching software), then a full digital prototype in Figma covering buddy search, buddy/group profiles, request-sending, and the notes repository.
Decision Framework: Used QOC (Questions/Options/Criteria) analysis to make deliberate, arguable calls about target audience fit and feature scope, rather than relying on instinct alone.

[ competitive analysis grid + paper prototype photos go here ]

03. The Messy Middle // "The easy answer wasn't the right one"

The honest version: the easy answer here was to just build a Find-a-Buddy matching feature and call it done. That would have technically solved the literal problem statement.

⚠️

The Pivot: Sitting with the QOC analysis surfaced something the simple version would've missed — not every student who needs peer learning wants to go through the (slightly vulnerable) process of finding and messaging a stranger to study with. Some would rather learn from what others have already shared, without the social step of "finding a buddy" at all. That's the actual reason Notes Repo exists as its own feature, not just a bonus — it's a second on-ramp into the same goal for people who wouldn't take the first one.

[ paper prototype vs. Figma prototype comparison goes here ]

04. The Fix // "Designing with receipts"

The through-line: every feature exists to keep peer learning happening inside the app CBIT students already trust, instead of the process fragmenting across WhatsApp for chat, email for notes, and word-of-mouth for finding people in the first place.

Feature 01: Find a Buddy

Backed by finding: students already study in ad hoc clusters — but only when they already know each other. Search and filter by person or group, and view a buddy's courses and availability before requesting, so it's not messaging blind.

Feature 02: Buddy Chats

Backed by finding: coordination was previously scattered across outside apps. A dedicated space to actually coordinate and share materials once a request is accepted keeps it in one place.

Feature 03: Notes Repo

Backed by finding: the QOC analysis showed not everyone wants the social step of finding a buddy. Save notes to a personal dashboard, publish publicly, and explore by subject — a no-social-risk path into peer learning.

[ before/after or key screen walkthroughs go here ]

05. Did It Work? // "The honest scoreboard"

3 Core features designed and traceable to a real finding

2 Prototype fidelities — paper, then Figma

4 Competitor apps analyzed to sharpen the design direction

This one's honest, not padded: the project moved through competitive analysis, paper prototyping, and a full Figma prototype — it wasn't usability-tested with CBIT students or deployed, so there aren't task-completion numbers or before/after metrics to point to yet. What I do have is a design that's traceable back to a real, specific constraint (the 70:1 ratio) and a real existing behavior (students already forming ad hoc study groups), rather than a hypothetical one.

06. Behind the Scenes // "Director's Commentary"

Designing for a specific community changes the brief — this wasn't "design a study app" in the abstract, every decision had to make sense for one real campus with one shared course catalog. The Find-a-Buddy vs. Notes Repo split came directly from realizing "peer learning" isn't one behavior, it's several, with different comfort levels attached. If I did this again, I'd get even 3–5 people to click through the Figma prototype before calling it done — a prototype is a conversation starter, not an answer, and I'd want to see where it actually breaks.