今読んでいる本 UXデザインの教科書#3

今日もよんでます。
認知工学が出てきて若干ないてます(´;ω;｀)
うぇぇぇとなりながらもやらねばならぬは人の道、、、

利用文脈

ユーザーは脈絡なくサービスを使うことはありません。
何かしらの理由があり、サービスを使い、どんな状況で、どんな背景でつかっているのかをしることが、ユーザーを理解することにつながります。
このどんな状況・時・理由etc..でサービスを利用するのかを表しているのが、利用文脈になります。

文脈効果とサービス
文脈効果は過去の経験に基づいて生じるものです。
あるサービスを使用するとき、今までの経験から、使い方・使う目的を自身で解釈して、使用していきます。
例えばnoteの下書き保存ボタンの左にあるメニューは、メニューアイコンの形をしていて、下書き保存ボタンの近くにあるため、記事を書くことに関するボタンなんだと解釈して使っています。

把握すべき利用文脈
１．ユーザーおよび他のステークホルダー
ターゲットにしているユーザーのニーズ以外にも、関連するユーザーたちがいて、そのニーズも把握しなければなりません。
２．ユーザーの特性
ユーザーの能力や経験、好みなど、それぞれのユーザーグループを定義しなければなりません。そうすることで、多様な想定ユーザーに対して、使用できるサービスを作ることができます。
３．ユーザーの目標と仕事
ユーザーが目標としているものと、サービスを使って行うタスクを特定しなければなりません。
４．システムの環境
物理的、文化的な環境を特定する必要があります。
サービスを使う空間、照明などから、仕事の習慣、組織構造などなどを特定します。

もう少し具体的な文脈のとらえ方
HMI(Human Machine Interface)をとらえることが大切です
以下の要素が自身の想定するユーザーに適合するか検討することが重要です。
１．身体的側面
想定されるユーザーの身体的な特徴をとらえる。
Webサービスでは椅子に座ってパソコンを使えればいいので、そこまで重要ではない？？
２．頭脳的側面
ユーザーはインターフェースから情報・文脈を理解・判断して操作するため、これらの一連の文脈と操作をわかりやすくする必要があります。
３．時間的側面
作業や操作にかかる時間を指しています。
操作のあとの反応時間が適切である必要があります。（速く次のページに移動するのはいいですが、同じようなページに速く移動してしまったら、混乱を招く可能性もあったりするってことですね）
４．環境的側面
作業を行う空間のことを指します。
Webサービスでは、パソコンのスペック、ブラウザ、端末なども考慮した方がいいのかもしれません。
５．運用的側面
サポート体制や、ユーザーへのマニュアルなどを指します。
サポートがいればそこをみれば、操作方法がわかる、という文脈が生まれます。

あなたのサービスはどの範囲の文脈にあるのか
サービスを考える上で、ユーザーがどのサービスを使うのかを選択することができる場合、サービスの中だけの文脈を考えるのではなく、その前の文脈も考慮しなければならないです。
広い範囲の利用文脈を把握して、どの範囲の文脈に注目するのかを検討しなければなりません。

Webサービスにおける文脈
Webサービスを使うまでの文脈を考えるとき、Webの世界のみを考えがちですが、現実世界の文脈も考える必要があります。
そして生活のどのタイミングで使い始めたのか、検索結果のなかでなぜそのサービスを選んだのか、など、様々な文脈を考慮する必要があります。
そしてそれらはユーザー視点で利用文脈を考え、その文脈は多重になっていることを理解しておかなければなりません。

ユーザビリティ

製品・サービスの構成要素
製品・サービスは以下の構成要素を持ちます。
モノ・プロダクト
└ ユーザーに提供されるものを指します。
　品質のレベルは、ユーザーの満足度を左右します。UXデザインの一番重要でわかりやすいものですが、製品・サービスの一要素である点も忘れはいけません。
サービス・プロダクト
└ サービスの内容のことです。
　ユーザーが体験するサービスの一連の流れの計画が、これに当たります。
サービス・デリバリー・システム
└ 実際にユーザーが経験するサービス活動のながれです。
　サービス・プロダクトは計画でしたが、こちらはサービス計画を利用できるようにするための仕組みのことを指します。UXデザインはサービスを提供する仕組み自体も設計します。
サービス環境
└ サービスが使われる環境のことです。
 　面倒なメルマガや、広告は環境を悪くする要素になります。

ユーザビリティってなーに
製品は目的を達成するためのものですが、ユーザビリティはユーザーがその目的を達成するために、どれほど機能を容易に操作できるのか、を表す言葉です。
ユーザビリティが高ければUXの質もよいものになります。
そしてユーザビリティが低いとユーザーが感じることは、悪いUXだったということになります。その結果としてユーザビリティが低いことも意味しています。
UXとユーザビリティは密接にかかわっていますが、ユーザビリティはユーザー側ではなく、製品としての品質の位置に立っている言葉です。

ユーザビリティの範囲
ユーザビリティの評価基準はISO/IEC 25010の製品品質モデルの中で以下のような構成要素をもつとされています。
適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザインタフェース快美性、アクセシビリティ
このなかで、適切度認識性は、ユーザーのニーズに、そのサービスが適しているものか、ユーザーが認識できる度合いを指しています。
つまり、チュートリアルやマニュアル、Webサイトの情報提供までがユーザビリティに含まれます。

目標達成から考えるユーザビリティ
ユーザーが目標とする、達成したい結果には、ユーザーごとに様々なアプローチがあります。
紆余曲折しながらも達成したユーザー、面倒であきらめたユーザー、それぞれのユーザーの行動を測定することで、サービスの品質向上としてのユーザビリティを定量的に図ることができます。

目標の階層性
ユーザーの目標は、目的地に行きたいなどの概念的なものから、カーナビで目的地設定をしたい、という具体的で手段的なものへとつながって階層を成しています。
目的地に行きたい場合でも、その上の階層にはデートに行きたい、というものがあったり、デートなのでスムーズにいきたいというように、カーナビの一つ上の階層に、目標がある場合もあります。
そのため、各階層のどの目標をみるのか、利用文脈を読み解きながら、理解することが重要です。

指向性と満足感
ユーザーの目標達成するまでの行動を以下の３種にわけることができます。
１．目標指向的行動：先に示した目標の達成が主眼の行動です。
２．プロセス指向的行動：目標達成までの過程を主眼とする行動です。
３．状態指向的行動：目標達成よりもその製品をもつことなどの状態を主眼とする行動です。
上記３種のユーザーのUXは、それぞれ異なります。
ユーザーの目指す目標、どの部分を重視しているのかを考慮することで、ユーザビリティを定量的に図る際に、どの目標を重視して検討するのか、考える参考になります。

人間中心デザインプロセス（HCD）

UXデザインを実践するためのプロセスとして活用される理論です。
ユーザーを中心においたデザインを行うためのものです。

HCDを使う理由
HCDを使う理由には以下の要素があります。
１．作ってみたらユーザーのニーズに合わないものだった、ということを防ぐ。
２．開発メンバーの意思を合致させるため。
誰のために、何を求めている人に、これを目標として掲げることで、開発メンバーのよりどころを作ることができます。
そして、HCDから、ユーザーではない我々は離れていってしまいます。
それが深刻にならないよう、開発のどの段階においてもユーザーの価値や、ニーズを再確認する必要があります。

反復設計
HCDプロセスは、以下のように進んでいきます。
１．利用状況の把握と明示
ユーザーの利用文脈を把握し、それを資料にまとめます。
２．ユーザーの要求事項の明示
ユーザーとサービスを提供する側の目標を考慮したうえで、
ユーザーの要求事項、つまり、ニーズを明確に示します。
３．ユーザーの要求事項を満たす設計による解決案の作成
企画・デザイン・UIを考慮して、ユーザーが目標を達成できる状況を設計します。
４．要求事項に対する設計の再評価
ユーザーの要求事項に、設計した解決案が合致するものか、再確認します。
これらを繰り返しながら、常に、ユーザーを念頭において、サイクルを回します。

HCDの原則
HCDには６つの原則が提示されています
１．設計がユーザー、タスク、環境の明確な理解に基づいている
利用文脈を把握することです。
利用文脈を把握することで、開発を進める中で立ち返るポイントにすることができます。
２．ユーザーが設計と開発全体を通じて参加している
実際にユーザーが開発に協力すべき、ということを示しています。
ユーザーの身になってもユーザーではないので、ユーザーテストは大事です。
３．設計がユーザー中心の評価により実施され、洗練されている
ユーザーからの評価を得ることができないばあい、または開発の途中段階では、利用文脈を考慮して、ユーザーの立場になって、開発メンバーで設計をみなおすことが大切でることを示しています。
４．プロセスを繰り返している
評価を行った後に、出てきた問題を必ず解決して、先に進むことが重要です。
５．設計がユーザーエクスペリエンス全体に取り組んでいる
UXを考慮することで、よりよいUXを達成すべきということを示しています。これはHCDプロセスの目的にあたります。
６．設計チームが学際的なスキルと視点を取り込んでいる
ビジネスと、技術上の問題、ユーザーのニーズのトレードオフが起きることが多々あります。その場合は、問題を解決しながらもUXの質を落とさないよう、解決策を探します。
そのための視点を、持つことです（できれば人を用意したいがめちゃきついっす）

モニタリングは忘れずに
HCDプロセスは開発中のことを言及しているが、
開発後も長期的にモニタリングすることで、ユーザーのUXを確認する必要があります。

デザイン手法で使おうと思うもの
ハートソンとパイラのモデルがWebサービスの開発にはよさそうでした。
具体的には、
１．ビジネスドメイン、ユーザーの仕事、ニーズの理解
２．コンセプトデザイン、見栄えのデザイン、デザインパターンの作成
３．プロトタイピング、UIの設計
４．再確認を行い、修正・改善する
この開発のながれは、１→２→３→４の順に進み、
１が終わればその段階を確認し、問題なければ２に進む、
必要であれば１つ前の段階に戻るという流れになります。
また、デザインとUIを切り離して考えることで、それぞれの与えたいUXの違いを考慮した構造になっています。

