Case Study · KappaChapters
Chapter names, campuses, and history were scattered across lists, documents, and login-walled locators. Brothers needed a public place to look a chapter up and share what they found.
I built KappaChapters.com as an independent, centralized directory of Kappa Alpha Psi undergraduate and alumni chapters.
The original impulse could have been a chapter-operations product: membership, events, communications. That would have been the wrong problem. The actual need was simpler and more frequent. Someone hears a chapter name, needs a campus and charter year, or wants the additional history that usually lives in someone’s head. They should be able to find it without hunting.
Official locators, Wikipedia lists, province documents, and social pages each hold a piece. None of them is a clean public search you can send as a link.
I started with the lookup. The product had to answer immediately: which chapter, where, and what should I know about it?
That constraint kept the work a directory. Undergraduate and alumni records sit in one place, searchable by name, campus, or location. A chapter card carries the charter year, province, university, location, additional history, and public links when they exist. A URL can be shared so the search arrives already filled.
Design, data, and development stayed in the same thread: what belongs on a card, how search should feel, and how little someone should have to do in order to find a chapter.
KappaChapters.com is a working public directory. It is useful because it stays a directory—not a chapter-operations platform. The product respects the moment of need: look it up, read it, share it.
This is the kind of problem an Idea-to-Prototype Sprint is designed to clarify before a larger build.