Skip to content

DNET_UIUX

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

UI/UX

概要

（元 Wiki でも内容は未記載。）

詳細

全体を通して、

ユーザー・インターフェース（UI）

ユーザー・インターフェース（UI / User Interface）

  • UXが
    「ユーザーが（システムや製品、サービスから）受け取る体験」であるのに対し、
  • UIは「それを実現するシステムや製品、サービスのインターフェイス設計や仕様」を指す。

定義

  • 製品やサービス（機械、コンピューター、アプリなど）と、
    それを使うユーザー（人間）との間で、情報をやり取りするための境界線や仕組み。

    • OSのシェルが参考になるが、
      GUI、CUI（インタラクティブ・シェルとシェル・スクリプト）などがある。
    • 最近は、VUI（Voice User Interface / 音声ユーザー・インターフェース）なども
      加わってきている。
    • また、音声認識に留まらず事前の定義を必要としない、複雑な自然言語で指示できる、
      LLMエージェントなども別の区分のUIなのかもしれない。

  • UIを構成する2つの視点

    • 視覚的な要素（見てわかるもの）
      画面に表示されるデザインやレイアウト全般

      • ボタン、メニュー、アイコン、テキスト
      • 配色、フォント、画像の配置
      • グラフ表示やアニメーション

    • 操作的な要素（触って動かすもの）
      ユーザーが何かを入力したり、機械を動かしたりする手段です。

      • マウスのクリック、キーボードのタイピング
      • スマホのタップ、スワイプ、ピンチイン/アウト
      • 音声操作（「アレクサ」「Hey Siri」など）

UIデザインと基本ルール

本来、UI（操作画面）のデザインのみを指す概念ではないが、
一般的にはUIデザイン＝UI（操作画面）デザインと
受け止められている場合が多い。

ユーザ・エクスペリエンス（UX）

（ユーザ・エクスペリエンス / ユーザー体験）

  • 「ユーザビリティ」から派生した新たな拡張された概念。
  • システムや製品、サービスと関わったときの、人の反応のすべて。

定義と本質（UX）

  • 定義(ISO 9241-210:2019/JIS Z 8530:2021による)

    “システム、製品又はサービスの利用前、利用中及び利用後に生じるユーザの知覚及び反応”

  • ポイント

    • 本質的な意味：一言で言えば、
      「システムや製品、サービスと関わったときの人の反応のすべて」という非常に広い概念。
    • 影響を与える要因：ユーザーの知覚及び反応（注釈1）だけでなく、
      その他の製品・ユーザーに関する要因、利用状況（注釈2）の影響を受ける。

  • 注釈

    • 1：ユーザの知覚及び反応は、ユーザの感情、信念、嗜好、知覚、身体的及び心理的反応、
      行動並びに達成感を含む。
    • 2：製品の「ブランド・イメージ、表現、機能、性能、支援機能及びインタラクション」、
      ユーザの「事前の経験、態度、技能、個性によって生じる内的及び身体的な状態」、
      利用状況などの要因の影響を受ける

満足度全体を重要視

するようになった経緯

  • それまで主流だった「ユーザビリティ」だけでは
    説明しきれない製品・サービスとユーザーの関係性の説明が必要になった。

    • 魅力的な体験が勝るケース：操作が難しくても、孫と連絡が取れる携帯電話のように、
      得られる機能や体験が極めて魅力的であれば受け入れられる。
    • 難しさに価値があるケース：楽器の演奏技術やゲームの攻略、筋トレのように、
      訓練や適度な負荷、難易度の高さそのものがステータスや楽しさ、価値につながる。
    • 他の要素が優先されるケース：セキュリティ対策のように、
      安全性を確保するためにあえて複雑な手続きを受け入れる必要がある。

  • 主戦場の変化（サービスの提供形態や評価軸の多様化）

    • 物売から事売（コーヒー豆を売る から 自動販売機・カフェなど）など
      「価値提供形態を変え付加価値向上を図る」ケースの増加。
    • 機能・性能向上からUX向上（鉄道車両ではスピードアップから乗客のユーザー体験向上）へ
      シフトするケースの増加。
    • 具体的な事例：医療機器販売ではなく健診ソリューション
      （Philips Ambient Experience - People focused healthcare）

UIとの違い

  • UIとの違い

  • UIは製品側に帰属する仕様（寸法、色、構造、スペックなど）であり、
    製品とユーザーの接点の要素。

  • UXはユーザー側に帰属し、製品と接した結果として
    ユーザーの中に生じる「体験」そのものを指す。

  • UIとUXの関係性：「UI＝原因」「UX＝結果」という因果関係にある。
    製品側のUIにユーザーが接した結果として、ユーザーがUX（体験）を享受する。

ユーザビリティとの違い

  • ユーザビリティとの違い

  • 「ユーザビリティ」の拡張された派生が
    「UX」で境界線は曖昧

    • ユーザビリティにも満足度やユーティリティの考え方がある。
    • 機能・性能がどちらに分類されるか？も、曖昧だが評価項目が異なりそう。
    • ただし「ユーザビリティ」が尺度であるのに対し
      「UX」は尺度ではない。
      従って、UXのレベルを議論するためには、別途、評価尺度を用意する必要がある。

  • ユーザビリティから拡張された4つの観点
    （「対象物」「場面」「対象者」「反応」）

観点 ユーザビリティの範囲 UXの範囲
対象物 主に使い易さの内の操作性に関わる要素（機能/性能/UIなど） 加えて、ブランド・イメージ、機能、性能、価格、評判など全体
場面 製品を今まさに操作している「利用中」 興味を持つ「利用前」から、修理や廃棄などの「利用後」まで
対象者 目標を持ってリアルタイムに操作している人 利用前後の人や、隣で見ている人など、対象物と接点を持つ人全般
反応 操作による効果・効率・満足 感情、思考、行動、ライフスタイルの変化などすべて

UXハニカム

（別の切り口）

  • UXを7つの要素でシンプルに説明した概念

  • 中心1要素を外側6要素を満たして実現。

    • 中心1要素：「Valuable 価値がある」
    • 外側6要素：
      「Useful 役に立つ」「Usable 使いやすい」「Desirable 好ましい」
      「Findable 探しやすい」「Accessible アクセスしやすい」「Credible 信頼できる」

Web UXの5階層モデル

（別の切り口）

  • 概念図
階層 Webアプリ（タスク指向） HTML（情報指向）
表層 ビジュアル設計（両者共通） ビジュアル設計（両者共通）
骨格 インターフェイス設計 ナビゲーション設計
骨格 情報設計（両者共通） 情報設計（両者共通）
構造 インタラクション設計 情報アーキテクチャ
要件 機能仕様 コンテンツ要件
戦略 ユーザーニーズ（両者共通） ユーザーニーズ（両者共通）
戦略 サイトの目的（両者共通） サイトの目的（両者共通）
  • 解説
    下層（抽象的）から上層（具体的）に向かって
    「戦略」「要件」「構造」「骨格」「表層」の5つの階層で構成される。
    • 設計プロセス：Webサイトの開発プロセス
      （目的の明確化 → 要件定義 → 構造決定 → ワイヤーフレーム化 → ビジュアル設計）に対応。
    • 普遍的な考え方：提唱者であるJ.J.ギャレット氏のこの概念図は、
      Webだけでなく他の製品やサービスにおいても基礎として応用できる。