認知工学、人間工学、感性工学

それぞれ関連書籍を読みましょう、、、、、(´;ω;｀)
ヤハリサケテハトオレヌイバラノミチ
「誰のためのデザイン？」（D.A.ノーマン）を読みましょう

インターフェースの二重接面
インターフェースにはユーザーとシステムの間にある直接的なインターフェース（触れる部分：マウス・キーボード）とシステムが実際に処理を行うインターフェース（触れない部分：受けっとった情報を処理する）があります。
後者の第二接面の処理ができるということを、前者の第一接面で、わかりやすく、操作しやすく設計することが重要です。
例えばボタンを押すと、その処理が始まることや、ホイールを動かしてスクロールするなど、処理ができることを分かりやすく説明することが大切。

行為の７段階モデル
人間の行為には実行と評価の段階があります。
実行の段階ではゴールから出発します。ここでいうゴールは達成したい目標です。
ゴールはプランに変換され、プランを実現するために、行為を詳細化します。そして、その詳細化した行為が実行されます。
そして評価の段階では、実行した行為の結果（外界）を知覚して、予想・期待に沿って結果を解釈します。その後、プランとゴールに照らし合わせて、比較を行います。
この流れに沿ったデザインが、認知的にわかりやすいデザインになります。

簡単に解釈すると、実行の段階ではプランを立てやすく、詳細化もわかりやすくするために、しっかりとしたマニュアルを作ります。
そして、外界の知覚に対しては、レスポンスを早くすること、レスポンスできない場合は、シークバーなどを出すこと、当然ゴールに近い結果を返すことが大切です。

アフォーダンスと̪シグ二ファイア
アフォーダンスは、モノ自体が発する意味を示しています。
例えば、ボタンであれば、「押せる」という意味を発しています。
そしてシグ二ファイアは、ボタンに影をつけることで、「押す」行為を促すデザインを作ることです。当然影をつけたボタンもアフォーダンスを発していて、「押す」の意味を発していますが、それは知覚するためのものではなく、その「押す」という意味そのものを発しているだけです。
反対に、シグ二ファイアは、意図的に、適切に「押す」を発するようにデザインを作る、という言葉になります。

とにかくノーマンの「誰のためのデザイン？」を読みましょう

ガイドライン・デザインパターン

ガイドラインの作り方
デザインを行う際に用いるルールをまとめたものです。
デザインの方針を示します。作り方は以下に沿っていきましょう。
１．設計指針
複数のサービスで、数世代にわたって使われるデザインを考える。
また、それは全社的なデザインに対する取り組みの姿勢も示す。
２．デザインガイド
設計指針を反映したガイドライン。
操作体系を統一し、パターンを整理します。
ユーザーの操作への学習効率を高めるためにあります。
ムードボードなどがそれにあてはまります。
３．スタイルガイド
特定のサービスにおいて、数世代にわたって使われるデザインです。
デザインガイドにそった、画面のモックアップなどがそれにあたります。

iOSヒューマンインタフェースが有名ですね

8つの黄金律
１．一貫性を持つようにする
一連の動作は一貫した操作で行えるようにする。
反対に削除などは一貫性から外れるとわかりやすいです。
２．あらゆるユーザビリティを満たす
技術への理解度・多様なニーズによって、内容を変形できるような柔軟なデザインを行う。
３．有益なフィードバックを提供する
どんな操作にもフィードバックを提供しましょう。
影響の度合いによって、小さなものには簡潔に（ハートがぴこっ）大きなものには情報量を多くします（ツイートが表示されてポップアップが消える）
４．完了感を与えるための対話
操作の流れの起承転結をつけましょう。
一つのことをやりとげた満足感、安心感をあたえ、次の動作への準備ができるようになります。
５．エラーの処理を簡単に
致命的なエラーを出さないようにしたいが、出てしまった場合は、簡単な解決を提示する。（Websocket きれたらリロードしてねとか）
６．簡単にやり直せるように
操作は可逆的にできるようにしましょう。
操作を誤っても、取り消せることを知っていれば不安もなくなり、いろいろな機能を試すことができます。
７．制御の内部が見えるように
自分がシステムを制御し、システムは単にその操作に応答している、という感覚にできるようにしましょう。
ユーザーが想定していない挙動や、期待していたことができないことをなくしましょう。
８．短期記憶領域の負担を減らす
表示は簡潔に、何ページにもわたる表示は統合、一連の操作を学習できるチュートリアルを用意します。

これらの原則はあくまで原則です。
利用文脈によって当てはまる原則がきまり、
組織の目標、想定ユーザーが必要とするニーズ、支援しようとする仕事、利用可能な技術・資源を元に、優先度を決めていきます。

デザインパターン
デザインの基礎となる、ムードボードの作成。
ユーザーはパーツが十分に見慣れたもので、関係性が明確であれば、初めてみるインタフェースでも、理解してくれます。
その慣用句をまとめたものを作ります。

「使いやすいアプリケーションは、”慣用的”になるようにデザインされている」（ジェニファー・ティドウェル）

今日はここまで