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 have years of accumulated complexity and interfaces that feel more like button and knob machines than creative environments. Simple, well-designed editors like Google Docs or Ulysses are simple to use, but lack the structural tools a world-building writer actually needs.
I wanted something in between. A writing environment as clean 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 and instantly pull up everything I'd ever written about them, without leaving the page.
When I talked to writers, the problem was consistent. One novelist I interviewed put it plainly: "I keep three different Google Docs open while I write because nothing connects. My character notes, my world notes, and my actual manuscript are all in different places and I'm constantly switching." 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
Before any design work I talked to 50 writers across novel writing, game writing, and journalism to validate the concept. Out of the first 10, 8 confirmed the problem and said they'd use Backstory. I kept talking with writers throughout the entire process.
One early finding changed the 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. That kind of research-driven scope change is exactly what the ongoing conversations were for.
The central design challenge was how to represent the database layer without it competing with the writing experience. Many world-building tools force you into their own categories. I wanted Backstory's database to be dynamic so any writer could shape it how they wanted. Originally, I developed a concept I called "Things", where the writer documents their world. Characters, places, spells, creatures, plots. Each Thing had sub-Things, and each sub-Thing could have more sub-Things.
The hierarchy sounded simple, but required careful iteration. Writers didn’t really track the concept of “things”, and once I explained it, many said, “oh, like a page?” So I changed the concept to “pages” and “sub pages” and the confusion disappeared.
The most conceptually difficult part of Backstory was designing every CRUD 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 page in the database, they should be able to take from inside the editor. But the contexts, affordances, and consequences were all different. Deleting a page from the database view was one flow. Deleting a page connected to several other pages, and with its own sub-pages, 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.
Because Backstory was designed for collaborative writing. 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. 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. I paused it rather than ship something already out-of-date.
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 of designing Backstory, I was a lead content designer. Building it 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, 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.
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, and someday I might just do it, that would be the core feature, completely changing all the foundational interactions.