UXデザイン

  • 概念
    UI設計に限定されるものではなく、意図したUXを提供するために
    「ユーザー視点」で機能やUIなどを設計すること。

    • 目的：単に「操作画面を描くこと」ではなく
      「ユーザー体験」を意図した通りに提供するための包括的な設計・開発行為。
    • 重要性：ユーザーに受け入れられないリスクを回避するため
      開発の上流から下流まで一貫して「ユーザーの視点」で考える。
    • 実践：プロセス全体を通してユーザーを中心におくアプローチ
      （人間中心設計（HCD））が不可欠。

  • プロセス全体像
    UXデザイン（人間中心設計（HCD）、進め方）は、
    製品開発プロセスと密接に連動している。

    • 計画策定後に以下の4つのステップを繰り返しながら進める。

      1. 利用状況の理解と明示（ユーザーリサーチ・分析）：
        ユーザーリサーチを行い、現状の利用状況、課題、価値観を理解・記述
      2. ユーザー要求事項の明示（目標の定義）：
        調査結果を元に、作り手側が「提供すべきUX」を定義・宣言し、
        ターゲット像や体験を記述。
      3. 設計案の作成：目標達成のための具体的なアイデアを検討し、
        画面UIやサービスなどの形（仕様）に落とし込む。
      4. 設計案の評価：作成した設計案が目標に適合しているかを検証。
        問題がなくなるまでこのプロセスを繰り返す。

    • 各ステップに合わせた最適な手法やツールを活用して設計の完成度を高める。

      1. 観察/フォトダイアリー、インタビュー、インフォーマント・プロフィール、
        現在のジャーニーマップ、...
      2. あるべき姿/目標とするUX、ペルソナ、未来のジャーニーマップ、...
      3. ストーリーボード、UIデザイン、ワイヤーフレーム/画面フロー、
        プロトタイプ作成、...
      4. ペーパー・プロトタイピング、ユーザビリティ・テスト、
        ヒューリスティック評価、アクセスログ、...

※ UXデザインは本質的に「マーケットイン」志向だが、
革新的であれば、「プロダクトアウト」的にもなる。

ユーザビリティ

操作上の扱い易さ。

  • 対象：人間が作った「人工物」の中の「道具」
  • 道具：人が何らかの実用的な目的を達成するために使用する人工物

※ UXの一部であり、歴史的にも先に登場

定義と本質（ユーザビリティ）

  • 定義 (ISO 9241-210:2019/JIS Z 8530:2021による)

    “特定のユーザが特定の利用状況において、 システム、製品又はサービスを利用する際に、
  効果、効率及び満足を伴って特定の目標を達成する度合い”

  • 厳密に言うと、ユーザビリティは、ユーザビリティとユーティリティに分けられる。
    利用に関する価値・便益についての...

    • ユーザビリティ：「機能を簡単かつ快適に使えるか？」マイナス排除
    • ユーティリティ：「優れた手段・機能があるか？」プラス提供

  • 目標達成の度合いを測る3要素
    「（独立したものではなく）依存関係」と「優先順位」がある（以下、優先順位順）。

    • 効果：ユーザーがやりたいことを正確かつ最後までやり遂げられるか（正確性と完全性）。
    • 効率：操作に迷ったり無駄な時間をかけたりせず、スムーズに処理できるか。
    • 満足：操作手順に違和感がなく、ユーザーが満足（納得）できるか。
    • ※例：確信が持てないワンクリックより確信が持てる複数クリックの方が満足度が高まる。

  • 議論に不可欠な3条件

    • 特定のユーザー（誰が使うのか）
    • 特定の目標（何のために使うのか）
    • 特定の状況（どんな場面・環境で使うのか）

石斧の例

破壊や切断という目的を果たすために巨大化・重量化する基調

  • サイズ・重量：人間が普通に持って扱える適度な大きさに調整
  • 素材：持ったときに手が痛くならず、滑りにくくされている。
  • 形状：人間が腕を振り下ろす軌道に合わせ、刃先に最も力が伝わる

利用に関する性質

「使い難い」の2つの性質（9つの事例による分類）

  • 製品スペックの問題：カメラの解像度、バッテリー持ち、通信状況など、
    ユーザーの存在とは無関係に、機能の有無や性能（スペック）として事前に評価できる問題。
  • ユーザー起因の問題：操作が分からない（ボタンが押しづらい、文字が読みづらいなど）、
    ユーザーが実際に操作する中で発生する問題。

※ IT系では、ユーザー起因の問題が増えている。

ユーザーへの負担

（別の切り口）

  • 身体的負担：利用する際の身体的な負担
  • 心理的負担：利用する際の身体的以外の負担
  • 社会的負担：誤操作による損失や、失敗による社会的影響など。

※ IT系では、身体的以外の部分が大きい。

認知とのギャップ

（別の切り口）

ユーザーが製品を操作する際、頭の中では
「気づく → わかる → 操作できる」という認知プロセス（メンタルモデル）が働いている。

  • インタラクションの成立（成功）：作り手が提供したUIと、
    ユーザーの操作イメージが一致していれば、操作はスムーズに成功。
  • 操作のつまずき（失敗）：ギャップがあると、アイコンに気づかない、意味がわからない、
    ボタンが小さくて押せないなどが起きる。

※ 電話の黒電話や受話器のマークは、将来、認知ギャップが発生する可能性がある。

測定要素の重要度の変化

「利用状況」や「経過時間」に応じて目標達成の度合いを測定する要素の重要度が変化する。

  • 利用状況の違いによる変化
    カメラを使用する場合、

    • 動かないもの（風景・食べ物など）の撮影：
      操作に時間をかけても状態が変わらないため、
      時間は目標達成の決定的な要素になりにくい。
    • 動くもの（動物・乗り物など）の撮影：
      もたもたしているとシャッターチャンスを逃すため、
      操作の速さが目標達成の可否に直結する。

  • 経過時間による変化

    • 購入直後：イニシャル作業をいかにスムーズに行えるか？
    • 利用継続時：目標達成は当然となり、作業効率が重要になる。
    • トラブル発生時：トラブルを解決して利用を再開できるか？

ITシステムへの応用

  • 機器のデジタル化に伴うユーザビリティの変遷

    • アナログ機器の特徴とユーザビリティ

      • 特徴：構造がシンプルで単機能
      • 操作性：外観を見ただけで操作方法が容易に想像できる。
      • 配慮：「解剖学的特性（身体的特性）」への配慮が中心。

    • デジタル機器の特徴と課題

      • 特徴：多機能・複合化しており「機能と形状が無関係」になりがち。
      • 課題：外観だけでは、どう操作すればどう動くのかという操作方法が想像し難い。

    • デジタル化による転換点とUI（GUI、CUI）設計の必要性

      • 課題：外観から操作を察することができなくなったため、
        意図的に操作方法がわかる設計（UI設計）が必要不可欠
      • 配慮：「解剖学的特性（身体的特性）」だけでなく
        「認知的特性（理解や判断のしやすさ）」に合っているかが特に重要。

  • インターネット、Webサービス（Webアプリ、Webシステム）の誕生

    • 多数の対人サービスがWebサービスに移行、
      ユーザビリティの向上が強く求められるようになった。
    • ITシステムはアナログ・体験要素が少ないので、
      ≒ マン・マシン・インターフェース（UI、GUI、CUI）になる。

Webユーザビリティ10原則

Webユーザビリティの大家、ヤコブ・ニールセン博士が1995年に提唱したUI設計原則

  • UI系

    • システムの状態を可視化する：見えない裏の動きを表に表す。
    • 実世界とシステムをマッチングさせる：例えばボタンの見た目はボタンと解るように。
    • 一貫性と標準性を保持する：今や、サイト内に限らず、共通認知、一般常識に合わせる。
    • 覚えなくても理解できる設計にする：
      画面をデータメンテにしないで業務フロー的にする、みたいな。
    • 柔軟性と効率性をもたせる：
      メニューやショートカットなど幅広いスキルのユーザーに選択肢を与える。
    • 最小限で無駄のない設計にする：
      機能に優先順位をつける（稀なボタンはサブメニューにするなど）

  • エラー系

    • ユーザに制御の主導権と自由を与える：誤操作を元に戻せる（業務例外的な）。
    • エラーは事前に防ぐ：システム例外、誤操作（ランタイム例外ではなく業務例外）に
      導かない工夫をする。
    • ユーザ自身で認識、診断、回復ができるようにする：
      誤操作が発生したら復帰方法を通知する。

  • その他

    • ヘルプとマニュアルを用意する：その他、FAQ、チュートリアル、使い方ガイドなども。

