Tone in Documentation
summary
Argues that tone must state a concrete policy — who is expected to use the docs, what actions are allowed, and how much support will be offered — and shows concrete examples: Buffer keeps a personal one-to-one support promise, Ember uses casual guides for new users, Wikipedia separates quick answers from deeper reference, CoffeeScript and Raspberry Pi show when tone scares novices, Yelp kills the brand voice for developer docs, Facebook waters brand down, and sentiment analysis plus analytics and tools like sendable are used to measure effects.
AI-written summary · about
chapters (10)
- 0:00Tone in documentation
- 1:32Technical writing and feelings
- 2:59Brand voice in docs
- 4:45Audience expectations through tone
- 7:35User interaction expectations
- 10:44Support and community tone
- 12:54Branded tone examples
- 17:11When to abandon branded tone
- 20:33Key tone questions
- 21:20Q&A
related talks
29mHumanizing Your Documentation
23mWhat They Don't Tell You About Creating New Style Guides
40mDocumentation as User Experience
43mDocumentation is UX! - Change my mind
46mDocumentation as Marketing? From Conflict to Collaboration
40mWhen documenting is designing
39mInvisible influence: the documentation behind UX copy
45mThe Content Design of Civil Discourse