CASE STUDY 3: Backstory

Building an app from scratch. IA, components, permissions, CRUD flows, and a design system. One very hard interaction problem. Here's what turned me into a product designer.

The problem

Writers who want serious tools have two options and neither is quite right. Feature-rich editors like Scrivener are built by writers for writers and wind up with years of accumulated complexity, poor UX, and interfaces that feel more like button and knob machines instead of creative environments. Simple, well-designed editors like Google Docs or Ulysses are a pleasure to use but lack the structural tools a worldbuilding-based writer actually needs.

I wanted something in between. A writing environment as clean and fast as Google Docs, but connected to a live database I could interact with directly from the editor. The kind of tool where I could highlight a character's name in my manuscript and instantly pull up everything I'd ever written about them, without leaving the page.

That tool didn't exist. So I designed it.

My role

Complete end-to-end product design ownership. I identified the problem, interviewed writers throughout the process, defined the information architecture, built a light design system, designed all components, mapped all flows, defined the permission model, and validated the design through testing. No team. No brief. No PM.

The process

Starting with the writers

Before any design work, I talked to 50 writers across novel writing, game writing, and journalism to validate the concept and understand the problem space. Out of the first 10 I spoke with, 8 confirmed the problem and said they'd use a product like Backstory. I kept talking with writers throughout the entire process. The goal was to understand not just what tools they used but what they were trying to do that their current tools made hard. The recurring theme: writers were managing character details, world lore, and plot threads across multiple disconnected documents and draft versions. The context lived in their heads because there was nowhere good to put it.

One early finding changed the product roadmap entirely. Nearly every writer mentioned wanting analytics on their writing habits over time, something like a Spotify Wrapped for writing. It wasn't in the original plan. I designed it into Phase 2 and planned to use it as a social sharing feature, letting writers connect their accounts and share their stats. That kind of research-driven scope change is exactly what the ongoing conversations were for.

That insight shaped the core concept: a word editor with a connected database, where the relationship between writing and reference was live and bidirectional.

Designing the information architecture

The central design challenge was how to represent the database layer without it competing with the writing experience. Many world-building softwares force you into their own database categories. I wanted to keep Backstory's database categories dynamic so any writer could craft it how they wanted. I developed a concept I called "Things," the objects a writer tracks in their world. Characters, places, spells, creatures, plots. Each Thing had sub-Things, and each sub-Thing could belong to Sections.

The hierarchy sounds simple but required careful thinking: how do you let a writer organize their world flexibly without creating an organizational system so complex it becomes its own burden? I validated the IA with writers at each stage, adjusting based on where they got confused.

The hardest design problem: CRUD operations from two places

The most technically and conceptually difficult part of Backstory was designing every Create, Read, Update, and Delete operation across two surfaces, the editor view and the database view, and keeping them consistent in both language and visual representation.

Every action a writer could take on a Thing in the database panel from the editor, they should be able to take in the database itself. This meant the visual contexts, affordances, and consequences were all different. Deleting a Thing from the database view is one flow. Deleting a Thing that's referenced twelve times in your manuscript is a different problem entirely.

I designed a full interaction model covering every state: selected, hidden, locked, hidden and locked, right-clicked, copied, moved. I built a Move modal with search and hierarchical navigation. I designed a "hold to delete" confirmation pattern specifically to slow down destructive actions, a deliberate friction that protected writers from accidental data loss.

The permission model

Backstory was designed for collaborative writing for co-authors, editors, reviewers, and beta readers. I designed a full four-tier permission system (Owner, Editor, Reviewer, Viewer) with 11 granular permissions per role including Create, Delete, Edit, Copy, Move, Lock, Hide/Show, Mention, and Comment.

This wasn't a nice-to-have. Writers sharing manuscripts have real needs around what collaborators can and can't touch. Designing this forced me to think about the product not just as a solo tool but as a collaborative platform.

Why it was never launched

Backstory was about 90% designed when AI changed everything. The way writers interact with databases, reference material, and contextual information is fundamentally different in a world where language models exist. The product I'd designed wasn't wrong, but it would have needed a complete rethink of the core interaction model to reflect what AI now makes possible. I paused it rather than ship something that was already being overtaken.

Validation

• 50 writers interviewed across novel writing, game writing, and journalism

• 8 out of 10 confirmed the problem and said they would use Backstory in initial concept validation

• Research directly changed the product roadmap, adding a Phase 2 analytics feature based on near-universal demand for writing habit tracking

What this project showed me

At the time I was a lead content designer. Building Backstory proved I was more. Not because it was perfect, far from it, but because I owned every part of it. The problem definition, the research, the architecture, the components, the edge cases, the permission model.

What I'd do differently

I'd invest more in the component system before touching screens. Because I was designing across two surfaces, the editor and the database view, components needed to flex across very different contexts. I underestimated how much that would compound. Every screen became a manual resizing exercise instead of a responsive assembly of flexible parts. I'd define the component architecture and its responsive rules first, then build screens from it. The Figma work would have been faster and the design more consistent.

I'd also design for AI from day one now. The feature that would have made Backstory genuinely powerful, natural language querying of your world database from inside the editor, wasn't something I fully imagined until AI made it obvious. If I built it today, that would be the core feature, completely changing all the foundational interactions.

Suggested visuals:

1. The editor in its default state

2. The Move modal showing the CRUD interaction complexity

3. The permissions matrix

4. A context menu showing the full action set on a Thing

5. The "hold to delete" interaction states