A platform for preserving community oral histories

The Problem

Oral histories are still collected much as they always have been. Staff recruit participants, schedule interviews, sit for each recording, and then transcribe and analyze it all by hand. Every step costs staff hours, and libraries in particular are short of staff. The stories a community most wants to keep are the ones there is never enough time to gather.

I set out to move each of those steps off staff time without taking the stories away from the institution or the people who tell them.

The need was sharpest in senior living, assisted living, local libraries, and cultural initiatives. All of them hold stories that cannot be replaced, and none had a realistic way to collect them or a tool built for the institution's side.

Talking to the Stakeholders

We were bootstrapping, so the product was shaped by conversations with the people who would use it. To move from a rough alpha to something real, I interviewed two librarians, a historic-resources lead from Maryland's park and planning commission, and a therapist who works with personal narrative. Their guidance kept steering the build from then on.

Two findings reset the plan. First, they welcomed AI, and they cared deeply about ownership. The collection had to belong to the institution rather than to Oria. Second, and more surprising, these institutions already have trusted channels to their participants.

What ate their time was collecting and analyzing the stories. They did not need help with distribution or recruitment the way a consumer product would, so I cut recruitment from the scope and aimed the product at collection and analysis. That set three requirements I designed against. A campaign had to be quick to create and share, collected stories had to be easy to manage and understand, and telling a story had to feel worth the effort, so that people would share a real one.

The Platform

I structured a collection in three levels. A campaign sets the overall theme, topics sit under it, and each topic has its own questions. To save them from a blank page, the platform drafts questions with the Gemini API from the campaign, the topic, and the direction the organizer enters. I placed the drafts in the same editor where organizers write their own questions, editable at any time, so the AI removes the blank page without taking over the authorship. Each campaign and topic publishes to missionoria.com as a link or QR code, so an institution can send it through the channels it already trusts, and participants can also browse public campaigns to find an institution collecting stories near them.

A participant opens the link and answers in text, audio, video, or photo, on a phone, tablet, or desktop, so a story can be told at the library or at home. I kept every contribution in its original format and had it transcribed on arrival, so the collection can be searched from the first story and nothing of the teller's voice is lost.

Ownership came straight from the interviews, so I designed it in at two levels. The collection belongs to the institution, which can download every story in it. Each teller keeps ownership of their own story and chooses whether it is public, community-only, or private, or submits it anonymously. Choosing public or community-only grants Oria a license to store, display, and share the story for historical, educational, and research purposes.

I also gave organizations the analytics their old process could not produce, including participation, completion, and retention rates and the number of stories collected, so a small team can see what is working without counting by hand.

Designing for Two Users at Once

The hard part was that this is two products sharing one platform. The institution needs control, speed, and clarity, so that creating, deploying, and managing a collection takes as little effort as possible. The participant needs a calm space that makes telling a real story feel worth doing, which is the opposite of an admin tool. The central design challenge was holding both in one system without letting the operational side make the teller's side feel cold.

I turned each need into a specific decision in the screens. A teller joins with an organization lookup or a join code, with no account to create. Each screen asks a single question, with read-aloud and microphone icons beside the prompt, so a question can be heard and answered by voice. An answer can be typed, recorded as audio or video, or uploaded, and a story can go in anonymously. On the institution side, a campaign is one link and one QR code, and every story arrives transcribed and ready to review.

I designed in Figma and built most of the product myself with Claude Code and Codex, on React and AWS after an initial Vercel build. The data engineer structured the database and set up the build and deploy pipelines.

Learnings

Moving fast cost consistency. The project went through many design phases and a shifting set of tools in a few months. The technology let me build quickly, but it also let the work sprawl, and the visual design has not caught up yet. I am still going screen by screen to bring everything back to one design system. That is the cost of building this fast with AI tools. The work can get ahead of its own conventions, and then it has to go back and fix them.