Recommended
More Related Content
Viewers also liked
UIがわかりにくいって言うけど、そもそもわかるって何なの？
- 2. 五ヶ市 壮央 (ごかいち たけひさ) ソニーデジタルネットワークアプリケーションズ株式会社 UX デザイナー / インタラクションデザイナー 2
- 5. 回答はのちほど。
- 6. 今日のお話
- 8. 命題的知識
- 10. 10 Abk skl yamaku sumi 命題的知識
- 11. 11 Abk skl yamaku sumi 命題的知識 ? ? ? ? それぞれの単語を読んでも絶対にわかりません！ …これは適当に打っただけの文字だから。
- 12. 12 सोनी 命題的知識
- 13. 13 सोनी 命題的知識 SONY 命題的知識があるので「わかる」 命題的知識が無いので「わからない」 ? いっつあソニー！ 文字を理解するには、文字という形で記号化された情報を解読する必要がある。 このような「A は B だ」という知識を「命題的知識」という。
- 14. 14 文字情報だけではなくサインやジェスチャーにも当てはまります。 • 例: 交通標識 知識無しではわからないものがたくさん。 • 例: 審判のジェスチャー 例えばサッカー。審判が手や旗でファウルを示す。これはジェスチャーと ルールが頭の中でつながると理解できるもの。知識無しではわからない。 命題的知識
- 15. 手掛かり情報
- 24. スキーマとメンタルモデル
- 32. スキーマとメンタルモデル 32 右を上げて、左を下げて… 10 14 9 6 28 4 3 2 7 15 1 この図があると 「サッカーのフォーメーション変更」 だとわかる。 しかし、サッカーの戦術を知らないと どんな意味があるか想像できない。
- 33. スキーマとメンタルモデル スキーマ • 作業の流れや作業の関連や特性など、構造化された知識を「スキーマ」という。 • 目玉焼きについての文章は、目玉焼き作成のスキーマが発動して「わかる」ことにつながった。 • トイレの開発会議についての文章は、トイレ作成の手順であったり焼成と季節の関連がわかっていないと、 一体何のことを言っているか想像できない。 33
- 36. スキーマとメンタルモデル 36 • ジョンは、窓口に1800円を渡した。 • 彼女はジョンに900円を渡そうとした。
- 37. スキーマとメンタルモデル 37 • ジョンは、窓口に1800円を渡した。 • 彼女はジョンに900円を渡そうとした。 • しかし、彼は受け取らなかった。それで彼らが中に入ったとき、彼女は彼に大きな ポップコーンを買った。
- 38. スキーマとメンタルモデル • ジョンは、窓口に1800円を渡した。 • 彼女はジョンに900円を渡そうとした。 • しかし、彼は受け取らなかった。それで彼らが中に入ったとき、彼女は彼に大きな ポップコーンを買った。 38 それぞれの文章を提示された段階で生まれた仮説が「メンタルモデル」 この例では窓口にお金を渡すところまでは他の行動でもありえる手続きですが、ポップコー ンが映画のスキーマを発動させ、「わかった」につながった。 (Collins, Brown & Larkin, 1980 価格を改変)
- 40. 「わかる」とUI
- 41. 「わかる」とUI 41 Aさん「パソコンが動かないんだけど…」 Bさん「まじか！動作環境は？」 Aさん「ふつうに、机の上で、部屋の隅に…」 送り手と受け手でメンタルモデルが異なるために起こった会話 ・ Aさんの「環境」は物理的環境 ・ Bさんの「環境」はスペックや設定など。
- 42. 「わかる」とUI 42 デザイナー (送り手) ソフトウェア ユーザー (受け手) (メンタルモデル) (メンタルモデル) メンタル モデルを 反映 検証 行動 (Norman, 1986) ギャップがある ギャップがある UI ギャップがある ギャップが無い状態にすることでわかるようになる
- 43. 「わかる」とUI 43 デザイナー (送り手) ソフトウェア ユーザー (受け手) (メンタルモデル) (メンタルモデル) メンタル モデルを 仕様化 検証 行動 (Gokaichi, 2013) ギャップがある ギャップがある UI ギャップがある 実際デザインの現場はエンジニアが入るのでメンタルモデルの伝言ゲームになる (だから指示書や仕様書は大切) エンジニア (送り手) (メンタルモデル) ギャップがある 実装
- 45. • すでに知っている知識を使う – ユーザーの知っている言葉を使う – デザインパターンを適用する – ユーザーの知っているメタファを生かす など… 45「わかる」とUI [※1] ウィザードは手順がブツ切れで関連が見えにくいので「洗濯」の例のように意味が見えにくくなってしま う。初回起動時の設定などでありがち。事前にユーザーへ作業の意味を伝えたり大まかな作業の意味を伝える など、必要に応じてウィザードでも「わかる」ための工夫を用意すると有効。 • 知識を使わず使えるようにする – ウィザード形式にする[※1] など… UIデザインのセオリーを守るユーザーはわかる
- 46. 46「わかる」とUI • 作業の前に学べる – チュートリアルで体験させる – 初回起動時に作業とその意味を伝える – 文章少なめ、絵は多め(とっつきやすくする) – ヒントを表示する など… • 使いながら学べる – 用語やビジュアルボキャブラリーを統一する – フィードバックにルールを持たせる – 行動に関連したフィードバックを返す – 細かくフィードバックする – Undoできる (怖がらずに作業できる) など… UIデザインのセオリーを守るユーザーは学べる
- 50. 「わかる」とUI • デザイナーとユーザーにはメンタルモデルにギャップがある • デザイナーのデザイン意図をエンジニアに伝える仕様書や指示書は大切 • セオリー通りにUIデザインすることがわかるUIにする一歩目 • ユーザーテストではどんな知識がわからないのかを注意して観察する • わかりやすくなるよう機能 (ときにはUX全体) の複雑さを減らすことも効果的 • 無理ならば、複雑なことを難しくても正しく明確に伝えるのが効果的な気がする 50
- 51. 参考文献
- 52. 参考文献 52