アクセシビリティ

（元 Wiki でも内容は未記載。）

その他（詳細）

学問領域

人間工学・感性工学・認知心理学：人間の特性をベースに設計を考える、
UXの基礎となる学問領域

人間中心設計（HCD）

人間中心 ≒ ユーザー指向の設計ポリシー。
UXデザインには必要な考え方。

  • スペック重視ではなく、利用者のニーズを中心に据える設計ポリシー（思想）。
  • 「UI/UX」、
    「ユーザビリティ/アクセシビリティ」を
    実践するためのプロセス。
  • 国際規格（ISO）にもなっており、プロセス・手法はUX設計にそのまま適用される。
  • UXのJIS定義には
    「人間中心設計では、インタラクティブシステムの設計に関連する
    ユーザエクスペリエンスだけを管理する。」とある。

ユニバーサル・デザイン（UD）

  • 年齢、性別、国籍、障害の有無にかかわらず
    「最初からすべての人が利用しやすいように設計する」という考え方

  • 7つの原則

    • 原則1 : 誰にでも公平に利用できること
    • 原則2 : 使う上で自由度が高いこと
    • 原則3 : 使い方が簡単ですぐわかること
    • 原則4 : 必要な情報がすぐに理解できること
    • 原則5 : うっかりミスや危険につながらないデザインであること
    • 原則6 : 無理な姿勢をとることなく、少ない力でも楽に使用できること
    • 原則7 : アクセスしやすいスペースと大きさを確保すること

※ AIの公平性・包括性（G検定：試験対策の該当節を参照）にも近い考え方。

カスタマー・エクスペリエンス（CX）

（カスタマー・エクスペリエンス / 顧客体験）

  • 本質的にはUXと大きな違いはない。
  • システムや製品では「ユーザー」だが、サービスで違和感がある場合に「カスタマー」と呼ぶ。
  • 余談だが、設計・開発系では「ユーザー」、企画・営業系では「カスタマー」と呼ぶ事が多い。

進め方

UI/UXデザイン、UIデザインはUXデザインに含まれる。

ユーザ・リサーチ

「作り手が考える」から「ユーザ（インフォーマント）側からヒント」を得る
（顕在 → 潜在、意識 → 無意識、断片 → 文脈）

全体の流れ

利用状況の理解と明示～ユーザー要求事項の明示まで

  • 調査手法：【AS-IS】フォーカス・グループ（グループ・インタビュー）、アンケート、
    【TO-BE】観察、フォトダイアリー、インタビュー
  • 記述手法：【ユーザー像】インフォーマント・プロフィール → ペルソナ、
    【活動・体験による時間経過を伴う変化】現在 → 未来のジャーニーマップ
  • 分析手法：「気づきの抽出」「本質の洞察（インサイト）」
    「あるべき姿（目標とするUX）の定義」

調査手法

  • 観察（行動観察やエスノグラフィーとも呼ばれる）

    • 調査対象者（インフォーマント）とその活動に関する事実を把握するための調査手法
    • 調査者が実際の活動現場に直接出向くことでリアルタイムで詳細な活動状況を把握できる。
    • メリットとデメリット
      • メリット：言葉での意思疎通が難しい対象（例：小さな子供）や、
        無意識の行動も含めた詳細な事実の把握ができる。
      • デメリット：インフォーマントのプライベートな空間に調査者が入り込むため、
        お互いに精神的・物理的な負担が大きい。
    • 実施の際の留意点
      • 自然な活動を妨げない
      • 同意なく個人情報や機密情報を取得しない。

  • フォトダイアリー

    • インフォーマント（対象者）自身に自身の活動を写真日記で記録してもらう情報収集手法。
    • メリットと有効なケース
      直接的な「現場観察」が難しい以下のようなケースにおいて有効な代替手段
      • プライバシー・機密保持：プライベートな空間や、機密情報を扱う職場である場合。
      • 物理的・コスト的制約：調査現場が遠隔地にある、または調査対象の数が多すぎる場合。
    • デメリットとその補完策
      • 本人が記録した内容に限られるため、直接観察より情報量は落ちる。
      • インタビューのきっかけとして活用し、詳しく深掘りすることでカバーできる。
    • 実施上の留意点と工夫
      インフォーマントの記入負担が大きいため、モチベーション低下を防ぐ対策が必要
      • 記録内容や写真の撮り方を事前にわかりやすく説明し、
        質問に答えられるサポート体制を整える。
      • 提出のハードルを下げるため、
        「LINEで写真を撮って文章と送ってもらう」などの気軽な方法を取り入れる。
      • 多少内容が期待と異なっても、まずは期限までに提出してもらうことを最優先とする。

  • インタビュー
    ユーザーリサーチの一環として「事実の把握」と「その背景（内面や価値観）の理解」の
    ために行う情報収集手法。観察やフォトダイアリーと組み合わせる。

    • 主な特徴と手法

      • 1対1の実施：活動の背景を深掘りするため、フォーカスグループではなく
        1名のインフォーマント（対象者）に対して行う。
      • 半構造化インタビューの採用：事前に質問を用意しつつ、
        対話の中で見つけた新たな問いを重ねていく手法。
      • 「個人の本音」の追求：一般論ではなく、
        言いづらいような対象者個人の本音やこだわりを聞き出すことが重要。

    • 4つのポイント

      • インフォーマントに多く話してもらう：インタビュアーの発言は最小限に留め、
        相手が主体的に話す環境を作る。
      • オープンクエスチョン：「はい/いいえ」で終わる質問ではなく、
        「どう感じたか」を問い、自身の言葉で語ってもらう。
      • 「弟子入り」の態度で臨む：相手の活動や考えに関心と共感を示し、
        教えを乞う（弟子のような）姿勢をとる。
      • 活動の「文脈」に着目する：空間的な広がりと、時間的な変化の双方を捉え、
        活動の文脈を深く理解する。

入力資料の作成

  • 人に関する情報を「インフォーマント・プロフィール」、
    活動に関する情報は「現在のジャーニーマップ」として作成

  • その後の分析作業の基礎となるだけでなく、判断に迷った際、
    原点に立ち返って確認するためのベース資料となる。

  • インフォーマント・プロフィール

    • インフォーマント（調査対象者）ごとに、その属性や基本的特徴をまとめた
      ドキュメントで、参加人数分を作成。
    • 基本プロフィールのほか、特徴的な活動、達成したいゴール、価値観、関係する人などを
      記述して個性を表現。

  • 現在のジャーニーマップ

    • 概要と特徴

      • 定義：一連の人の活動体験を「旅」に見立てて時系列でまとめ、
        行動や感情の変化を可視化したもの。
      • 目的：システム、製品又はサービスなど、
        複数のタッチポイントが絡む体験の全体像の表現。
      • 現在のマップ：観察、フォトダイアリー、インタビュー等から得た
        今の活動体験をまとめたもの。

    • 構成要素と記述内容

      • 時系列の記述：横軸は時間経過、縦軸は活動内容、場所、利用した道具・情報、
        関係者、その時の気持ちや嗜好など。
      • 視覚的要素：フォトダイアリー等から入手した写真もあわせて貼り付ける。

分析手法

  • 気づきの抽出：事実に基づいてインフォーマントの特徴的な活動や思考を記述、
    この段階では調査者の主観的な解釈を入れないことが鉄則。

    • 位置づけ：調査データ（プロフィールやジャーニーマップ）から
      「インサイト（洞察）」を得るための前段階として行う情報の整理・取捨選択の作業。
    • 基本方針：調査者の解釈や想像は極力加えず、徹底して「事実に基づいた発見」を書き出す。
    • 性質：正解・不正解の定義はなく、調査者によって異なる。
      チーム全体で多様な視点を出し合い気づきを得る。

  • 本質の洞察（インサイト）：事実に基づいた「気付き」から主観的に解釈
    （本質的な価値観、意識、ルール、パターン、法則性などの「上位概念」を発見）。

    • 言葉による言語化: 関連する気付きをグループ分けして上位概念を
      「〜という意識が、〜という活動を生み出している」といった表現で表す。
    • 関係性の図解（視覚化）: 順序・因果関係、座標プロット、ベン図、グラフなどを用いて
      要素間の関係性や価値観の構造を描く。

  • 「あるべき姿（目標とするUX）」の定義：インサイトを基に
    「どのような人が、どのような活動体験ができるか」の形式で定義し、
    自他環境を考慮して絞り込む。

    • 概要：インサイトを基に、作り手が提供すべき理想の体験を考え、開発目標として定義。
    • 形式：「どのような人が、どのような活動体験ができる」 という形式で端的に宣言。
    • 役割： 仕様検討が始まった後、機能やUIなどを判断する際の重要な指標となる。
    • 視点：「実現手段」（はあるか？）「ユーザ」（とズレていないか？）
      「技術」（的問題はないか？）「ビジネス」（として成立するか？）

出力資料の作成

  • ペルソナ

    • 概要と目的

      • 定義：目標とするUX（あるべき姿）のうち、
        「どのような人（ターゲットユーザー）」の部分をモデル化
      • 目的：開発に関わるメンバー間で「提供相手が誰か」の認識を共有し、
        検討中のアイデアや操作性がターゲットに適合しているかを判断する拠りどころにする。

    • 作成のポイント

      • 具体性と本質：曖昧な平均像ではなく、達成したいゴールや価値観を含む
        具体的で特徴のある人物像にする。ただし、無関係な要素を細かく書きすぎない。
      • 合意形成の重要性：正解はないので関係者間で合意が取れていることが重要。
        違和感が生じた場合は運用中であっても適宜修正して合意を取り直すべき。

  • 未来のジャーニーマップ
    仕様検討などの場面で判断のよりどころとなる
    「作り手が提供しようとしているあるべき姿（UX）」を時系列で可視化したもの。

    • 目標と作成時の注意点

      • 目的：目指すべき体験活動の具体的イメージを関係者間で共有し、
        その妥当性をチェック・修正するために用いる。
      • 作成方法: 現在のジャーニーマップやユーザーリサーチ結果を参考に、
        矛盾のない自然な体験をマップ化する。
      • 注意点：リサーチ結果がない状態で作成する（≒仕様書になる）こともあるが、
        「作り手に都合のよいマップ」にならないようにする。

    • エモーショナルカーブの活用

      • 時系列に沿ったユーザーの感情の波（快適・不満など）を曲線で表現。
      • 上げ、下げ、プラマイ・ゼロなど。
        体験価値の妥当性を検討・工夫する重要な視点として活用。

プロトタイピング/UIデザイン

  • 位置付けと役割

    • 抽象から具体への移行：目標とするUXが決まった後、本格的な開発に入る前に、
      具体的な仕様を少しずつ試しながら検討。
      この段階における具現化が主にUIデザインと呼ばれる。
    • 開発コストの削減：本格的な開発が始まると仕様変更のコストが高くなるため、
      その前に「作って評価する」サイクルを繰り返し、
      低コストで最適な仕様を見出すことが目的です。

  • プロトタイプ（試作）の基本的な考え方

    • UX再現が最優先：最も重要なのは、ユーザーの体験を部分的または全体的に再現すること。
    • 仕組みの再現は不要：体験さえ再現できれば、
      プロトタイプは最終成果物と同じ仕組・構造である必要はない。
    • スピードと効率の重視：簡単に作ったもので検証を繰り返す。
      検証したい要素ごとに別々のプロトタイプを作る。

プロトタイプ

  • 画面・UI

    • 一般的な手法

      • ペーパー・プロトタイプ：最も簡易的。
        ワイヤーフレームを紙芝居のように提示してテスト。
      • プロトタイピング・ツール：最近の主流。
        パソコン上で質の高いシミュレーションを作成できる。

    • 定義と現実
      画面・UIプロトタイプで、以下の3つの違いは曖昧。
      重要なのは定義ではなく「目的によってどの要素の再現性を高め、どこを省略するか」

      • ワイヤーフレーム：UI構造検討（インタラクションなし）
      • プロトタイプ：ユーザビリティ検証（インタラクションあり）
      • モックアップ：ビジュアル検討（見た目重視、インタラクションなし）

  • ハードウェア製品

    • 重要性：形状変更が困難なため、早い段階での十分な検討が不可欠。
    • 特徴：設計要素が多岐にわたるため、体験要素の検証目的毎に別々に作る。
    • 見た目・雰囲気：スケッチ、CG、VR/AR、モックアップなどを活用。
    • モックアップ
      • 寸法・形状：紙や木、粘土、3Dプリンターで、1/nスケール～実物大で作成。
      • 重量感・疲労度：実寸形状の中に重りを入れ、重さや重心を本物に合わせる。
      • 機能試作：機能のみを再現して検証。外見や大きさは不問。

  • サービス商品

    • 特徴：基本に立ち返り「簡易的に体験して検証する方法」を考える。
    • 手法：ロールプレイングでサービス利用場面を再現し、改善点を見つける。
      心理状態や雰囲気をリアルに再現すると効果的。

UIデザイン

ユーザビリティ上の深刻な問題の多くはUIの基本構造に起因するので、UXデザインでもある。
問題の影響度、後工程からの手戻り工数が大きいため、
画面・UIプロトタイピング中のUIデザインで徹底的に検証する。

  • ペーパー・プロトタイピング：
    画面フローとワイヤーフレームで紙芝居をし、基本構造を決めてから詳細を作り込む。

    • ツール

      • 画面フロー：画面遷移を矢印などで図式化したもの。
      • ワイヤーフレーム
        ・画面内の要素（ボタンや表示エリアなど）のレイアウトを簡単な線画で示したもの。
        ・手書きやPowerPoint、UIデザイン・ツールなどを用いて、
        　細部にこだわらずスピーディに描くことが重要。

    • プロセス
      画面フローからワイヤーフレームの順、あるいはそれらを行き来しながら進める。

      • 画面フローの検討プロセス
        ・タスク（機能・サービス）の全体像を把握
        ・ユーザーの目的を洗い出し、メニュー構造へ分類・整理
        ・操作の順序とステップ（画面数）を考える
        ・イレギュラーへの対応（操作のやり直しや別行動）も考慮

      • ワイヤーフレームの検討プロセス
        ・画面に必要なUI要素の洗い出しとグループ化
        ・レイアウトの配置（重要度、操作順、視線移動を考慮）
        ・情報量のコントロール（非表示、ポップアップ、複数画面に分ける）

  • 製品全体での一貫性（ルールの策定）

    • 製品全体で、タスク・画面毎の挙動やレイアウトがバラバラにならないようにする。
    • 共通ルールを決め一貫性を持たせる「どの画面からもホームに戻れる」「ロゴは左上」

  • ツール（プロトタイピング・ツール、UIデザイン・ツール）

    • 画面上でワイヤーフレームを描き、画面遷移を指定することで、
      ペーパー・プロトタイピングできるソフトウェア（Web提供が主流）。

    • 完成品レベルのビジュアルまで作り込めるため、
      ペーパー・プロトタイピングよりもリアルな疑似体験ができる。

    • 主な共通機能

      • テンプレート・パーツの再利用：枠やOS標準のパーツが用意されており、
        自作パーツの登録・再利用も可能。
      • 画面遷移の指定：画面同士を「線」でつなぐだけで遷移を指定できる。
      • インタラクションの再現：タップ、ダブルタップやフリック、
        オーバーレイやアニメーションも設定可能。
      • マルチデバイスでのプレビュー：PCや実機（スマホ・タブレット）で動作を確認でき、
        実機では実際のタッチ操作で操作感を検証できる。
      • コラボレーション機能：複数人での共同編集や、
        コメント機能による進捗確認・フィードバックが可能。

    • 代表的なツール「Figma」での操作例

      • 登録済みのパーツをドラッグ＆ドロップして配置
      • ボタンから遷移先画面へ矢印（線）を引くことで、
        簡単に画面遷移やアニメーションを設定
      • プレビュー画面で縦横のスクロールやタップによる画面遷移など、
        実機さながらの挙動を確認

    • ツールのリンク集

