Becoming —
Turning Reading into Action

Becoming started as a conversation with a developer friend who had a clear product idea and needed a design partner. He had the technical vision and the business — I came in as designer and product strategist.

Clean split: he handled backend and CEO decisions, I handled design and product strategy. A two-person team making real decisions with limited resources and a lot still to validate.

Most serious readers already have a system for capturing ideas. They highlight in Kindle, sync to Readwise, track books in Goodreads. The problem isn't that they don't save what resonates — it's that those highlights just sit there, accumulating, rarely revisited and almost never acted on.

The gap isn't between reading and remembering. It's between reading and becoming.

The tools that exist today are built for storage, not integration. They help you keep ideas. They don't help you live them.

Before any wireframe existed, there was a fundamental disagreement about what the product should do.

My co-founder had a clear vision: the AI reads your highlights and returns actionables directly. You highlighted ideas about deep work, you get a concrete practice to do today. Clean, direct, high-value.

I pushed back.

Not because the vision was wrong — it was actually compelling. But because it was limiting. Forcing users into actionables from day one assumes a level of intent and readiness that not every reader has when they first arrive. It also cuts off users who want to explore, reflect, and discover patterns in their reading before committing to specific practices.

My proposal: design a spectrum, not a single output. Start with themes and recommendations — lighter, more exploratory — and let users progress toward actionables as they build the habit.

The resolution was pragmatic: anchor the product in the core of Readwise — highlight, revisit, integrate — and layer actionables on top of that foundation. This way we'd cover users who already have the habit (Readwise users) without alienating those who are still building it.

This is still to be validated. The approach is deliberately Lean: design, build, ship, and learn from real users before committing to a definitive direction. The question isn't whether the concept is good — it's whether it generates the behavior change it promises.

Step 1 — Connect your sources.

The home screen is built around one thing: today's insight.

Each insight has three components: the practice or reflection (generated by AI based on the active theme), the highlight it came from (the user's own words, attributed to the book), and a clear action — Mark as done or Dismiss. Week and day context is always visible so users know where they are in the 4-week theme cycle.

Below the daily insight: the Daily Review (a 5-minute session revisiting recent highlights) and Suggestions (related articles and reflections). The streak indicator is present but never dominant — it supports the habit without making the product feel like a fitness app.

The Timeline gives users a weekly view of their insights, organized by theme. It's the product's memory — proof that the habit is building, and a way to revisit insights that landed.

The Library is the user's full highlight collection — filterable by books, saved from browser, or Notion. Every highlight that feeds the AI is visible and searchable. This transparency was deliberate: users should always be able to see where their insights come from.

We ran initial tests with a small group of users to validate the flow and catch friction. The results were useful — but came with an important caveat.

The users we tested weren't the right users. They read, but they didn't have a clear intention of applying what they read to their lives. For a product built around integration, that distinction matters. The ideal test user is someone already using Readwise — a person who has already demonstrated that they care about doing something with their highlights, not just collecting them.

That said, the feedback was directionally useful. The theme-based approach resonated — users understood and appreciated exploring an area of their reading rather than being assigned tasks. Several users clicked in unexpected places or didn't immediately recognize that the highlighted content was coming from their own library — a limitation of the prototype, not the concept, since we were using placeholder data instead of their real highlights.

The most important learning: the product needs to be tested with real data. The next phase is a functional prototype — not just a design prototype — connected to real user libraries, generating real AI insights. Only then will we understand whether the core loop actually creates the behavior change the product is designed for.

The current focus is the MVP experiment: a functional version of the onboarding and daily experience, connected to real data, tested with users who have demonstrated intent — active Readwise users and Kindle highlighters who already believe in the value of their reading but haven't found a way to act on it.

The key question the experiment is designed to answer: does receiving a daily insight grounded in your own highlights actually change how you engage with what you read?

Questioning the vision early is the most valuable thing a designer can do. The original concept — AI returns actionables directly — was good. The expanded concept — a spectrum from exploration to action, anchored in the Readwise core — is better. That shift happened because I didn't just execute the brief.

Themes are a better design pattern than goals for habit-forming products. Goals imply failure. Themes imply curiosity. When the stakes feel lower, users engage more honestly.

Test with the right users or don't draw conclusions. Early testing with users who don't share the intent your product is designed for gives you UX feedback but not product validation. Those are two different things, and conflating them leads to wrong decisions.

The AI's output is only as trustworthy as its transparency. Every insight in Becoming is grounded in a real highlight, attributed to a real book. That's not just a design detail — it's what makes users trust the AI enough to act on what it tells them.

Lean doesn't mean skipping validation — it means validating faster. Shipping early with the intention of learning is only valuable if you're honest about what you don't yet know. We have a strong hypothesis. We don't have proof yet.