|
| 1 | +--- |
| 2 | +layout: guide |
| 3 | +title: Content guidelines |
| 4 | +nav_order: |
| 5 | +--- |
| 6 | + |
| 7 | +# Content guidelines |
| 8 | + |
| 9 | +Thank your for helping shape the Bitcoin Design Guide. We have many different authors with different ideas and voices. To ensure a coherent and consistent experience for readers, we collected a few tips on writing here. |
| 10 | + |
| 11 | +#### Know your reader |
| 12 | + |
| 13 | +The guide is primarily meant as a tool for people who work on open-source, non-custodial bitcoin projects, with a focus on design. |
| 14 | + |
| 15 | +#### Speak to the reader |
| 16 | + |
| 17 | +Address the reader directly via "you". |
| 18 | + |
| 19 | +#### Use simple language |
| 20 | + |
| 21 | +Bitcoin is meant for a global audience, so you need to assume that many readers are not native English speakers. Many speech writers intentionally write for a 6 to 8th grade proficiency level. This allows a wider audience to understand the content (including non-native speakers), and it forces them to clarify their thinking. You can take advantage of readability tools like [Hemingway](http://www.hemingwayapp.com). They analyze text, provide a readability score, and suggest ways to simplify the writing. |
| 22 | + |
| 23 | +Note that simple language does not mean "dumbing things down". There are also some specific topics that require more complex language. A good guidelines is that the deeper a reader gets into a topic, the more complex the language can be (it does not have to be). |
| 24 | + |
| 25 | +#### Be precise |
| 26 | + |
| 27 | +Focus on the information that will be the most useful to your reader. If a page gets too long, split it up into multiple pages. If you want to allow users to dive deeper into a topic that is not core to the guide, see if there are third-party resources you can link to. |
| 28 | + |
| 29 | +#### Give practical tips, but don't be overly prescriptive |
| 30 | + |
| 31 | +Provide recommendations and best practices but do not force specific solutions on readers. The project the reader is working on may require something slightly or completely different because of unique context. |
| 32 | + |
| 33 | +#### Get the reader involved |
| 34 | + |
| 35 | +You can consider asking questions directly to the user before giving answers. You can also use work-sheets, to-do lists, do's and don'ts or other formats to get readers hands-on. |
| 36 | + |
| 37 | +#### Use the right medium |
| 38 | + |
| 39 | +One picture can say more than one thousand words. Plus, we can use videos, interactive prototypes, diagrams, and more. Take advantage of these different media and their strengths at communicating differen types of information. If you'd like help creating this type of content, ask in the community. |
| 40 | + |
| 41 | +#### Show examples |
| 42 | + |
| 43 | +It is OK to show screenshots of other software as reference points. Make sure to indicate the product and version. Avoid negative examples and focus on showcasing good solutions and explain why they are good. |
| 44 | + |
| 45 | +#### Be humble |
| 46 | + |
| 47 | +The guide is a work in progress and needs to evolve to stay relevant. What we write today may not be applicable tomorrow. |
| 48 | + |
| 49 | +#### Write in the open if you can |
| 50 | + |
| 51 | +It is healthy to get early feedback as it may prevent you from going into a wrong direction for too long. There is a whole community around you to help you create better content that helps more people. |
| 52 | + |
| 53 | + |
| 54 | + |
0 commit comments