Lore: a study app for students who listen at 1.4x

Lore came to us with an idea and not much else: students should be able to learn by listening. The company wanted to change how people study, using audio and analytics, and it needed everything built from scratch. The brand, the product design, a prototype and the app itself, live on the App Store and Google Play.

I was the project manager. We had six months and a team of eight: two product designers, a brand designer, three full-stack developers, a QA engineer and me.

From first sketches to both app stores

6 months

Smaller audio files after re-encoding

5x

Faster first playback, at best

45%

A brief that pulled three ways

Universities had to take Lore seriously, so it needed an academic feel. Students had to want to open it, so it needed some of the pull of a fitness app, including a coaching feature that encouraged progress. And because the readings came from licensed publishers at top universities, it had to protect copyrighted material and keep student data private.

Formal education, fitness and well-being don't share a visual language. Our designers didn't solve that on paper. They found the balance by iterating, and the brand we landed on feels like a healthy habit that still belongs in a university.

Prototype early, then reuse it

We built a fully interactive prototype very early and put it in front of students for quick feedback. It paid off twice, because the same prototype became part of Lore's pitch deck.

That second use mattered. Lore was going to be pitched to university stakeholders, professors and experts, and a product you can tap through tells that audience more than a slide can.

A pilot before the pitch

Before the pitch, we ran a small pilot: at least one course and a few dozen students. We wanted to know if the product worked, and we wanted data to back the pitch.

So we defined the metrics with universities in mind: reading completion rates, engagement over time, the settings and places where students listened, and anonymous like and dislike feedback on each reading. Lore could share those insights with universities and faculty without exposing any individual student.

What students actually did

The pilot answered questions we hadn't thought to ask.

Most students played their readings at 1.3x or 1.4x speed, and some pushed it to 2x. They were short on time, which was the premise of the product, and they used playback speed as a study tool.

They also listened with the app minimized. Most of Lore's use happened while students commuted, did chores or worked out. For long stretches, the product had no screen at all.

For long stretches, the product had no screen at all. The audio was the interface.

Native where it counts

We knew from day one that the API, the integrations and the interface had to make Lore feel like a native app, and that we had to deliver it fast. React Native gave us both.

Audio is where feeling native gets hard. Our QA engineer had to plan test cases for lock-screen playback, operating system events, Bluetooth, casting, playback speed and the app running in the background. Most of those never show up in a typical app's test plan.

We also worked on the files themselves. Re-encoding the audio with the Fraunhofer FDK AAC codec made files five times smaller and the first playback up to 45% faster. For a student opening a reading on a train, that's the difference between listening and waiting.

Keeping six months predictable

Six months is short for a brand, a product and a launch. A few decisions kept the date safe:

• AWS and GitLab gave us fast deployments, and Bitrise automated the app builds.
• Separate internal, alpha and beta channels let us test different versions of the app at once.
• Strapi held the content, so readings, courses and universities could be added without a developer.
• Every version shipped with a detailed changelog. Hernán Valdez, one of our developers, pushed for it to keep momentum and clarity on each delivery. It also made my job easier when I wrote release notes for beta testers.

On the planning side, we split responsibilities clearly, organized the work around milestones and kept a mitigation plan with a critical path analysis. That last one is unglamorous, and it's what lets you say yes to a client's change without moving the launch.

What I'd tell a founder building for students

Design for the setting as much as for the screen. Our best insights came from where and how people listened, not from what they tapped.

Put a working prototype in front of users before the design is finished. It's the cheapest research you will do, and it can double as your pitch.

And decide what you'll measure before the pilot starts. We picked the metrics universities cared about, which is why Lore's pilot data could carry its pitch. The full project is in our Lore case study.