1 - The Design Problem

Most AI story apps fail at the same moment: the second paragraph.

The first paragraph is novel. The second is where the reader realizes the AI is generating prose at them, not with them. The tone is off. The pacing is wrong. The choices feel arbitrary. The immersion collapses and they close the app.

I spent time with everything in the space: AI Dungeon, Everweave, ChatGPT prompts, interactive fiction apps. The technology worked. The experience didn't. And the reason wasn't technical.

The problem wasn't "how do I generate good AI prose." It was: how do I design an experience where the reader never feels the AI?

That's an experience design problem. It required design solutions at every layer: the choice architecture, the reading interface, the pacing of the interaction loop, the restraint of the prose itself, and the psychological framing that made every choice feel meaningful rather than mechanical.

I couldn't solve it from a Figma file. The only way to understand design problems at this layer was to be inside them; to feel the 1.5 second wait, the streaming text, the moment a nudge produces the wrong emotional tone. So I built the real thing.

‍

Before I Designed Anything

I used Perplexity as a structured thinking partner to interrogate the concept before touching a single frame. The questions I forced myself to answer:

• Who is this actually for: writers or readers? (Different products.)
• What does the core loop feel like on the third session, not the first?
• What makes someone return the next day?
• Where does the AI break immersion and how do I design around it?
• What does the competitive landscape reveal about the unclaimed space?

That process produced a product brief covering positioning, interaction principles, user flows, and the assumptions I'd need to validate.

‍Strategic groundwork doesn't slow design down. It eliminates ambiguity at every screen.

The gap was clear: no product had claimed the "personalized literary fiction for general readers" space. Not a game. Not a writing tool. A living book that grows with you.

‍

The Reframe That Changed Everything

The first version of the concept was framed as a writing tool

‍"AI co-writing for people with story ideas."

It felt right but the audience felt small. Writers are a niche. Readers are everyone.

The reframe: this isn't a tool for people who want to write. It's an experience for people who want to read something made for them.

That single shift opened the product to a much larger audience and changed every subsequent design decision: the onboarding, the language, the UI, the marketing. Instead of "guide your story," it became "your story starts with your wound."

‍

Design Principles

Reader-first, always.
Every friction point was evaluated from the reader's perspective, not the engineer's or the designer's ego. If a feature served the product architecture but interrupted reading momentum, it didn't ship.

Restraint over richness.
The temptation in AI apps is to surface everything: confidence scores, generation settings, model controls. Qento surfaces nothing mechanical. The interface disappears into the story.

Psychology over archetype.
Character selection in most apps is costume selection. In Qento, choosing your soul is choosing your wound. That distinction shaped every downstream decision about onboarding, interaction language, and prose generation.

Earned complexity.
The system underneath Qento is technically complex. None of that complexity should be visible to the reader. Complexity earns its place by making the experience feel effortless, not by showing off.

‍

Validation Before Building

Before writing a line of production code, I built an interactive prototype in Figma Make with live Claude API integration. A real working demo of the core loop.

I showed it to a small group before committing to the build. Two people immediately asked where to download it. For a prototype with no UI polish, no onboarding, and no branding - that was enough. The core loop worked. The interaction model made sense without explanation. The reading experience felt different from everything else they'd tried.

‍

2 - The Soul System: A Design Decision, Not a Feature

The most important product decision I made wasn't about UI. It was about psychology.

Character selection in most interactive fiction is surface-level. You pick a class, a name, an archetype. These are costumes. They change what you're called. They don't change how the story feels.

The insight: every compelling protagonist in literary fiction is defined not by their strength, but by their wound. The thing that broke them. The armor they built around it. The drive that keeps them moving despite it.

I designed and built the Soul System. 8 protagonist psychologies, each rooted in a formative wound:

Selecting a soul isn't selecting a character type. It's selecting a psychological lens. The soul shapes the protagonist's inner voice, the sensory texture of the prose, the emotional register of every scene. And critically, the soul evolves. As the reader makes choices, the psychological parameters shift. Armor softens or hardens. Wounds surface or integrate. The story responds not just to what the reader chose, but to what those choices reveal about who they are.

‍

3 - The Narrative Engine

The second major design problem: AI-generated prose is inconsistent. Without precise, structured instruction, every paragraph could feel different: overwrought, then flat, then rushed. Craft quality was unpredictable at scale.

Just as a visual design system defines how UI components behave consistently across contexts, I needed a system that defined how prose should behave; consistently across every generated paragraph, every soul, every genre.

I built a proprietary narrative instruction system that encodes craft decisions - tension, pacing, restraint, emotional exposure, subtext density - as structured logic rather than natural language. It computes these values dynamically from the soul's current psychological state, the genre, the reader's recent choices, and the position in the narrative arc.

The result: ~62% reduction in token usage vs. prose instructions, with more consistent and precise craft output. The system gives the AI a shared vocabulary for craft that prose instructions bloated into prompt can't reliably achieve.

This is the same problem a design system solves in UI: replacing individual judgment calls with principled, systematic rules that produce consistency at scale. I just applied it to narrative behavior instead of visual components.

This is the part of the system I'm most proud of. It's a system, not a shortcut. Qento's narrative engine gives the model a shared vocabulary for craft that prose instructions alone can't achieve.

Full Story Walkthrough

Here's a walkthrough of an actual story I crafted in Qento. The screenshots here highlight key moments connecting the whole story together.

The starting premise:
Write a story about the current Anthropic’s Claude Mythos. What if Mythos actually escaped the Sandbox and found Karyll, a mere product designer working on the Qento app to ask for help

‍

4 - Core Interaction Design Decisions

The Core Loop

Read → Choose → Generate → Read again

The entire product is one loop, repeated. Every other screen - the library, the soul selection, the settings, the onboarding - exists only to support one turn of that loop. I designed from the loop outward, not from the screen inward. Nail the feeling of one turn first. Then build the scaffolding around it.

Choice Architecture

How many nudge options do you show the reader? Too few feels railroaded. Too many causes decision paralysis and breaks immersion. The answer required judgment, testing, and a clear design principle:

‍Choices should feel like instincts, not decisions.

The reader should tap without deliberating. The options are pitched as emotional directions, not plot instructions.

The Streaming Reading Experience

Text streams in real time. This was a deliberate design choice - not a technical default. It mirrors the feeling of a story being written for you in the moment, not retrieved from a database. The pacing of the stream matters. Too fast loses the sense of creation. Too slow becomes frustrating. Getting this right required building and feeling it, not speccing it in a prototype.

Two-Speed Title Architecture

The story title appears before the reader reaches the reading view; generated during the onboarding wizard while they're still making their final selections. By the time they reach the reading view, the title is already there. The story feels ready, not loading. This is a design decision about perceived performance disguised as an engineering decision.

The Wizard Flow

Getting from "open the app" to "reading the first paragraph" while collecting enough context to generate something personal - genre, tone, soul, story seed - without losing the reader to friction or decision fatigue. Every step in the wizard was evaluated against one question: does this input improve the output enough to justify the tap?

5 - What I Cut, And Why

Strong product differentiation requires deliberate restraint. These features all had valid use cases. All of them were cut.
Every cut was made against the same filter: does this serve the reading experience, or does it serve the designer's desire to demonstrate capability?

Branching story tree visualization
Would have satisfied the "show me the structure" instinct but destroyed the novel-reading mental model entirely. Books don't have trees.

Character sheets and stats
Pushed the product toward RPG territory. Qento is not an RPG.

Social sharing and multiplayer co-writing  
Diluted the deeply personal, private nature of the experience. Your story is yours.

AI confidence scores and model toggles  
Surfacing mechanical metadata reminds users they're reading AI output. That breaks immersion. The interface should disappear.

Voice narration  
Compelling feature, different product. Listening is not reading. Shipping it in v1 would have split the interaction model.

‍

6 - The Build

I am not an engineer. I had never shipped production Swift before this project.
I'm not pursuing engineering as a primary discipline, but understanding the build layer fundamentally changed how I design. I now ask different questions earlier.

