satoshi murata
UXKYOTO STUDY
Published in
6 min readSep 5, 2014

--

誰のためのデザイン#02

抄読会: UXKYOTO STUDYで取り上げる書籍「誰のためのデザイン」の第2章『日常場面における行為の心理学』をまとめました

Chapter 2『日常場面における行為の心理学』

自分を責めてしまうという誤り

だれでも同じようなエラーを犯す

<例> Return/Enterキーの打ち間違い

課題が一見単純であったり些細なものであるように見えるとき、悪いのはデザインであるにもかかわらず、自分自身を責める。

→ 複雑な道具には教示が必要で、デザイナーは出来る限りエラーや損失を生まないような特別の配慮をすべき。起こりうるエラーが実際に起こることを想定した上で、そのエラーが起こる確立と、起こった時の影響が最小になるようにデザインしなければならない。エラーは見つけ出しやすく、その結果生じる影響は最小でなければならない。

毎日の生活の中の思い違い

アリストテレスの物理学

<例>ピストルから放たれた弾丸と同じ高さから落とした弾丸/走っている人がボールを落下させる

ピストルのほうがちょっと浮きそうとか、ボールはまっすぐ落ちそうといった素朴な考え方がそんなにも変だと思えない

→人間は何でも説明したがる生きものなので、自分がよく知らないものでも、自分なりに理解する方法を持っている

説明好きな存在としての人間

外部から情報を与えないと、誰でも観察したことを説明する理論(メンタルモデル)を形成してしまう。みたと思う事実と矛盾しない範囲で想像してしまう。メンタルモデルは一種の素朴心理学によって、断片的なデータに基づいて作られることも良くある。

<例>サーモスタット問題

メンタルモデル

メンタルモデルとは、ものがどのように機能し、できごとがどのように起こり、人がどのように振る舞うかについての概念モデル

メンタルモデルは、経験を理解したり、自分の行動の結果を理解したり、予期せぬできごとに対処するときの手助けとして必須である。「現実か想像か」や「素朴か洗練か」といった情報の質は問わない。

誤ったモデルは破滅的な事故につながるおそれがある。

間違ったことのせいにしてしまう

2つの出来事に因果関係を見てしまうA -> R

結果を得ようとして失敗した時の責任はどこに求める? A -> X -> R

知覚された因果関係

責任を帰せられることがらと結果との間には知覚された因果関係が存在していなければならない。因果関係は実際に存在している必要はない。

判断対象に関する情報をほとんど持っていないということが良くあるので、原因は、ほとんど現実とは無関係に判断される。日常の事物に関する失敗に際して自分自身を責めるというよくある傾向は、人が普通行う原因帰属の仕方と逆になっている。

自分の問題の原因は環境に、他人の問題の原因は性格に=誤ったメンタルモデル

<例>やっかいもののトムの朝のヒトコマ

ものごとがうまく行っているときは逆に原因が帰属する

学習された無力感

数えきれないほどの失敗の経験を繰り返し、自分には出来ないと無力感を抱く。プロセス:自分にはできない→やめてしまう。日常の道具では数回でも生じるかもしれない。鬱病も。

教えられた無力感

失敗を一般化してしまう。プロセス:何かで失敗する→自分のせいである→作業は達成できないと思う→次にその作業をする必要が出てもできないと思うのでやることさえしなくなる。

人間の思考と説明の性質

問題の原因の判断は容易ではない。 エラーにつながる判断をした人にとっては自然なこと。

<例>信号送信のフィードバック/百万回に一度のエンジンオイル切れ/4時間のマンモスドライブ

いったん説明を思いついてしまうと、思いつく前だったら気づいた矛盾や困惑を忘れてしまう。ほんの少しの間のことにすぎないけれども。

人はどのように作業をするか―行為の7段階理論

<例>映写機/読書中の照明調節

  1. ゴールの形成:何かをするためには何をしたいかという何らかの考え(=ゴール)がなくてはならない。達成されるべきものであってあまりはっきりと記述されない
  2. 意図の形成:ゴールを達成するための特定の行為
  3. 行為の詳細化
  4. 行為の実行
  5. 外界の状況の知覚
  6. 外界の状況の解釈
  7. 結果の評価

すべてを経由する必要はない。ゴールは具体的に特定されていないことが多い。ご都合主義

実行と評価におけるへだたり

<例>映写機

対応付けとフィードバックが困難。心のなかにある意図・解釈・実際の行為・状況の間の関係がどのようになっているのかを見つけ出すのが難しい。

実行のへだたり ―― gulf of execution

システムが利用可能にしている行為が、ユーザーが意図したものとどれくらい対応しているか。行為を余計な努力なしで直接することができるように。

評価におけるへだたり gulf of evaluation

ユーザーがシステムの状態を解釈するのにどれほどの努力が必要か。自分の予期や意図がどの程度よく満たされているか。

→これが小さいことは、システムの状態が分かりやすく、ユーザーが予測するシステムの反応がマッチ

どれくらい簡単に次のことができるだろうか

へだたりの橋チェックリスト

  • 装置の機能を見極められるか?
  • どんな操作をすることができるかを知ることができるか?
  • 問題になっているシステムが期待通りの状態にあるかどうかを言えるか?
  • 意図を実際の行為に対応づける関係を見つけられるか?
  • システムの状態と解釈との間の対応づけがわかるか?
  • その行為をすることができるか?
  • 対象システムがどんな状態であるかがわかるか?

→よいデザインの4原則。チェックリストの1つ以上の項目を支持するものとなっている。

使いやすいものは、注意深くデザインされている。

まとめ

  • なんらかのエラーが起こる場面では誰かがそのエラーをおこす。デザイナーは出来る限りエラーや損失を生まないような特別の配慮をすべき。
  • ユーザーが誤ったメンタルモデルを形成してしまうとエラーが起こりやすくなる。
  • ユーザーが頭のなかに作り上げている心理的な表現と外界の物理的な構成要素・状態のあいだに存在する距離がユーザーにとって困難である。
  • これを取り除くための7つの問いがある。そしてこれは良いデザインの4原則とも関連している。

--

--