Stachybortrys chartarum likes a cutting board that it is wet, warm, fertile.
The following should be done after using a cutting board.
1. Washing it very well with a soap.
2. Dry it at well-ventilated place.
3. sometime marinate it bleach.
----
黒カビは濡れていて、少し暖かくて、栄養がたっぷりのまな板が大好きだ。
まな板を黒カビから守るには以下のことをする。
1. 洗剤でよく洗う
2. 風通しのいいところで乾かす
3. 時々漂白剤に漬け込む
2011年8月27日土曜日
2011年8月2日火曜日
6 Tips for making a user manual (1)
ユーザーマニュアルについての悪いうわさがある。アメリカでのある調査、、
「あなたを混乱させる可能性のある技術的なものってなに？
という質問に対しなんとユーザーマニュアルがトップに！
企業はもう一度マニュアルについて考えなおしてみてもいいかもしれない。（Philip Hodgson posted）
ってことでマニュアルってたしかに難しい。
私も先日自社製品に関わるマニュアルを書いてみたけど
24ページの仕様をまとめるのに1ヶ月ぐらいかかったし、
改善の余地があるんじゃないかと今なおあれこれ試行錯誤しています。
その中で感じたコトと今回この記事を読んでまさにこれと同じコトやってた！
と思ったので少し深く読み込んでいきたいと思います。
ということで今回はマニュアルのユーザービリティについての話です。
----
ベストプラクティスとしての原則だったり、
『読む』ということに関する人間の知覚や認知、心理などの側面だったり、
また、世にあるあらゆるマニュアルやドキュメントをテストした結果と基にまとめています。
* General guidelines
* How to create a great first impression
* How to enhance findability
* How to give instructions
* How to design individual pages
* How to design the physical manual
では一つ目からみていきましょう。
General Guideline for user manuals
（ユーザーマニュアルの一般的なガイドライン）
このガイドラインで注目すべきは5つ目です。
「何のためにその機能があるのかを伝えること」
これは私も間違えてしまうことでその機能の使い方ばっかり書いてしまうんですよね。
例えば、GUI画面のマニュアルを書く時、画面項目の説明を中心に書きます。
これはワークフローの申請タイプです。申請タイプは「新規登録」「更新」「セルフメンテナンス」から選択できます。
ってかんじでね。新規登録用のワークフローを作成したいユーザーはこの説明を見てあぁ、これか、って思いますが
そうではない人はこれだけを見てもどの申請タイプがどう働くのかわかりませんよね。
でもいつも製品を作るときって勢いが重要なときもあって、
なんとなくのコンセプトで作ってしまうことがあるし、
ユーザーからのフィードバックを何の気なしに受けて製品に反映させてしまうこともあるので
実際に製品が完成してみると仕様が変わっていることもよくあります。
トータルで見るとちぐはぐな仕様になっていることもしばしばあります。
そんな中でマニュアルを作成しても一貫性のないものになってしまい余計ユーザーは混乱してしまうかもしれません。
そこで仕様を一度マニュアルとして明文化してみるといいかもしれません。
設計書とは違います。もっとユーザー目線で記述されるものです。
初めて製品を見た人が「これを使うとこういうことができるんだ」というのがわかるようなものです。
私は以下の流れで書くことが多いです。
誰が、いつ、何のために使う機能か。
その機能を使うと何が出来るのか、を明らかにします
アカウント情報変更機能はログインユーザーが自身のアカウント情報を変更するため機能です。
アカウント情報に変更が生じた場合、WEBブラウザから自身のアカウント情報を変更することができます。
変更内容は管理者ユーザーが承認後、反映されます。
そして、必要に応じてどのようにその機能を使うか、を明らかにします。
ここに記載される内容はリファレンスマニュアルとしての内容を含むと思います。
XX設定画面に表示されるツリーを展開し、変更可能なアカウント情報を設定します。
誰が、いつ、何のために使う機能かを明文化するには少なくとも製品仕様について十分理解している必要があります。
また、マニュアルを作成する人は製品開発チームの一人であり、プロダクトオーナーと開発者との架け橋になることも大切かなと思います。ビジネスの目標に対するプロダクトを作るためのプロダクトオーナーとそれを遂行する開発者、双方の思いをユーザー目線のワンクッションを挟むコトができるのがマニュアル作成者なのですから。
では次回は「How to create a great first impression（偉大なる第一印象を与える方法）」についてみていきたいと思います。
原文：http://www.userfocus.co.uk/articles/usermanuals.html
「あなたを混乱させる可能性のある技術的なものってなに？
という質問に対しなんとユーザーマニュアルがトップに！
企業はもう一度マニュアルについて考えなおしてみてもいいかもしれない。（Philip Hodgson posted）
ってことでマニュアルってたしかに難しい。
私も先日自社製品に関わるマニュアルを書いてみたけど
24ページの仕様をまとめるのに1ヶ月ぐらいかかったし、
改善の余地があるんじゃないかと今なおあれこれ試行錯誤しています。
その中で感じたコトと今回この記事を読んでまさにこれと同じコトやってた！
と思ったので少し深く読み込んでいきたいと思います。
ということで今回はマニュアルのユーザービリティについての話です。
----
ベストプラクティスとしての原則だったり、
『読む』ということに関する人間の知覚や認知、心理などの側面だったり、
また、世にあるあらゆるマニュアルやドキュメントをテストした結果と基にまとめています。
* General guidelines
* How to create a great first impression
* How to enhance findability
* How to give instructions
* How to design individual pages
* How to design the physical manual
では一つ目からみていきましょう。
General Guideline for user manuals
（ユーザーマニュアルの一般的なガイドライン）
- 物理的に存在するユーザーマニュアルを製品に添えて提供すること：PDFで読ませてはいけない
- あらゆる点で製品を網羅した説明がなされているか確認すること
- １ページに収まる量のクイックスタートが含まれていること
- 手順をステップバイステップで説明すること
- どんな機能があるのか伝えること、特に何のためにその機能があるのかも伝えること、
- どのように使うのか説明することは適切ではない
- マニュアル作成者は製品のデザインチームのメンバであること
- ユーザーマニュアルは製品の開発タイムラインと並行して作成すること。
- 出荷ギリギリのプレッシャーの下では作成しない
- マニュアル作成者は製品を実際に持っていて、製品を理解していて、そして実際に製品を使いながらマニュアルを作成すること
- 弱視や視覚障害を持った方へ配慮すること代替的なマニュアルとして点字、大きな文字、音声などを提供する
- ユーザーマニュアルと実際の利用者（障害者を含む）に製品のユーザーテストをおこなってもらうこと
このガイドラインで注目すべきは5つ目です。
「何のためにその機能があるのかを伝えること」
これは私も間違えてしまうことでその機能の使い方ばっかり書いてしまうんですよね。
例えば、GUI画面のマニュアルを書く時、画面項目の説明を中心に書きます。
これはワークフローの申請タイプです。申請タイプは「新規登録」「更新」「セルフメンテナンス」から選択できます。
ってかんじでね。新規登録用のワークフローを作成したいユーザーはこの説明を見てあぁ、これか、って思いますが
そうではない人はこれだけを見てもどの申請タイプがどう働くのかわかりませんよね。
でもいつも製品を作るときって勢いが重要なときもあって、
なんとなくのコンセプトで作ってしまうことがあるし、
ユーザーからのフィードバックを何の気なしに受けて製品に反映させてしまうこともあるので
実際に製品が完成してみると仕様が変わっていることもよくあります。
トータルで見るとちぐはぐな仕様になっていることもしばしばあります。
そんな中でマニュアルを作成しても一貫性のないものになってしまい余計ユーザーは混乱してしまうかもしれません。
そこで仕様を一度マニュアルとして明文化してみるといいかもしれません。
設計書とは違います。もっとユーザー目線で記述されるものです。
初めて製品を見た人が「これを使うとこういうことができるんだ」というのがわかるようなものです。
私は以下の流れで書くことが多いです。
誰が、いつ、何のために使う機能か。
その機能を使うと何が出来るのか、を明らかにします
アカウント情報変更機能はログインユーザーが自身のアカウント情報を変更するため機能です。
アカウント情報に変更が生じた場合、WEBブラウザから自身のアカウント情報を変更することができます。
変更内容は管理者ユーザーが承認後、反映されます。
そして、必要に応じてどのようにその機能を使うか、を明らかにします。
ここに記載される内容はリファレンスマニュアルとしての内容を含むと思います。
XX設定画面に表示されるツリーを展開し、変更可能なアカウント情報を設定します。
誰が、いつ、何のために使う機能かを明文化するには少なくとも製品仕様について十分理解している必要があります。
また、マニュアルを作成する人は製品開発チームの一人であり、プロダクトオーナーと開発者との架け橋になることも大切かなと思います。ビジネスの目標に対するプロダクトを作るためのプロダクトオーナーとそれを遂行する開発者、双方の思いをユーザー目線のワンクッションを挟むコトができるのがマニュアル作成者なのですから。
では次回は「How to create a great first impression（偉大なる第一印象を与える方法）」についてみていきたいと思います。
原文：http://www.userfocus.co.uk/articles/usermanuals.html
登録:
投稿 (Atom)