前回は操作手順の各要素についてそれぞれ考えてみました。今回は、その中でも操作文そのものについてもう少し分析してみたいと思います。

行為だけ?それとも目的も?

操作文を書くときに困るのが、操作を示すだけにするのか、それとも操作の目的も示すのかという点です。つまり「〜を押す」とするのか、「〜するために、〜を押す」とするのかを決めなくてはならない、ということです。

確かに、操作目的を示すことでユーザーによる応用操作を期待できるという面もあります。しかし、煩雑な目的を持つ操作を説明する場合には、手順説明文が重くなりすぎて、肝心な情報が伝わらなくなることも考えられます(単純な操作目的に還元できるまでに手順を分割すればすむ話かもしれません)。

一般的に、上級者や向上心のあるユーザーは操作目的を知りたがる傾向があるように思えます。操作目的と操作手順をあわせて理解することで、取扱説明書に説明されていない高度な使いかたもできるようになるからです。逆に「できればいい」と割り切っているユーザーは、必要な手順だけを知りたがるという傾向があるのではないでしょうか。

ということは、この問題は「取扱説明書の想定ユーザーをどこに設定するか」という問題に還元されることになります。ケースバイケースですが、一冊を通して、または章ごとに説明のスタイルは統一しておいたほうが良いでしょう。

一番重要なのは結果文

結果文のない操作手順なんて. . . 。どんなに分かりやすい手順を書いても、結果文がなければよい操作文とは言えません

ところで、そもそも結果文とは何でしょう? 結果文とは、ユーザーの操作の結果として起こる、機器側の反応を説明する文のことなのです。

  1. ○○ボタンを押す。
    〜ランプが赤色から緑色に変わります。

結果文がないとしたら、ユーザーは自分の操作が正しい操作だったかを知ることができません。結果文があることで、ユーザーは「緑色になった=うまく操作できた」または「緑色にならなかった=うまく操作できなかった」と知ることができるのです。

  1. カチッと音がするまで、バッテリーを押し込む。

これは一見、結果文がないように見えます。しかし、「カチッと音がするまで」という部分が結果文の役割を果たしているとも言えます。なぜなら、この部分がユーザーに「自分は正しく操作できたのかどうか」を知らせることができるからです。

こうしてみると、結果文が何故大切かおわかりいただけたかと思います。つまり、結果文は正しく操作できたかどうかの判断材料をユーザーに与えるために必要なのです。ユーザーに必ずフィードバックを与えるように製品側のインターフェースを改良しても、それが操作の結果であることをユーザーが認知できなければ、フィードバックの役割を果たしているとはいえません。

正しい操作とそれによるフィードバックを説明することは、初めて操作するユーザーにとっては非常に重要なことであると考えます。誤動作によってPL法問題に発展するような機器であれば、結果文はさらに重要になります。

操作手順内での分岐について

コストダウン要請によるページ削減の影響のためか、全く異なる操作目的を持つ操作の説明を強引にまとめて、途中で分岐させる例も見掛けるようになりました。メニューモードを持つ製品に多いようです。確かに操作手順はほとんど同じなんですがね. . . 。

「基本的な操作手順は同じだから、できるだけ共通化して途中で分岐させたほうが良い」という考え方も一理あるとは思うのですが、ユーザーから見ると困り者なのではないでしょうか。操作手順内では、あまり分岐させないほうが良いと思います。

ページを削減するための手段として割り切るにしても、基本的な操作や、ユーザーのニーズが高いと思われる操作に関しては、操作目的ごとに操作文を構成したいものです。

2回にわたって操作手順を考えてきましたが、いかがでしたか? 書きながら「これも入れたほうが良かったかな」ということもなきにしもあらずですが、また気づいた点があれば追加することとします。

「こういう例が抜けているのでは?」「こういうときはどうするんだ?」といった感想がありましたら、遠慮なくお寄せください。

The 1140px CSS Grid System · Fluid down to mobile