Best practice communication & documentation
- don’t forget the purpose
- keep in mind the users
- what do they already know?
- what problem do they want to solve?
- focus on how not what: “A common mistake […] is to describe the what of the interface, instead of the how of a user’s workflow [e.g.] Click the Confirm Button to confirm [lol]”
- have a quick-start guide
- don’t ship your org chart, ship a solution (instead of categorising into products/features, categorise into use-cases/solutions)
very few users want to be using software. Instead, they want to do the things that software enables. […] Users don’t want to buy your software, and they don’t want to read your documentation—they just want to have their problems solved