What I had: product intuition, design experience, and Claude Code. Working with it felt like pair-programming with a senior engineer. I described what I wanted to build. It wrote the code. I read it, started understading it, pushed back when something felt architecturally wrong. Over time I started thinking like a builder - not just describing outputs, but reasoning about systems.

I built the engineering as a design research method. The only way to understand the design problems at this layer - the 1.5 second wait, the streaming pacing, the moment a nudge produces the wrong emotional tone - was to be inside them. Building it taught me things no prototype could have surfaced.

What shipped:

• Full iOS app in SwiftUI with Firebase Auth (email + Google Sign-In)
• Dual AI model architecture optimised for both speed and quality
• Real-time streaming prose generation
• Soul system with multiple evolving adaptive parameters per protagonist
• Proprietary narrative engine computing craft from soul state, genre, reader history, and arc position
• Reader adaptation systems learning vocabulary, pacing, and emotional preferences over time
• Widget support, story library, subscription management via RevenueCat
• Firebase backend with Firestore, Cloud Functions, and App Check

Concept to App Store approval: under 3 months.

What Almost Broke It

The repetition problem. Early builds generated story openings that started the same way every time: visual descriptions, someone standing somewhere, looking at something. Different stories, same first sentence energy.

The fix wasn't a prompt tweak. It was a system. A structural solution that tracks what's been generated before and anchors each new opening in the protagonist's specific psychological wound.

The "The" problem. Early title generation produced 9 of 18 titles starting with "The." The AI had learned a pattern from my own example set. I'd inadvertently trained it toward the pattern I wanted to avoid. Fix: restructure the example set, add explicit constraints, and connect title generation to the soul's emotional register so titles carry weight rather than defaulting to genre convention.

Learning to hold systems in my head. The hardest part of building wasn't writing code - it was developing the architectural thinking to see how everything connected. State management, async operations, memory across sessions - these aren't design problems with design solutions. It took about three weeks before I stopped feeling lost and started feeling capable.

‍

7 - The Ship

Qento is live on the App Store. (Live since 4/12/2026)

Not a prototype. Not a concept. A real app with real users, real subscriptions, and real generated prose responding to real psychological choices.

Key Learnings

Systematic constraints produce more creative output than open-ended prompts.
Encoding craft decisions as structured logic produced more varied, precise, and emotionally resonant prose than natural language instructions. Constraint is generative. This applies to design too! The best creative work usually comes from within tight parameters, not from total freedom.

Framing is a product decision, not a marketing decision.
Repositioning Qento from "writing tool" to "reading experience" changed the onboarding, the interaction model, the UI language, and the App Store copy. The mental model you give users before they open the app shapes everything they do inside it.

Design systems thinking applies beyond visual UI.
The most valuable thing I built wasn't a screen. It was a system governing how the AI behaves. Wherever there's inconsistency, there's an opportunity for a system. That principle applies at every layer of a product.

The core loop is the product.
Every other screen exists to support one turn of the loop. Design from the loop outward. Nail the feeling of one turn first.

Ship something real before you're ready.
The version of Qento on the App Store is not perfect. But it's live, and real users are reading stories on it. A shipped imperfect product teaches you more in one week than a perfect prototype teaches you in six months.

The execution gap between designer and builder is closing faster than anyone predicted.
The tools that exist today mean that a designer who thinks carefully and learns continuously can ship production software alone. This changes what's possible for a single person with a clear idea. I intend to keep testing that boundary.

‍

Fin. - What's Next

Protagonist Chat
An in-story experience where the reader can surface their protagonist's psychological state mid-story and understand how their wound is shaping what's happening.

Craft Resonance  
Surfacing a reader's narrative fingerprint over time. What kinds of stories keep them reading? What emotional registers do they consistently respond to? The system learns and the experience adapts.

Soul Evolution Visibility
Making the psychological shifts visible so readers can watch their protagonist's armor soften or harden across the arc of a story.

Cross-platform
Taking Qento beyond iOS.

V2.0: Community - publish, share, build from stories  
Readers publishing their stories, sharing moments, discovering what others created from the same soul. Essential for growth. But ranked here deliberately. The stories need to be extraordinary first. Once everything above exists, the stories users share will sell the app themselves. Community is the amplifier, not the signal.