UIデザインの基本ルール

  • 人間の特性や過去のノウハウに基づく「基本ルール」に沿うことで、
    効率的に問題の少ないUIを作ることができる。
  • ただし、それだけで優れたユーザビリティが保証されるわけではないため、
    最終的なユーザビリティ評価は必要
  • デザインガイドライン（OSメーカーが公開しているもの）や、
    デザインルール解説書籍などを活用する。

レイアウト

  • 情報量の制限

    • 情報量を増やしすぎない配慮：人間の短期記憶には限界があるため、
      一度に提示する情報量を抑える。
    • 短期記憶の限界：「マジカルナンバー7±2」
      人間が一度に処理・記憶できる情報の塊（チャンク）は5〜9個程度（7±2個）
    • デザインへの応用：ユーザーの許容量を超えない適切な情報量を都度検討して
      デザイン（ワイヤーフレーム等）に落とし込む。

  • 視線移動に配慮
    UI配置の主な考え方は、横書きの操作画面でユーザーの視線は
    「左上から右下」へ移動する事を前提にしている。

    • 配置の3つのアプローチ

      • 操作手順に合わせる：最初に押すボタンを左上に、完了ボタンを右下に配置
      • 優先順位に合わせる：使用頻度の高い機能やおすすめコンテンツなど、
        重要なものを上部や左側に配置
      • 階層構造に合わせる：メニューやカテゴリー（上位）を上・左に、
        具体的なコンテンツ（下位）を下・右に配置

    • 代表的なレイアウト例

      • 左上のロゴ配置：多くのサイトで左上に企業ロゴ（ホームへのリンク）を配置。
      • F型レイアウト：Webサイトでは画面の上部と左側にツールバーやメニューを並べ、
        視線を「上から下」「左から右」へ誘導。
      • 右上のメニュー配置：スマホサイトでは、
        右上にハンバーガーメニューやメニューボタンが配置される。

  • ゾーニング（エリア分け）
    意味の近いものごとにエリアを分けて配置するデザイン手法で、
    画面構成の意味がユーザーに伝わりやすくなり、操作を覚えやすくなる。

    • 例：エアコンのリモコン
      基板の物理的な制約がある中で、機能の共通性や操作の連動性を考慮して配置されている。

      • 温度調節：上下ボタンと液晶の数字（表示）を近接させ、連動を意識させている。
      • 風に関する機能：風量調節・風向・スイングなど、
        風に関するボタンと表示を右側に集約。
      • メンテナンス機能：使用頻度が低いため、空きスペース（左右）に配置。
      • タイマー機能：下端に配置。端のエリアは視認性が高いため、
        一定の頻度で使う機能として悪くない配置。

    • 例：ウェブサイト
      役割ごとに画面上の配置エリアが明確に固定されている。

      • 上部（ツールバー）： 全ページで共通して使う機能のゾーン。
      • 左側（メニュー）： コンテンツ切り替え機能、および下部に設定・ユーザー支援系を配置。
      • 右側（メインスペース）： コンテンツ表示ゾーン（上部がメイン、下部が補足情報）。

手がかり

  • アフォーダンスとシグニファイア
    ユーザーがモノを直感的に操作できるようにするための重要な概念

    • アフォーダンス：モノが人に提供する「行動の可能性」
      （椅子なら座れる、梯子なら登れる）

    • シグニファイア：ユーザーに「どう行動すればよいか」を伝える手がかりやサイン。

    • ドアの取っ手の例

      • パイプ形状: 手で握れるため「引く」動作を促す。
      • プレート形状: 面があるため「押す」動作を促す。

    • 画面UIのデザイン変遷と課題

      • スキューモーフィック・デザイン（過去）: 実際のボタンのようなリアルな凹凸
        （出っ張り）を再現していたため、
        「押す」という操作を直感的に誘導（アフォード）しやすかった。
      • フラット・デザイン（現在）: トレンドである反面、出っ張りの表現がないため
        「押す」という誘導（アフォード）が弱まり、ボタンだと気づかれにくい問題が生じている。

  • フィードバック

    • 定義と効果：ユーザーの操作に対するシステムからの反応。
      これによりユーザーは操作の正しさを確信し、安心感を得られる。
    • 必要性: 内部処理は見えないため、
      UIの一部として意図的にフィードバックをデザインする必要がある。
    • 具体例：ボタンがマウスオーバーで変色し、クリックで凹む。
      ゴミ箱アイコンの変化（状態表示の兼任）。
    • 多角化：視覚（見た目）にとどまらず、カメラのシャッター音、ボタンの押し心地、
      スマホの振動などもある。

  • メタファー
    機能を「何かに例える表現手段」のこと。
    身近なものに例えることで、直感的に操作できるようになった。
    GUIの登場により、一般へ広く普及した。

    • デスクトップメタファー：パソコンの基本画面を「書斎の机（デスクトップ）」に、
      アイコンと操作を「ゴミ箱」、「フォルダー」に置き換えたもの。
    • 画材・文房具のメタファー：グラフィックソフトにおいて、
      鉛筆や筆、消しゴムなどのアイコンでツールの機能を例え、
      筆箱から文房具を取り出す様子に例えたもの。
    • ボタンのメタファー：本質的にはコマンド実行やパラメタの切り替えに過ぎない操作を、
      ボタン押下にすることで、ユーザーが簡単に直感的に操作できるようになった。

  • 強調表現

    • 特徴

      • 重要性: 通知や警告など、システムとユーザーの双方にとって
        重要な局面に多く使われる。
      • 異質性: 意識していないユーザーに気付きを促すという、使い易さとは逆のアプローチ

    • 目的
      特定の要素を目立たせるために使われ、主に4つの目的がある。

      • 意味の違いの表現：選択中のタブの色変更や、カレンダーの休日・予定日の色分け。
      • システムからの通知：メッセージ受信などを知らせるアイコンへの「バッジ」の追加。
      • 重要な判断の促進・警告：データ削除時のメッセージ表示や、
        注意を要するボタンの色変更。
      • 要素への視線誘導：バナー広告など、ユーザーの目を引くための表現。

操作手順

  • 画面フロー

    • 基本ルールは、ユーザーの「自然な思考順序」に合わせること。
    • ただし、何が自然かは、サービスやユーザー像によって異なる。
      • 例えば、JR東日本の指定席券売機では
        「特急券の指定（駅・日時など） → 列車選択 → 座席選択 → 乗車券の要否選択 → 支払い」
        というフローが採用されている。
      • しかし、次の思考順序やニーズも考えられる
        「乗車券を先、特急券を後」（一部を特急区間にしたい）
        「座席選択を先、列車選択を後」（コンセントのある座席）

  • オブジェクト指向UI（OOUI）

    • 設計思想
      • タスク指向UI：ユーザーが「処理（タスク）」を先に選択し、
        その後に「操作対象（オブジェクト）」を指定する設計思想。
      • オブジェクト指向UI：ユーザーが「操作対象（オブジェクト）」を先に選択し、
        その後に「処理（タスク）」を指定する設計思想。
    • 現在主流
      • 通常の「タスク指向UI」と比べ、モードレス（思考を分断しない）と言うメリットがある。
      • メタファーとの相性もあり、現在、GUIアプリの多くは、
        このオブジェクト指向UIが主流。

