Product Discovery · 2026
Living Fieldbook
A mobile-first product discovery prototype that keeps observations, interpretations, and assumptions connected so teams can explain why their judgment changed.
Visit Living Fieldbook
Product notes often hide the reasoning that matters
A research repository can contain hundreds of notes and still leave a team unable to answer a simple question: why did our product judgment change?
The problem is not capture alone. Raw observations are often mixed with interpretation. Interpretations become conclusions. Conclusions reach a roadmap without a visible link to the assumption they strengthened, weakened, or complicated.
I built Living Fieldbook as a product discovery prototype for preserving that chain.
Its promise is deliberately small: build better product judgment by gathering one piece of real evidence at a time.
The core loop
Living Fieldbook turns a signal into a five-part trace:
1. Source: Record where the signal came from.
2. Observation: State what happened without explaining it.
3. Interpretation: Write what the observation might mean.
4. Assumption: Name the belief the signal affects.
5. Connection: Mark whether the evidence strengthens, weakens, or complicates that belief.
The sequence matters. It makes the gap between seeing and concluding visible. A teammate can disagree with the interpretation without erasing the observation. A new signal can change the affected assumption without rewriting the history.
The prototype guides the user through that loop as a short mission. A fieldbook preserves completed signals. A living habitat responds as evidence connects, turning the history of product learning into something the user can revisit.
Designing for judgment instead of certainty
Evidence rarely behaves like a score. One interview does not prove a market. One usability failure does not invalidate an entire concept. Contradictory signals are often useful because they expose a segment, context, or condition the original assumption ignored.
That is why Living Fieldbook does not award points for reaching certainty. Its connection choices are directional:
• Strengthens it when the signal supports an assumption.
• Weakens it when the signal challenges an assumption.
• Complicates it when the signal adds an important condition or contradiction.
Progress comes from making the reasoning more inspectable, not from forcing every signal into a positive result.
A fieldbook, not another dashboard
The visual language supports the same product principle. The experience is framed as a mineral observatory with translucent field tools, living nodes, and a habitat that changes as evidence accumulates.
This was not an attempt to make research feel like a game. It was an attempt to make a careful practice feel worth returning to.
The dark mineral glass keeps the interface grounded. Amber marks the active decision. Cyan light shows evidence moving through the habitat. Serif display type gives the product a reflective field-journal quality, while the interface copy and controls remain compact and direct.
The fieldbook uses progressive disclosure. A collapsed entry keeps the source, date, observation, and connection visible. Expanding it reveals the interpretation and affected assumption. That keeps scanning fast without hiding the reasoning a future decision may depend on.
Building and auditing the prototype
Living Fieldbook is a frontend prototype built with React, TypeScript, Vite, Phosphor icons, and custom CSS.
The build focused on one complete vertical slice rather than a broad feature set. The mission can be completed end to end. The observation source selector, text entry, interpretation, assumption connection, completion state, fieldbook disclosure, habitat response, and bottom navigation all work in the deployed experience.
The responsive audit covered the full flow at 390 by 844 and the constrained 320 by 568 viewport. That pass corrected crowded controls, dropdown anatomy, accordion placement, bottom navigation overlap, glass depth, scrolling behavior, and small-screen content density. Typecheck, lint, and the production build pass with no warnings.
The current version intentionally has no account system, collaboration, or backend evidence store. It is a focused prototype for testing whether the interaction model makes product reasoning easier to understand.
The product boundary
A real evidence system would need stronger privacy and governance than this prototype.
Research notes can include personal or confidential information. A production version would need informed consent, role-based access, retention controls, redaction, deletion, and an explicit boundary between evidence gathered for a decision and data reused for another purpose.
It would also need to preserve uncertainty. The product should never turn a single observation into a confident recommendation or present an interpretation as if it were a participant quote.
What I would measure next
The next stage is not adding more screens. It is testing whether the loop improves judgment.
I would compare Living Fieldbook with an unstructured research-notes workflow and measure:
• time from capture to a complete evidence trace
• the percentage of decision changes linked to a source and assumption
• correction rates when another teammate reviews the observation and interpretation
• how quickly a teammate can explain why an assumption changed
• the number of reversals made without new evidence
• whether contradictory evidence leads to a clearer next research question
The thesis is falsifiable. If a simpler note template produces equally traceable decisions with less effort, the product should become simpler.
Living Fieldbook is a small experiment in a larger idea: evidence becomes valuable when a team can see what happened, what it might mean, and which belief changed because of it.


