Given at Write the Docs Europe, 2015. See the write-up here (https://docs.google.com/document/d/1HTuKl4gSOcqdqYY72MK_frbTpHb73j_WnZN3HExp184/edit?usp=sharing)
Good documentation is important, but it should be your last resort. You need to help users before they reach the docs - in the user interface itself.
In this talk, I discuss:
- strategies for writing microcopy when you’re short on space
- what to explain in the UI, and what to save for the documentation
- how to pick the right style of embedded help
- what makes a great error message (and a terrible one)
... with plenty of real-world examples of doing it right and wrong.
If you're interested in this, see my blog for more detailed examples: http://uiwriting.tumblr.com/
27. Three strategies for microcopy
1. Think from the user perspective
2. Choose names they can understand
3. Experiment with phrasing
Introduction - Microcopy - Help - Errors
28. 1. Think from the user perspective
Explain what a feature does, not how it
works
Introduction - Microcopy - Help - Errors
57. Embedded help vs docs
- If it’s necessary information:
probably keep it in the UI
- If it’s huge:
summarise, then link to a doc
Introduction - Microcopy - Help - Errors
58. Show it in the relevant place
Introduction - Microcopy - Help - Errors
66. In summary
- find out what user needs to complete
task
- don’t overload with information
- show help in a relevant place and time
Introduction - Microcopy - Help - Errors
82. - what went wrong
- consequences
- how to fix it
(and leave it out if it doesn’t apply)
Introduction - Microcopy - Help - Errors
83. In summary...
- Experiment with naming to get your
microcopy right.
- Support users with embedded help in
the UI, but be ready to link to docs.
- Use the formula for error messages!
Introduction - Microcopy - Help - Errors