Scribe

Designed an interactive spatial mapping interface that helps product teams spot critical strategic gaps and stress-test roadmaps without getting lost in flat document systems.

Role

Solo Designer & Developer

Engineering Appendix Link

A complete, engineering-focused deep dive into the system architecture and implementation details is available in the collapsible process drawer at the bottom or the Scribe Appendix file.

Visit Live Site3 min read / 45 sec skim
01 / ORIGIN

The Evolution of Scribe: 3 MVP Iterations Before Context

Before landing on rigid hierarchical columns, Scribe underwent three distinct design and product iterations. Each prototype tested a different mental model—from unconstrained AI connection graphs to qualitative storytelling, before focusing on rigid strategic hierarchy for decision-makers.

Iteration 01

MVP 1 — AI Connection Map Generator

Unconstrained Force Graph

The initial concept was simple: input raw notes and let an automated AI engine construct a force-directed graph based on word co-occurrences and semantic links using simple logic.

MVP 1 Light Theme GraphLight Graph View
MVP 1 Dark Theme GraphDark Graph View
User Feedbacks & Initial Reactions
💬 "What do I use it for?"💬 "Wow, you made this?"💬 "Looks cool"💬 "Can I try it?"💬 "How do I read all this?"💬 "What are you using it for?"💬 "Okay... (confusion personifies)"
Conclusion

The map looked visually impressive, but failed to serve a practical purpose. The UI provided no direction, turning navigation into an exhausting game of detective.

New Direction

The tool needed a specific purpose. The UI must drastically reduce cognitive load rather than increase it.

Iteration 02

MVP 2 — Storytelling & Qualitative Journey Maps

Story of the Little Match Girl

Chose storytelling as the core direction—taking complex qualitative data (like stories, user interview transcripts, and narrative arcs) and representing them as interactive cluster journey maps.

Cluster ViewCluster View
Node MapNode Map
Document AnalysisDocument Analysis
Interview CardsInterview Cards
User Feedbacks (Dark Mode Test Batch)
💬 "I am putting in more effort..."💬 "Looks cool"💬 "What are you using it for?"💬 "Can I try it?"
Conclusion

Slightly more useful than MVP 1, but as a tool it still lacked a clear, indispensable purpose. Users felt they were putting in excessive effort decoding visual layouts.

New Direction

Scrap visual gimmicks entirely. Focus on a specific niche problem for users who need to make high-stakes decisions from dense data.

Iteration 03

MVP 3 — Multi-Data Link & Connection Analyzer

Targeting Thinkers & PMs

Pivoted away from creative writers toward thinkers, product managers, and researchers—synthesizing complex data inputs, 50-page research papers, and technical requirements into linked analytical graphs.

Analytical ClustersMulti-Cluster Analysis
Dense Link GraphDense Link Graph
In-Depth User Interview Insights(Targeted Stakeholder Testing)
UX Professor

"This looks useful enough but you still need to find a better use case for it. Write a research paper on this..."

IBM Product Manager

"I will use it if it reduces my effort and saves me time. I don't understand the specific context... I'd rather use normal AI."

Automobile Designer(Tested on 50-page paper)

"I don't want to read all that and either way I don't feel like it helped me."

Conclusion

It was significantly better than previous iterations, but unconstrained graphs still lacked a singular focus to replace traditional AI chat windows in daily workflows.

Final Breakthrough to Scribe

Scrap free-form physics graphs entirely. Constrain D3 to snap nodes into fixed 300px hierarchical columns (Pillars → Clusters → Leaves) tailored specifically for strategic roadmap stress-testing.

02 / CONTEXT

Scribe is a local-first, visual note-taking environment designed to solve this specific problem.

It was built as a solo project, meaning I needed a stack that allowed for rapid prototyping without heavy backend infrastructure (Next.js, Tailwind, D3.js, and local IndexedDB).

Scribe System Overview (MacBook & iPhone Mockups)
03 / THE REAL PROBLEM

I was trying to reconcile a product roadmap across 30 different user interviews, technical constraints, and design requirements. I kept losing track of how a feature in Phase 2 would break a constraint we discovered in Phase 1.

Linear documents (like Notion or Google Docs) hide interdependencies. You can link pages, but you can't *see* the connections. I needed a way to map out complex logic visually without it turning into an unreadable mess.

The Problem
04 / KEY DECISIONS

1. Forcing hierarchical columns over free-form graphs

Most note-taking apps with graphs (like Obsidian) use force-directed layouts. They look cool, but they turn into useless 'hairballs' once you have more than 50 notes.

Rationale

Decision: I constrained the D3 physics engine to snap nodes into fixed 300px columns based on their hierarchy (Pillars -> Clusters -> Leaves). Trade-off: Users lose the ability to place notes anywhere they want on an infinite canvas, but the structure remains legible and organized even with hundreds of nodes.

Forcing hierarchical columns over free-form graphs

2. Client-side storage over cloud databases

Scribe stores all data in the browser using IndexedDB.

Rationale

Trade-off: It prevents easy multi-device syncing out of the box, but it allowed me to bypass complex authentication flows, ship faster, and guarantee 100% privacy for users working with sensitive strategic data.

Client-side storage over cloud databases

3. Bring-Your-Own-Key (BYOK) for AI features

Instead of charging a subscription for AI credits, users paste in their own OpenAI or Claude keys, or connect to a local Ollama instance.

Rationale

Trade-off: It adds friction to the onboarding process, but it keeps the app free to host and ensures user data isn't being silently scraped by a middleman server.

Bring-Your-Own-Key (BYOK) for AI features
Scribe System Iteration Pre-Physics
05 / WHAT DIDN'T WORK

My first attempt at the "Oracle" view used a standard physics simulation where notes repelled each other. When users tried to drag notes to group them, the physics engine fought back, causing the entire map to constantly jiggle and re-adjust. It was incredibly distracting.

I had to rip out the continuous simulation and write a custom collision-detection script that only calculates physics when a node is actively dropped, snapping it to a strict 40px grid.

Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Iteration 6
Iteration 7
Iteration 8
06 / RECONSIDERATIONS & OUTCOME

What I'd Reconsider

01. Progressive Spatial Disclosure in Graph Density (Design)

Presenting complex canvas node graphs all at once can induce cognitive overload during initial research reviews. I would refine the visual onboarding by implementing a progressive zoom-disclosure hierarchy that keeps macro strategy clusters clean at wide viewports and reveals individual leaf cards only as the user zooms into specific decision nodes.

02. Canvas Render Engine Scalability (WebGL vs. SVG) (Technical)

While SVG and D3 render crisply for moderate node counts, panning and zooming heavy graph clusters with over 500 interactive elements can introduce frame rate drops. Migrating the core canvas rendering layer to WebGL/Pixi.js would maintain smooth 60fps interaction during large-scale dataset navigation.

Reflection

Building a tool that challenges how people write forced me to realize that "Ease of Use" shouldn't always be the primary goal. Scribe has a steeper learning curve than a blank text document, but for mapping out complex strategies, that friction forces better thinking.

I am moving to...

Campus Trace

Project documentation and design system complete.

© 2026 Product Design Portfolio

0X