The problem
Students at IU juggle two sprawling platforms. Canvas handles courses and messaging; One.IU hosts 964 (!) features from bill pay to degree audits. Neither is built around the act of studying.
With remote learning forcing students to manage their own time, we asked: what if there were one focused place for studying, planning, and finding help?
Instead of building yet another everything-platform, we made IU Study Assistant deliberately narrow: only features related to studying, time management, and course planning. Designed for IU first (IU login, Rivet design language), architected to be portable to other universities.
Research
To confirm this was a real pain and not just ours, we surveyed forty peers about Canvas and One.IU, then ran interviews, a focus group, direct observation, and usability tests — each team member owned two sessions and a write-up.
What we heard: most students had hit issues with at least one platform, use cases were inconsistent across the student body, and nearly everyone wanted necessary services aggregated in one location. The lack of interface standardization was producing real friction.
Feature list: 12 → 9
Research let us cut. Flashcards and Professor Profiler were dropped; sharing was removed from Survey and Notes to sidestep confidentiality issues; the Messenger sub-feature came out of Tutor Classifieds because of team scheduling constraints. What remained: Login & Register (IU credentials), Profile, Dashboard, Friends List, Survey, Notes, Study Groups, Tutor Classifieds, and Buy & Sell Textbooks.
Design
We adopted the 3-click rule as a design framework — not because usability equals a click count, but as a forcing function to iron out redundancy and keep navigation obvious. Wireframes were built in Figma at web dimensions using Indiana University's color palette so the product felt native alongside other IU services.
Build
I designed the database and built the Notes feature. The schema accepts new data (users, note entries) while staying concrete about existing entities like users and study groups — the ERD doubled as the team's shared mental model of how data moves through the system.
Front-end was HTML, CSS, Bootstrap, and JavaScript; back-end was PHP and SQL, with LucidChart for the ERD and Mockaroo for seed data. Branding (poster, logo, promo GIF) was done in InDesign, Photoshop, and Illustrator.
Outcome & lessons
The system shipped on IU servers with all nine features. The honest version of the story: early sprints were slowed by database setup and syncing files to IU's servers, and later sprints suffered from scheduling miscalculations that pushed styling work into the final sprint — so the Bootstrap grid and a mobile-friendly pass never made it across every feature.
Teamwork accountability. Working fully remote made a flexible meeting structure possible, but when accountability slipped, the team had to confront it directly. Timed stand-ups that focus on the value delivered — not the obstacles — kept us moving.
Self-directed learning. The implementation was an exercise in problem-solving without a safety net, which is exactly what the first year on a real team feels like.