# Docs for Developers ## Source Information - Author: [[Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, and Heidi Waterhouse]] - Full Title: Docs for Developers - Category: #source/books ## Highlights synced on 2024-01-10 > In the late 1980s, a group of economists at Harvard determined that humans assume others have the same knowledge they do. They named this cognitive bias the “curse of knowledge.” ([Location 579](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=579)) > Breaking the curse, and writing effective documentation, requires empathy for your users. ([Location 589](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=589)) > You don’t just want your users to know something about your software; you want them to complete a set of tasks or change their behavior in some way. There is an engineering goal (for them) and a business goal (for you) that you want your users to reach. ([Location 604](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=604)) > Note Not every user is the same, and you can’t meet every user’s needs. Prioritize the users who are most important for your product or business. ([Location 622](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=622)) > Once you have a definition of your users, their goals, and their needs, you should validate and build on your initial understanding. User research helps you confirm who your users are and what they need from your documentation. ([Location 642](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=642)) > Note The focus here is on your users’ needs, which are different from user wants. ([Location 647](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=647)) ## Highlights synced on 2024-01-11 > The easiest way to connect with your users is to find the places where communication channels already exist. ([Location 652](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=652)) > it’s important to note that good research can be time consuming. ([Location 676](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=676)) > As you develop your own user personas, consider the needs of your users. Who do you need to help most? Who would face the biggest learning curve to use your software? Who is most important for the adoption of your product? ([Location 744](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=744)) > A friction log is a journal in which you try your software as a user would and record your experiences. To record your experience, log each step sequentially, noting the behavior you expect and the actual behavior of your software. The bigger the gap between expectation and reality, the bigger the opportunity to improve your docs or software. ([Location 781](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=781)) ## Highlights synced on 2024-01-11 > Good documentation describes use cases that help your users meet their goals. ([Location 865](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=865)) ## Highlights synced on 2024-01-12 > A procedural document shows readers how to accomplish a specific goal by following a set of structured steps. A single step should describe a single action that a user takes. ([Location 938](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=938)) > Links in the middle of your document may distract readers. Instead, provide links to additional resources at the bottom of the page. ([Location 982](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=982)) > A documentation plan functions as a flexible outline, making it easy to map out a user journey through the content you write. ([Location 1054](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=1054)) > If your documentation plan reflects a coherent journey for your users, you’re probably in good shape. If your plan feels like a maze or it’s unclear what a user needs to do to accomplish a task or solve their problem, then go back and reshape the documentation plan. ([Location 1085](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=1085)) > Think of an outline as the pseudocode of a document: it lets you discuss your content with other developers and potential users before you’ve sunk too much time into writing. ([Location 1183](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=1183)) > Getting stuck is part of the writing process, whether it’s floundering in the initial steps of creating your outline or somewhere in the middle of completing your draft. ([Location 1312](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=1312)) > Separating writing from editing lets you separate the process of creation from the process of evaluation, reviewing what you wrote with a critical eye outside of trying to get it down in the first place. ([Location 1416](https://readwise.io/to_kindle?action=open&asin=B09HLZGWKT&location=1416))