Technical writing is a specialized form of writing focused on communicating complex technical information clearly and effectively. This guide provides standards and best practices for creating high-quality technical content across all Bayat projects.
- Use simple, direct language
- Define technical terms when first used
- Break complex ideas into smaller, manageable parts
- Focus on one main idea per paragraph
- Verify all technical information
- Include version numbers where relevant
- Cite sources for external information
- Maintain consistency in terminology
- Identify your audience before writing
- Adjust technical depth based on audience expertise
- Consider cultural and language differences
- Address the audience's goals and needs
- Organize content with a clear hierarchy
- Use descriptive headings and subheadings
- Present information in a logical sequence
- Include navigation aids for longer documents
- Professional but conversational
- Active voice (preferred over passive)
- Second person ("you") for instructions
- Confident but not authoritative
- Tutorials: Encouraging and step-by-step
- Reference materials: Precise and neutral
- Troubleshooting guides: Empathetic and solution-oriented
- API documentation: Concise and technical
- Start with clear prerequisites
- Include a working example
- Break into discrete, achievable steps
- Explain the why behind actions
- End with next steps or further learning
- Focus on specific tasks
- Use numbered steps for sequential procedures
- Include examples for complex steps
- Add troubleshooting tips for common issues
- Explain ideas and abstract concepts
- Use analogies to simplify complex topics
- Include diagrams and visual aids
- Connect concepts to practical applications
- Organize for quick information retrieval
- Use consistent formatting for similar items
- Include all relevant parameters and options
- Link to related concepts and examples
- Categorize changes (new features, improvements, bug fixes)
- Highlight breaking changes prominently
- Include migration instructions when needed
- Use consistent versioning references
- Use short to medium-length sentences (15-25 words)
- Limit paragraphs to 3-5 sentences
- Use transitional phrases between paragraphs
- Vary sentence structure to maintain interest
- Use consistent terminology throughout
- Avoid jargon unless necessary for the audience
- Replace idioms with direct language
- Choose specific over general terms
- Use bulleted lists for unordered items
- Use numbered lists for sequential steps
- Keep list items parallel in structure
- Aim for 3-7 items per list
- Use tables to organize complex information
- Include clear column headers
- Align numerical data appropriately
- Provide a descriptive caption
- Use sentence case for headings
- Apply consistent heading hierarchy
- Use bold for emphasis (sparingly)
- Use italics for defined terms and UI elements
- Use monospace font for code
- Include syntax highlighting where possible
- Clearly distinguish inline code from surrounding text
- Provide complete, runnable examples
- Use descriptive link text (not "click here")
- Indicate external links consistently
- Verify links regularly
- Group related links at the end of sections
- Use high-quality, accessible images
- Include descriptive alt text
- Add captions explaining the image purpose
- Maintain consistent style across diagrams
- Use sufficient color contrast
- Don't rely solely on color to convey information
- Use descriptive headings for screen readers
- Avoid directional references ("below" or "right")
- Provide transcripts for audio content
- Add captions to video content
- Create alt text for all meaningful images
- Make diagrams screenreader-compatible
- Use proper heading hierarchy (H1, H2, H3)
- Create accessible tables with headers
- Use semantic HTML when publishing online
- Test documents with accessibility tools
- Wait at least one hour before self-reviewing
- Read content aloud to catch awkward phrasing
- Check for consistency in terminology and style
- Verify all examples work as described
- Request technical review from subject matter experts
- Seek editorial review for clarity and style
- Include accessibility review in the process
- Document and track feedback systematically
- Test documentation with target audience members
- Observe users following documentation
- Collect structured feedback
- Iterate based on user experience
- Markdown for standard documentation
- Asciidoc for complex technical documentation
- Mermaid or PlantUML for diagrams
- Grammarly or similar for grammar checking
- Project README template
- API documentation template
- Tutorial template
- Troubleshooting guide template
- Store documentation in the same repository as code
- Version documentation alongside software releases
- Tag documentation changes in commits
- Track major documentation revisions
- Review documentation at least quarterly
- Update with each major software release
- Archive obsolete documentation
- Establish ownership for ongoing maintenance
- Use simple sentence structures
- Avoid culturally specific references
- Provide context for translators
- Allow for text expansion in layouts
- Maintain glossaries for consistent terminology
- Provide style guides for translators
- Include translation memory in the workflow
- Test translated documentation with target audiences