Skip to content

Instantly share code, notes, and snippets.

@fand
Created March 30, 2016 03:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save fand/44af82356a37cb38f4a766d9d9563827 to your computer and use it in GitHub Desktop.
Save fand/44af82356a37cb38f4a766d9d9563827 to your computer and use it in GitHub Desktop.
誰のためのデザイン?読書メモ

5

  • ミステイク

    • 現在の状況と過去の状況を混同することで生まれる?
    • 人間の思考のモデル(スキーマ理論 ≒ フレーム理論 ≒ 意味ネットワーク……)
      • 個々の構造には論理と秩序がある(スキーマ or フレームと呼ぶ)
      • 人間の記憶は連想的である
      • 演繹的な思考力は、あるスキーマから他のスキーマの特徴を演繹する力である
    • コネクショニストアプローチ ≒ニューラルネットワーク?
    • 人間は、得意な出来事に過大な重みを与えてしまう
  • 作業の構造

    • 広い深い構造: チェスのデシジョンツリー
    • 浅い構造: レストランの単品メニュー
    • 狭い構造: レストランのコースメニュー
    • 日常の行動は浅く狭いはず
  • エラーの原因

    • エラーを正当化してしまう: エラーじゃないはずだ、大丈夫だと思い込む
    • 社会的な圧力
  • エラーに備えてデザインする

    • 原則
      • エラーの原因を理解し、それが最小となるようデザインする
      • UNDO可能にする or UNDO不可能な操作はやりにくくする
      • エラーを発見・訂正しやすくする
      • ユーザーはまずエラーすると考える
    • 強制選択法
      • 車はキーを挿さないと起動しない、などの良いアイデア
      • あんまり面倒だとユーザーは抜け道を探してしまう
        • e.g. アメリカのシートベルト強制法案
      • インターロック
        • 電子レンジはドア閉じないと使えない
      • ロックイン
        • PCの電源を一瞬でオフにする手段はないので、安全に終了する
      • ロックアウト
        • 非常時に降り過ぎないよう、1階から下に行く階段には仕切りを設ける
      • NESの事例は、SNESで解決されてよかったですね^^
  • デザインの基本的な考え方

    • 必要な知識は外界においておく
    • 物理的・論理的・意味的・文化的制約を利用する
    • 実行と評価のへだたりを狭める

6章 デザインという困難な課題

  • デザインの自然な進化

    • 丘登り法(hill-climbing): 本番環境/実世界での遺伝的プログラミングてきな
    • 障壁: 時間、個々の主張、...
      • 独占時代のベルの電話機のほうが正気なデザインだった − タイプライターの例: 一旦満足のいくデザインが出来上がったら、それ以上の改善は合理的でない
      • qwertyで充分であり、普及しきってしまったため、dvorakは普及しづらい
  • なぜデザイナーは正しい道から外れるのか

    • 美しさ至上主義になってしまう
      • 業界的な問題
      • 「多分賞でもとっているんでしょう」
    • デザイナーは典型的なユーザーではない
    • 顧客が本当のユーザーとは限らない
  • デザインのプロセスの複雑さ

    • 「デザインというのは、他とは異なったユニークな製品ができるまで制約を繰り返し適用することである」
    • 万人にあうデザインはない
      • 殆どの人に合うデザインで妥協する
      • 少数の人には専用のデザインをする
    • 選択的注意
      • 一つの要因に囚われて、他の重要な要因を見過ごしてしまうことがある
  • 蛇口

    • 世界的な標準に従ってデザインしろ
  • デザイナーを脅かす2つの致命的な誘惑

    • なしくずしの機能追加主義 creeping featurism
      • 複雑になり、対応付けも出来ず、デザインが腐る
      • 対処法
        • 機能追加を避ける
        • 体系化してモジュール化する
    • 誤ったイメージをありがたがる
      • 多機能 = 善 というイメージとか
  • コンピューターシステムの弱点

    • 昔のソフトウェアはデザイナーによってデザインされてなかった
    • 多機能すぎて腐ってた
    • 悪いデザインをする方法: 不可視化, 恣意的にする, 一貫性をなくす, 操作をわかりにくく, 無作法にするジとか
    • WYSIWYGはいいよね
    • Xeroxの手法 = 良いシステムのデザインの仕方
      • 操作に一貫性をもたせる
      • 対象を可視的にして、その場面で利用可能な選択肢をわかりやすくする
      • 開発の過程の全ステップで、一つ一つのアイデアを実際のユーザーで試す
    • ユーザーが探索可能にする(学習し放題にする)
      • ユーザーに何が許されてるかわかる
      • 行為の結果が目に見え、解釈しやすい
      • 行為は代償なしに実行できる
    • 利用の形
      • コマンドモード: バッチとか
      • 直接操作モード: マウスでポチポチ
      • 直接のほうが最初はわかりやすいけど、むずい

7章 ユーザ中心のデザイン

  • 7つの原則

    • 外界にある知識と頭のなかにある知識の両者を利用する
      • デザインモデル、ユーザのもつモデル、システムイメージ が乖離しすぎないように
      • マニュアル駆動開発が理想だけど、マニュアルは大して読まれない
    • 作業の構造を単純化する
      • メモ等のメンタルエイドを利用し、学習コスト下げる
      • テクノロジーで可視性をあげてフィードバック増やす
      • 自動化する
      • 作業の性質自体を変更し、単純にする (マジックテープ、デジタル時計、……)
      • コントロールはなくさない(自動化し過ぎない、柔軟性はなくさない)
    • 対象を目に見えるようにして、実行のへだたりと評価のへだたりに橋をかける
      • a
    • 対応付けを正しくする
    • 自然の制約や人工的な制約など、制約の力を利用する
    • エラーに備えたデザインをする
    • 以上の全てが上手く行かない時には標準化をする
      • 車: 左側通行、右ハンドル、アクセルの位置
      • コンピューター: まだ? ←About Faceの3部でメッチャ論じてる
  • わざと使いにくくする

    • 安全やセキュリティのため
    • 7つの原則を反対にすれば良い
      • 重要な要素を隠す、不自然な対応付けをする、実際の行為を難しい物にする、操作に正確さを求める、フィードバックを与えない、システムの状態を解釈しにくくする
    • ゲームの場合: 簡単すぎず、難しすぎず
      • 様々な難しさを用意しておく
      • 絶えずイベントを発生させて好奇心を煽る
    • 使いやすく見える != 使いやすい
      • 車のダッシュボードはスイッチ多いが、操作の種類と対応してるためつかいやすい
  • デザインと社会

    • 文章を書く方法が文章のスタイルにどう影響するか
      • 羊皮紙+羽ペン -> 訂正できない
        • 長くて装飾の多い文章
        • 修辞法が重要
      • 最近: 修正が容易に
        • 日常会話に近いスタイルに
      • 書くスピードが向上 -> 口述筆記
        • 文章の構造が失われる
      • コンピュータ
        • 表示領域が狭い→文章の構造などが推敲されなくなる
        • 同じ文が大量にあっても気づかない
    • アウトラインプロセッサーとハイパーテキスト
      • アウトラインプロセッサーは段落ごとのタイトルとかそういう部分にばかり目が行きがち ←は??
      • ハイパーテキストは従来の文章の脚注とかが進化したもの
      • ハイパーテキストが広まったら、文章が大量に必要とされ、結果文章書く人はもっと大変になる
    • 毎日の道具のデザイン   
  • 作業の構造を単純化する

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment