|
> "In my experience, people don't read documents." I think this is worth calling out for its own discussion. Along with the traditional use of "RTFM" meaning "go away and stop bothering me", any amount of dysfunction in a sytem or company can be tolerated as long as someone has written about it in a document somewhere. Poor design? Buggy implementation? Complex configuration? Poor defaults? Missing features with inconvenient workarounds? Arduous processes? All fine as long as it's been documented. And any comments about voluminous documentation and "I couldn't find it" become point-scoring "I know where the needle is in the documentation haystack so I win". And as a user or customer, the last thing I want when facing your system being complex and unintuitive is a mountain of documentation to go with it. That adds insult to injury - you couldn't make a good system and you've made more work for me on top. How often have any of you read some good documentation about the internal workings of a system and left feeling intrigued and surprised and impressed? Occasionally, right? And how often have you trawled through documentation saying things like "to change the username field, simply log into our admin website, click accounts, click usernames, click customize, then download the XML customization file from the available template files, make the necessary changes, and simply raise a support ticket for us to install the new file" ? A poorly designed feature with an awkward process, with parts where detail matters (content of the file) left for guesswork, but at least it's all documented. I want my intuition (experience) to carry me almost seamlessly through your system, and if it has a short amount of clear documentation which helps me then I'm OK with that. If you want me to commit to trawling through books worth of content to learn things which are your own proprietary lock-in buzzwords around Rube Goldberg kludge designs, I'm not as OK with that. |