記憶負担

  • 一貫性
    「記憶負担」を軽減する核心的なアプローチ

    • 一貫性の定義と効果

      • 定義：異なる場面や製品でも、共通の操作作法を提供
      • 効果：初めて使う機能やアプリでも、過去の経験から操作方法を類推できる。

    • 範囲とUI要素

      • 範囲：1つの製品内、OS共通、ブランド内、業界全体などのレベルがある。
      • UI要素：用語、色、形、大きさ、配置、操作手順などを共通化する。

    • 「緩い一貫性」の有効性
      必ずしも「完全一致」である必要はない。

      • 用語のカタカナ表記と英語表記（どちらでも連想可能）
      • RGB値が完全に一致していなくても同系色なら連想可能
      • 「SHIFTキーでの複数・範囲選択」のような「緩い一貫性」

    • 具体例と標準化

      • アプリのメニューバー：「ファイル」「編集」、
        「編集」中の「コピー＆ペースト」の並びの共通化。
      • 規格化とデファクトスタンダード：
        異なるメーカーのプリンターのスタートキーが緑色で同じマーク

  • 再認型メニューと再生型メニュー

    • 再認型（再確認する）： 正確に記憶していなくても状況に応じた選択肢が提示され、
      その中からコマンドを選ぶ方式。
    • 再生型（再入力する）： 従来のCUI（テキスト入力）のように、
      大量のコマンドを文法やスペルまで正確に記憶し、0から打ち込む必要がある方式。
    • スマホのマルチタッチ操作（ジェスチャー）や、音声対話型UI、
      AIへのプロンプト入力などは、再認型ではなく負担増加になっている側面がある。

その他（基本ルール）

  • 寛容性とユーザー主体性に関する要約
    「ユーザー主体性」を持たせるUI設計：製品にコントロールされているのではなく
    自分が主導権を握っている感覚を持たせる。

    • 基本的にユーザーがアクションを起こさない限りシステム側からは処理を開始しない
      （例外: 通知や警告のダイアログなど）
    • ユーザーは日常的に操作ミスや作業中断を行う。
      これらに対応できる「寛容性」が必要（UNDOや一時保存）。
    • 今後、AIや自律型ロボット（ドローンなど）が普及すると、
      インタラクション（相互作用）の設計が今後の大きな課題となる。

  • 習熟への対応
    長く使い続けるユーザーの習熟に合わせた「効率性」への配慮も重要

    • 代表例がキーボードショートカット、右クリック、
      ダブルクリックなどのショートカット機能。
    • 初心者向けの標準的なアクセス方法を担保した上で、
      習熟者向けのショートカットなどを追加する。

  • 安全性に基づく設計ルール

    • フールプルーフ（馬鹿よけ）：人間はミスをするという前提に基づき、
      誤操作による危険をあらかじめ防ぐ設計思想
    • 具体例：電子レンジの扉を閉めないと加熱機能がオンにならない。
      電源ケーブルを抜かないとメモリースロットのカバーを開けるボタンが押せない。
    • UI応用：入力チェック系全般。また、GitHubの「Danger Zone（危険な地帯）」に
      以下のような強力なフールプルーフが組み込まれている。
      • 文字列の強制手入力（タイピング・バリデーション）
      • 段階的なモーダルウィンドウ（多段階の警告）
      • ボタンの意図的な非活性化（Disabled）と「赤色」の配色
      • パスワードや2要素認証（2FA）の再要求

  • 解剖学的特性に基づく設計ルール

    • 形状、寸法、関節の可動範囲などの目に見える要素だけでなく、
      体重、強度、筋力などの目に見えない要素も含まれる。

    • 設計データの入手方法：書籍やネットから人体寸法の統計データを購入できるが、
      特殊なデータが必要な場合は独自に測定を行う。

    • ハードウェア設計における重要性

      • 操作部の高さやスペース、ハンドルの大きさなどは人体寸法に基づいて決定される。
      • 操作や保持に必要な力は、人間の筋力や筋肉への負担を考慮して決める必要がある。

    • ソフトウェアUIにおける影響

      • タッチパネルのボタンサイズや間隔など、
        物理的操作を伴う部分には指の寸法（解剖学的特性）が関係する。
      • OSメーカー（Apple、Microsoft、Google等）が標準UI部品を提供しているため、
        アプリ開発者がこれを直接意識する機会は少ない。

  • 言葉・用語のルール

    • 平易な言葉の選択：専門用語やアルファベット略語、カタカナ英語は極力避け、
      ユーザーの知識レベルを常に意識して日常的な言葉を使う。
    • 二重否定の回避：「不要なファイル以外は削除しない」
      「"プリント中止"に対する"キャンセル"ボタン」などは混乱を招くため避ける。
    • 明確な主語の提示：「ファイルを閉じます」は、
      システムとユーザーのどちらが操作を行うべきか誤解が生じるため、
      行動の主体を明確にする。

ユーザビリティ・テスト

UIのテストで、UXも含むため、UXテストでもある。

