Persona: Morgan — the room author

Secondary persona. Morgan is a developer who wants to build a specialized listening experience on the Rymflux platform.

Persona: Morgan — the room author

Secondary persona for v1 (room framework API). Becomes primary in v2 when additional rooms are built.

Demographics

Goals

1. Build a new room for a niche audio type (e.g., language lessons) in a weekend.
2. Define the navigation, search, and player behavior specific to that content type.
3. Reuse core services (playback, library, queue) without reinventing them.
4. Publish the room so users can install and use it alongside existing rooms.

Pain points

1. Framework rigidity: Some platforms make it impossible to customize the player or navigation. Morgan wants control over the experience.
2. Over-engineered APIs: A room API that requires deep understanding of the entire platform before building a simple room is a barrier.
3. No reference implementation: Without a working example (like the Music Room), Morgan has to guess the patterns.
4. Unclear boundaries: What does the room own vs what does the core own? Surprising behavior when the core overrides a room’s decision.

Behaviours

• Starts by studying the reference room implementation (Music Room).
• Prototypes quickly — wants a visible result after the first hour of coding.
• Prefers convention over configuration: sensible defaults with overrides for behavior that matters.
• Will read API docs but learns best from a complete working example.
• Expects the room API to be stable within a major version. Breaking changes should have a deprecation window and migration guide.

Scenarios

Primary scenario: Language Learning Room

Context: Morgan is building a Language Learning room. Each “track” is a lesson with audio, a transcript, and a slow-down mode.

Goal: A working room prototype in one weekend.

Success criteria:

• Room registers and appears in the shell’s room list.
• Room defines its own search filters: language, level (beginner/intermediate/advanced), instructor.
• Room registers a custom player expansion that shows transcript, slow-down slider, and repeat-phrase button.
• Room uses the core library and queue services without custom code.
• Users can switch between Music Room and Language Learning Room without losing their queue.

Secondary scenario: Diagnosing a room framework issue

Context: Morgan’s room is mostly working but the player expansion doesn’t receive metadata updates when the track changes automatically (next in queue).

Goal: Identify whether the bug is in the room or the framework.

Success criteria:

• Morgan checks the room framework docs for the player expansion lifecycle.
• Morgan adds a log line in the expansion update handler.
• The framework docs explain when expansion views are updated (track change, manual expand).
• The bug is either fixed in the room code or filed against the framework with a clear reproduction.

Quotes

“I don’t want a SDK. I want a contract — here’s what you control, here’s what the core handles, here’s an example room that does both. Let me build from there.”

Validation

Related

• Journey map: Not yet created (v2 priority)
• User stories: Register a room, Customize player for a room
• Other personas: Listener, Plugin developer