# Friction Logging Is the DevRel Equivalent of Code Review Code review catches bugs before they reach users. Friction logging catches experience failures before they cost you developers. Lewko and Parton define it as "the process of actually walking through the developer journey to audit its effectiveness" -- you step into your target developer's shoes and document every stumble, confusion, and dead end. The Docs for Developers team operationalizes this further: a friction log is a journal where you try your software as a user would, recording each step sequentially and noting the gap between expected behavior and actual behavior. The bigger the gap, the bigger the opportunity to improve docs or product. This isn't a survey or a sentiment score -- it's a hands-on audit that produces specific, actionable findings. Out-of-date documentation, broken quickstart guides, confusing error messages, missing code samples -- friction logging surfaces all of these. The practice connects three things that often operate in silos: developer experience measurement, documentation quality, and product feedback. When a DevRel team member hits a wall in the getting-started flow, that's simultaneously a DX problem, a docs problem, and a product insight. Lewko and Parton pair friction logging with two other feedback mechanisms: community feedback (surveys, office hours, support channels) and journey data evaluation (analytics on your developer hub). But friction logging is the one that generates the most actionable output because it produces specific, reproducible observations rather than aggregate sentiment. The discipline is doing it regularly, not once. Products change, docs drift, and new onboarding paths emerge. A friction log from six months ago is stale. The DevRel team that walks the developer journey quarterly -- or better, continuously -- catches regression before developers report it. <!-- atomicity: 1 idea ✓ --> ## Why This Matters Developer experience problems compound silently. A developer who hits three friction points in your onboarding flow doesn't file three bug reports -- they leave. Friction logging is the only practice that systematically catches these experience failures before they become churn. It turns subjective "the DX feels bad" complaints into concrete, prioritized improvement lists. ## Links - [[3. Resources/Permanent Notes/The Maker Should Not Grade Its Own Homework]] — evidence-for: an outside reconstruction of the developer journey catches friction that the builder's familiarity makes invisible - [[3. Resources/Permanent Notes/The Recommend Layer Is Where Vendor Markets Make Their Real Decisions]] — applies-in: logged practitioner friction identifies the trust failures that later appear as lost recommendations - [[3. Resources/Permanent Notes/A System Failure That Looks Like a Performance Failure Never Gets Fixed]] — applies-in; friction logging exposes system causes before degraded outcomes are misread as individual performance failures. - [[3. Resources/Permanent Notes/Time-to-Hello-World Is the Critical Developer Experience Metric]] — friction logs expose the concrete delays that make this activation metric worse - [[3. Resources/Permanent Notes/Education Is the Only Marketing That Works With Developers]] — hands-on friction findings identify what developers need taught rather than what a product team wants promoted - [[3. Resources/Permanent Notes/DevRel as Railroad Infrastructure]] — recurring journey audits are maintenance work on the adoption path DevRel operates - [[3. Resources/Permanent Notes/Repeated Workarounds Are Unfiled Bug Reports]] — configuration workarounds are passive friction logs written by users who never filed an issue - [[3. Resources/Literature Notes/The Developer Advocate's Guide to Addressing Product Friction]] — evidence-for; Apollo's Discover-Build-Report-Follow Up loop is a worked operating model for friction logging. - [[3. Resources/Literature Notes/The DevRel Show Episode 53 — Chris DeMars from TuxCare]] — evidence-for; DeMars's build-break-report ritual independently describes the same internal advocacy practice. - [[3. Resources/MOCs/Documentation & Technical Writing MOC]] — applies-in: the docs discipline map; the active remedy for silent feedback channels - [[3. Resources/Permanent Notes/A Shared Gate Definition Turns Onboarding Complaints Into a Count Product Can Dispute]] — applied in: count the gates between arrival and first success on one real route before arguing onboarding is hard (Save). - [[3. Resources/Permanent Notes/A Tutorial Starts at the Reader's Actual Level, Not the Author's]] — applied in: set a tutorial's start line by what the reader knows (Kretzschmar). - [[3. Resources/Permanent Notes/Developers Who Build Through Agents Often Can't Name the API They Call]] — extended by: start support from what the developer is building, not which API they call (Rabasa). - [[3. Resources/MOCs/DevRel MOC]] — applies-in: the practitioner discipline of walking the developer journey and documenting every stumble. - [[3. Resources/MOCs/Open Source Governance MOC]] — applies-in: the governance map lists the same journey-walking practice for contributor and user onboarding. - [[3. Resources/MOCs/Personal Knowledge Management MOC]] — applies-in: listed there as a cross-reference; the map gives no further reason. ## Source - [[3. Resources/Literature Notes/DevRel at Scale - Operations Measurement and Organizational Design - Literature Note]] - [[3. Resources/Readwise/Books/Developer Relations]] - [[3. Resources/Readwise/Books/Docs for Developers]] - [[3. Resources/Readwise/Books/Developer, Advocate!|Developer, Advocate!]]