アカウント名:
パスワード:
マニュアルが分かりにくい、という原因の1つとして「マニュアル担当が実物に触れて書いていない」ことが挙げられます。
私のところはパッケージソフト中心の事業をしていて、バージョンアップでの製品更新が多いです。で、マニュアル担当に渡すものは、前バージョンのマニュアル、バージョンアップで変更された部分の概要(ただしパンフレットに書く程度のおおざっぱな内容)、あとはα前~βの完成度の実物ですね。とにかく実物はほぼ必須。
仕様を定義する仕様書と、機能をうまくユーザに説明するためのマニュアルとは、話の進め方もずいぶん違うはずだと思うので、構成も基本的にはマニュアルライターに任せます。ある程度実物をいじらないとマニュアルを書けないはずだという意識はあります。なお、マニュアルライターがいじっているうちにバグを見つけてくれるという副次的な効果もあります。(苦笑)
またマニュアルはユーザが読むだけでなく、電話サポートでユーザに説明する時にも使われます(電話で、マニュアルに沿ってユーザに操作してもらうようお願いして、どこで止まっているのか確認するなど)から、ユーザに分かりにくい単語があるとか、操作の流れの説明が良くないなどを確認するため、電話サポート担当者にも読んでもらってます。彼らにしてみれば読みやすくて説明のしやすいマニュアルを作れば、かかってくる電話も少なくなるし、かかってきたとしても誘導しやすいので、ちゃんと読んでくれているみたいです。もちろん彼らにも実物を渡します。
それが普通だと思っていたんですが、違う所もあるんですね。ちょっとびっくり。(^_^;
なお、マニュアルライターがいじっているうちにバグを見つけてくれるという副次的な効果もあります。(苦笑)
またマニュアルはユーザが読むだけでなく、電話サポートでユーザに説明する時にも使われます
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
いわゆる・・・ (スコア:2, 興味深い)
釣った魚に餌は要らない (スコア:2, 興味深い)
マニュアルが分かりにくい、という原因の1つとして「マニュアル担当が実物に触れて書いていない」ことが挙げられます。マニュアル担当と言っても渡された資料を DTP 化するだけだったりすると、原稿は開発の外部仕様書だったりします。これではマニュアルというより資料です。
テクニカル・ライターは、商品知識を持ち、サポート状況を把
Mc.N
マニュアル校閲者 (スコア:2, 興味深い)
私のところはパッケージソフト中心の事業をしていて、バージョンアップでの製品更新が多いです。で、マニュアル担当に渡すものは、前バージョンのマニュアル、バージョンアップで変更された部分の概要(ただしパンフレットに書く程度のおおざっぱな内容)、あとはα前~βの完成度の実物ですね。とにかく実物はほぼ必須。
仕様を定義する仕様書と、機能をうまくユーザに説明するためのマニュアルとは、話の進め方もずいぶん違うはずだと思うので、構成も基本的にはマニュアルライターに任せます。ある程度実物をいじらないとマニュアルを書けないはずだという意識はあります。なお、マニュアルライターがいじっているうちにバグを見つけてくれるという副次的な効果もあります。(苦笑)
またマニュアルはユーザが読むだけでなく、電話サポートでユーザに説明する時にも使われます(電話で、マニュアルに沿ってユーザに操作してもらうようお願いして、どこで止まっているのか確認するなど)から、ユーザに分かりにくい単語があるとか、操作の流れの説明が良くないなどを確認するため、電話サポート担当者にも読んでもらってます。彼らにしてみれば読みやすくて説明のしやすいマニュアルを作れば、かかってくる電話も少なくなるし、かかってきたとしても誘導しやすいので、ちゃんと読んでくれているみたいです。もちろん彼らにも実物を渡します。
それが普通だと思っていたんですが、違う所もあるんですね。ちょっとびっくり。(^_^;
vyama 「バグ取れワンワン」
Re:マニュアル校閲者 (スコア:1)
マニュアル面では通常より恵まれていると思いますよ。多分。
Mc.N