概要（ユーザビリティ・テスト）

  • 目的

    • 目的と評価対象：設計したアイデアが目標とするUXを実現できているかを
      検証するための評価手法。操作のスムーズさだけでなく、目標とするUX全体を評価。
    • 開発プロセスにおける意義：プロトタイピングの一環として検証と改善を繰り返すことで、
      製品やサービスの品質を高め、目標とするUXへと近づけていく。
    • 品質のコントロール（歯止め）：一定の品質基準を設けることで、
      問題のある製品のリリースを防ぐ
      （特に修正が困難なハードウェア製品においては重要な歯止め）
    • 実施のポイント：体験を評価するという視点を持ち、
      実際のユーザーの体験を可能な限りシミュレートして検証を行うことが望ましいとされている。

  • 手法
    被験者に特定のタスクを与えて製品を操作してもらい、
    その際の言動（思考の発話など）を観察・分析して問題点を発見する定性評価手法。

    • 実施方法

      • インタラクション評価 (タスクあり）：被験者には、
        考えていることを口に出す「思考発話」をしながら操作してもらう。
      • インタビュー：適宜インタビューを組み合わせることで、
        ユーザーの気持ちや意見を把握する。

    • メリット・デメリット

      • メリット：課題の発見だけでなくその原因も推測し易く、
        インタビューを交えることでユーザーの気持ちや意見も含めた総合的な評価が可能
      • デメリット：テストの準備や分析に手間がかかる（簡易手法もある）。
        定量的な議論には向かない。

  • 効果・効用

    • ユーザー参加型製品開発の実現：
      ユーザー参加により間接的に人間中心設計（HCD）を実現できる。

    • 評価技術

      • 実際の使用状況に近い客観的事実や操作プロセスを直接観察できるため、
        評価精度が高く、具体的で適切な改善に繋がり易い。
      • その場でインタビューを行うことで被験者の主観的な印象も確認でき、
        開発の判断材料となる多様な情報を多く入手できる。

    • 啓蒙効果

      • ユーザからの評価でユーザビリティへの意識が大きく向上
        （開発者のテスト見学が推奨される）
      • 開発者が「ユーザーがうまく操作できない場面」を直接目撃することで、
        開発者側の思い込みが覆る。

体系

  • ユーザビリティ・テスト：被験者を使った評価

    • 観察：直接的に観察するため情報量と信頼性の観点から主軸

      • インタラクション評価 (タスクなし）：自由操作
      • インタラクション評価 (タスクあり）：一般的★
      • パフォーマンス評価：タスクの成否を定量的（やや異質）に測定・評価
      • 操作ログ分析：間接的にユーザーの行動を検証

    • 質問：間接的に主観的な意見を聴く方法のため補足的

      • インタビュー：対面で質問（タスク有り評価と組み合わせるのが一般的★）
      • 主観評価：アンケート用紙を用いて主観評価を回収する。

  • ヒューリスティック評価(専門家による評価)：被験者を使わないため精度は下がる。

    • 仕様のチェック：一般的な要件を満たしているか確認する。
    • 認知的ウォークスルー：専門家が実際に操作し、
      ユーザーがつまずきそうな部分を発見する。

実施（ユーザビリティ・テスト）

後の分析作業で「改善のアイデア」につなげるための情報収集活動で
「質の高い情報をなるべく多く収集する」工夫が必要。

  • 評価計画書の作成

    • 目的

      • ミスなくスムーズに準備・進行できるよう、計画書を作成し最新の状態に保つ。
      • 関係者との事前共有：開発者とあらかじめ計画を共有しておく。

    • 内容

      • 背景・目的・目標：実施理由を明確にする。
      • 評価対象と範囲：実機・プロトタイプ、対象とする機能の範囲。
      • 評価方法：テストやインタビューの手法、特定の測定基準
      • 被験者情報とタスク：被験者の人数・条件、タスク・アンケート内容。
      • 実施場所と環境：テスト会場のレイアウトや機材の配線図など。
      • スケジュール：プロジェクト全体と評価計画～実施の工程、当日のタイムテーブル。
      • 納品物：報告書やテストのエビデンス（録画動画・アンケート用紙）
      • 役割分担：進行係、記録係、会場・製品の確保担当など、関係者の役割。

  • タスク指示書の作成

    • 目的

      • 被験者にタスクの「目的やゴール」を理解させる。
      • タスクの与え方を均一にし、被験者ごとの理解のばらつきを防ぐ。

    • 原則と注意点

      • ヒントの排除：操作手順や機能名称は、
        画面上のボタン名と同じ表現にならないようにする。
      • ストーリー性：被験者を主人公にしたストーリーを設定
        （各タスクが繋がっていると、より効果的）
      • 明確な指示：ゴールだけでなく、やってほしい操作・やってほしくない操作、
        テスト上の注意事項も伝える。

  • 被験者リクルーティング

    • 適切な被験者数：コスパ的に5〜6名が目安とされている。

    • ポイント

      • テスト結果への影響大：ユーザビリティテストの成否は、
        適切なプロフィールを持つ被験者を選べるかどうかにかかっている。
      • 一般ユーザーこそが典型：「軽い気持ちで参加する人」（弱いステークホルダー）こそが、
        リアルなユーザー像。
      • 外注の検討：複雑な条件や人数の厳密なコントロールが必要な
        本格的なリクルーティングは専門会社へ委託するのが合理的。

    • 条件の決め方

      • 基本的には「想定ユーザーと同等の特性・知識・機器使用経験を持つ人」をベースに、
        特定のタイプに偏らないよう幅広く集めます。
      • 基本属性・経験：年齢、性別、機器・サービスの所有や使用経験、
        評価目的に応じた知識やスキル、ライフスタイルなど。
      • 製品への習熟度：原則として、問題を発見しやすくするために
        「製品やサービスに詳しくない人」を採用
      • 妥協条件とNG条件: 理想通りの人が見つからない場合の「緩和条件」や
        競合メーカー関係者などを排除など

  • 会場準備

    • 会場要件

      • 基本インフラの確保：評価対象製品が確実に動作する環境
        （電源、Wi-Fi、必要に応じた水道・ガスなど）。
      • 確実な観察と記録：被験者の言動を克明に観察・録画できる機材と、
        そのための電源や配線スペース。
      • 被験者への配慮：観察者を意識せず落ち着いて取り組める設備、
        同伴者・早着者のための待合室。
      • 評価者間の連携：進行係と記録係が、被験者に気づかれずに連絡を取り合えること。

    • テストラボ
      防音された「テスト室」と「観察室」の2部屋で構成

      • 視覚・音響の分離
        ・ハーフミラーやカメラを設置し、被験者に意識させずに観察室から様子を確認
        ・防音対策により、観察室側の会話が被験者に聞こえないようにする。

      • 柔軟性と機材の充実
        ・様々な製品や評価方法に対応できるよう内装を容易に変更できる仕様
        ・映像機材や音響機器を一定水準で備えている。

    • スタッフ
      テストを円滑に運営し、質の高い情報を得るための役割分担。

      • 進行係（モデレーター）：直接被験者と接してテストを円滑に推進する重要な役割であり、
        主に以下の業務や配慮を行う。
        ・タスクの提示と理解の促進、リラックスできる雰囲気づくりと状態の観察、
        　発話の促進、行き詰まった場合の助言とインタビュー
        ・インタビュー時、指示は「～してください」、質問は「～ですか」と、
        　指示・質問であることを明確にする。
        ・インタビューは問題の「真の原因」につながる情報を引き出すため
        　必要に応じて繰り返し深く質問する。

      • 記録係：被験者の言動を記録
        ・役割と体制：テスト中の被験者の操作状況を記録、
        　分析者と記録係は同一人物が望ましい。
        　観察室から進行係への連絡手段を準備しておく。
        ・記録内容：製品の状態と被験者の行動、観察者自身の気づき、
        　推測される心理状態、被験者の発言、進行係の助言や質問、進行係への回答
        ・工夫：正しい手順、スムーズな操作は丸、同じ操作の繰り返しは「1、2」、
        　情報の色分け（助言/インタビュー/問題点）

      • 撮影係・機材担当：機材操作、トラブルに対応する。
        ・役割：被験者の状況がよく分かる映像を観察室へ提供する。
        　固定カメラで十分でない場合、フォーカスさせる必要がある。
        ・ポイント：手元だけでなく視線、操作部分を同時に捉える。
        　重要な部位にフォーカスするがヒントにならないように後追いする。

      • 被験者受付担当：当日の受付、案内、連絡を行う。

      • 被験者：テストに必要不可欠な存在。

  • 簡易手法
    本格的な設備の準備に手間がかかるので、会議室とスマホ1台で実施できる手法

    • 会場と観察の工夫

      • 会場：機密保持と被験者のリラックスのため、
        周りから隔てられた「会議室などの個室」を確保する。

      • 観察:
        ・リアルタイム観察が必要ない：被験者のストレス軽減と機材削減のため
        　「リアルタイム観察なし（後日録画確認）」が理想。
        ・リアルタイム観察が必要：観察者を1名に絞る、パーティションで仕切る、
        　観察用モニター越しに観察する。

    • スマホによる撮影・録音

      • 基本体制：スマホを三脚で固定し、
        進行係が録画操作を兼任することでスタッフ数を減らす。
      • 注意点：長時間の撮影になるため、
        ACアダプターの接続とメモリ空き容量の確保が必須。
      • 推奨工夫：アダプター経由で外部モニターにHDMI出力すると、
        観察しやすさが大幅に向上。

テスト結果の分析

概要（テスト結果の分析）

  • 分析に使用する材料（収集データ）

    • 事前情報：評価対象製品の仕様、被験者の属性
    • テスト中の記録：ビデオ映像、行動・発話の記録、
      インタビューの回答内容、タスク達成度
    • アンケート：主観評価アンケートの回答結果

  • 分析・報告のプロセス

    • 問題箇所の特定とリスト化

      • 問題リストを作成：行動・発話記録やインタビュー結果を基に
        問題箇所を特定しリストにまとめる。
      • 詳細分析シートの作成：リスト化した各問題について、
        問題、原因、改善案を分析しシートにまとめる。
      • 集計と報告書の作成：タスク達成度や主観評価アンケートの平均値などを集計し、
        分析結果をまとめた「報告書」を作成

    • 報告後の流れ（開発側の対応）
      開発者は報告書を受け取った後、以下の対応を行う。

      • 開発側の事情を考慮した上で改めて改良方針を立て、
        修正箇所に対する具体的な改良を実行。
      • 一部の問題は次回のバージョンアップやモデルチェンジのタイミングまで
        見送られることもある。

実施（テスト結果の分析）

  • 問題（特定とリスト化）

    • ポイント

      • 主観より客観（行動）を優先：被験者の主観よりも、
        実際に発生した「つまずき」という客観的事実を優先。
      • 取り上げるべきかの判断基準：他者も同様につまずいているか。製品に原因があるか。
      • 問題の切り分けと統合：基本は1つの問題に複数を混在させず、個別の問題に分割するが、
        発生箇所が異なっても原因が共通している場合は1つの問題として扱う。

    • 問題リストの作成

      • 発見された問題の一覧を表にまとめる（タスクや被験者の情報も記載）。
      • 並び順はタスク順、重要度順などがあるが、タスク順が分かりやすい。
      • 複数のタスクで共通する問題は、最終的に1つにまとめる。

  • 原因（分析プロセス）

    • 分析手順

      • 状況の確認：問題周辺の行動・発話、インタビュー内容、製品の動きを詳細に確認
      • 思考の推測：被験者が思い描いていたイメージ（メンタルモデル）を推測する。
      • ギャップの特定：ユーザーの思考と合致しない「製品の仕様」を探し、想定原因とする。

    • ポイント

      • 「原因」と「結果」（≒ 問題）を混同しない：
        「製品の仕様」と「ユーザーのつまずき」
      • ユーザー側は「原因」としない：コントロールできる製品側が「原因」で、
        できないユーザー側は「結果」とする。
      • 想定原因はあえて複数挙げる：原因を1つに絞り込まず、
        多様な可能性（原因A、原因Bなど）を示しておく。

  • 改良案（検討ポイント3点）

    • 基本アプローチ：「逆の仕様」にすることが、改良への基本路線
      （小さい→大きく、専門用語→一般用語、長い→短く、自由→選択肢）
    • 多様な案の提示：効果のレベル（抜本的〜対症療法的）や、
      開発規模（大規模〜小規模）が異なる多様な案を出しておく。
    • 方向性の提示に集中する：設計開発を伴う具体的な改良方法ではなく、
      評価者として改良の方向性を示す。選択肢を広げておく。

  • 詳細分析シート

    • 体裁

      • 内容：1シート1問題、問題内容（つまずきの状況）、想定原因、改良の方向性。
      • 書式：厳密な決まりはなく、重要問題のみに絞ったり、
        リスト形式にしたりと簡略化も可能。
      • 役割：単なる「報告書」にとどまらず、
        設計改善のための「提案書」「指示書」としての意味合いを持つ。

    • ポイント
      改良の意思決定に供されるため、

      • 端的なタイトル：タイトルを読むだけで、
        ユーザーがどう困っているかの状況が把握できること。
      • 具体的な状況描写：テストを直接見ていない人でも、
        被験者のつまずきが目に浮かぶように書くこと。
      • 論理的なつながり：「問題内容 → 想定原因 → 改良の方向性」の流れに
        筋が通っていること。
      • 多様なアイデア：想定原因や改良の方向性を整理して複数出すことで、
        修正の選択肢を増やす。

  • 報告書

    • 標準構成：一般的には問題リスト、詳細分析シート、タスク達成度、
      主観評価などで構成され、評価計画や考察を加える。
    • 目的と柔軟性：「テストで得られた知見を関係者に共有すること」
      「状況に応じて速報の作成や簡易フォーマットへのアレンジが可能。」
    • スピードを重視した代替手段：議事録を報告書の代わりにすることで、
      細かい見落としのリスクもあるが、時間短縮できる。

その他（進め方）

リリース後

  • 独自ガイドライン作成
    自社製品のあるべき姿（品質や設計ルール）を社内で具体的に共有できるようになる。

    • 実用性のある社内展開：自社製品に特化しているため実用性が高く、
      メンバーへの共有がスムーズになる。
    • 具体性の向上：抽象的な表現を排除し、ボタンの形状や配置まで具体的に定義できるため、
      解釈のズレを防ぐ。
    • 品質目標とポリシーの共有：自社が目指すべき品質や設計ポリシーが明確になり、
      新人の教育・継承にも活用できる。

  • 継続的インテグレーション的な

    • 事項

      • 評価改善の継続：リリースした実製品で検証を繰り返し、
        見落としていた問題を修正・改善する。
      • ユーザーの反応や使用実態の把握：狙い通りのUX提供が出来ているか確認し、
        今後の開発や現行品の改善に活かす。
      • 次回に向けた環境整備：プロジェクトを通じて得られたノウハウや手法の課題を
        体系立てて見直し、次の活動に備える。

    • 調査
      実態把握の具体的な方法：主に2つの調査がある。

      • ユーザーの生の声の収集：ユーザーの反応や使用実態の把握
        ・ネット情報のチェック：レビューや口コミ、SNSの投稿から、
        　多くの人の評価やテキスト化しにくい使用実態を比較的容易に把握する。
        ・インタビュー・テストの実施：記憶喚起のために実機を操作してもらいながら
        　意見を聞く「ユーザビリティテスト形式」を取り入れ、課題を発見する。

      • 競合製品との比較：評価改善の継続の一つ、競合比較による対競合戦略
        ・仕様やコンセプトの比較：双方の製品を実際に操作し、
        　機能・UIの類似点や相違点を調べる。
        ・UX比較：双方で同じタスクを行ってもらい、客観的に比較する。
        　順序効果を防ぐため、被験者ごとに順序を入れ替えるなど工夫が必要。

モラル

  • ユーザビリティは操作上の扱い易さだが、
    ユーザ・エクスペリエンス（UX）は関わったときの、
    人の反応で、購入前も含まれる。
  • このため、ビジネス上の成功（売上やアクセス数）を優先するあまり、
    ユーザーを不誠実な方法で誘導するUXデザイン事例（ダークパターン）が問題視されている。
    • 登録は一瞬、解約は迷宮（ローチ・モーテル / Roach Motel）
    • コッソリ買い物かごに入れる（スニーキング / Sneaking）
    • 罪悪感を煽る選択肢（コンファーム・シェイミング / Confirmshaming）
    • 偽りの緊急性・希少性（フェイク・アージェンシー / Fake Urgency）
    • 巧妙な視覚的誘導（ミスディレクション / Misdirection）
    • 定期購入へのすり替え（ディスガイズド・サブスクリプション / Disguised Subscription）

移行メモ

  • 見出し自体がリンクになっていた箇所は、見出しを平文にした上で
    直下（または該当箇所）に箇条書きのリンクを配置した
    （GitHub Wiki は見出しテキストからアンカーを生成するため）。
  • 同一階層に同名の見出しが複数あったため、括弧書きで区別した
    （「定義と本質（UX）」「概要（ユーザビリティ・テスト）」など）。
  • 元ページの誤記を修正した。
    「重要が変化する」→「重要度が変化する」、「身体的の負担」→「身体的な負担」、
    「Ulzard」→「Uizard」、「フループルーフ」→「フールプルーフ」、
    「意思決定に称される」→「意思決定に供される」、
    「負担増加に成っている」→「負担増加になっている」。
  • ダークパターンの名称を一般的な表記に修正した。
    「ロッチ・モーテル」→「ローチ・モーテル」、「スネーキング」→「スニーキング」、
    「フェイク・サージェンシー」→「フェイク・アージェンシー」、
    「ディスガイズ・サブスクリプション / Disguised Ads」→
    「ディスガイズド・サブスクリプション / Disguised Subscription」。

Tags: UI, UX, ユーザビリティ, アクセシビリティ, 人間中心設計, ユーザビリティ・テスト, ダークパターン

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally