• 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