veyepar: How to Write Documentation for People that Don't Read

Author(s):	Kevin Burke
Location	Crystal Ballroom
Date	may Mon 18	Days Raw Files
Start	11:40	First Raw Start	11:30
Duration	00:30:00	Offset	0:09:18
End	12:10	Last Raw End	12:11
Chapters	00:00
Total cuts_time	28 min.

http://lanyrd.com/2015/writethedocs/sdmwxy/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf How_to_Write_Documentation_for_People_that_Dont_Read.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

It&#39;s 3AM, do you know where your users are? If people want to learn how to use your product, where are they looking for help? Are they on your site, and if they&#39;re on your site, are they finding the right page?
Usability researchers have known for decades that users don&#39;t read word by word - they scan for the content they want.
If users can&#39;t make heads or tails of your documentation, they&#39;ll give up (a loss of revenue), remain ignorant of product features (another loss of revenue) or ask needless support questions (an increased cost).
In this talk we&#39;ll examine the findability of your documentation, and the text on the pages in your documentation. We&#39;ll examine usability research into how users read, look at several ways your documentation is failing busy users, and the lessons I learned conducting user tests at Twilio. We&#39;ll learn more about how users find the answers they are looking for, and the importance of spreading clear writing across not just your documentation, but your headlines and error messages in your API.

Comment:

production notes