- コンテキスチュアルインクワイアリ
- 徒弟制度の学習モデル
- 候補者の選定
- 仮説的ペルソナ、ロール、人口統計的変数、環境要因
- 半ダースほどの面接が必要（経験則）
-
1日六回まで
- 質問、報告、作戦会議のため余裕雨を持つ
- 手探り→自由回答→確認、選択式氏kつもん
技術的な話をしない
ゴールが先、作業の話は後
ユーザをデザイナにしない
誘導尋問を避ける
- フォーカスグルーぷ
- 「なぜ」をさぐるのにはやくだたない
- 人口統計的分析と市場セグメント
- 製品の成長力の評価に役立つ
- ユーザビリティテスト（ ≠ ユーザーテスト）
- ユーザは上手く使えるか？
- ネーミング、構成、初めてつかうときのわかりやすさ、効率
- 日記を使った調査
- カードソート
- ユーザの脳内モデルを探る手法
- むずい
- 作業分析
- 作業の部分部分の原因とかを分析
- ペルソナ = 複合アーキタイプ
- 調査に基づいてつくる(≠ ステレオタイプ)
- 固有のニーズを持つユーザータイプごとに、別々のデザインを用意する
- 正解は一つに絞れない
- 最重要ユーザのニーズを満たす
- ペルソナのメリット
- 「ユーザー」って言葉は曖昧
- 主観ぽくなくなる
- ごくまれなケースに囚われにくくなる
- 別のプロダクtでペルソナ使いまわしちゃ🙅
ペルソナセット
モチベーション
ユーザーペルソナと顧客ペルソナ、サービス利用者ペルソナ
- ペルソナは↓とは違う
- ユーザーロール (抽象てきすぎ)
- ユーザープロフィール (ステレオタイプっぽい)
- 市場セグメンと
暫定ペルソナ
各ゴールは単純な1文で表現できないとだめ
行動的レベルメイン、本能or内省的レベル重視
- エクスペリエンスゴール: 体験
- エンドゴール: 具体的な目的
- ライフゴール: ライフステージ、結婚、給料三倍、我が社もサクセス
ユーザー以外のゴール：顧客、企業、技術的なゴール、、、
ユーザーが馬鹿にされてると感じたら負け
- 行動変数決める
- インタビューと行動変数の対応付
- パターン見出す
- ゴールと特徴を総合する
- チェック
- 物語を肉付け
- 配役を決める
- 主役、脇役、顧客、……
ペルソナ同士は赤の他人のほうが楽
- シナリオ：ゆーざーの未来を想像するツール
- ゴールわかりやすい
- ペルソナ使お
How(機能)よりWhat(ゴール)が大事
要件確定→フレームワーク設定
- 問題とビジョンを各
- ブレストで頭をリセット
- ペルソナは何を期待してる？を考える
- 被験者の反応を思い出す
- コンテキストシナリオをかく
- テキストのみ
- 実装の制約は完全に無視
- 要件を突き止める データ要件、昨日要件、……
- インタラクションフレームワークの設定
- フオームファクタ、ポスチュア、入力メソッドを定義
- 昨日要素、データ要素を定義
- 製品を「メッチャいい人」と仮定してあつかうとお徳
- 機能のグループと階層構造を決める
- スケッチを描く
- キーパスシナリオをかく
- 主要なインタラクションのシナオ
- チェックシナリオでチェック
- ビジュアル〃
- 「ビジュアル言語スタディ」？？？？を開発
- スタイルいくつか案出す、みたいな
- →適用
- 「ビジュアル言語スタディ」？？？？を開発
- 工業デザインフレームワーク フォームファクタと入力メソッド→プロトタイぷ作る→「形態言語スタディ」を作る
ブラッシュアップ
- 総括的評価と形成的評価
- 形成的評価: 反復的でアジャイルな感じ、評価→修正→評価→っ
- 総括的評価: 最後に評価
- ユーザビリティテストを形成的におこなうには
- 早い段階でテストやる、さいしょからデザイナ参加する、……
デザインの価値観、コンセプト原則、振る舞い原則、インターフェイスレベル原則、……
- 倫理的: 害にならない、状況改善、人類の進歩、社会貢献、幸福、正義、真実、法、神
- 目的的: ゴール達成に役立つ
- 実践的: コスト感とか、柔軟さとか
- エレガント: 気持ちよさ、統一感
ポスチュアパターン、構造パターン、振る舞いパターン
- ポスチュア = ユーザーにどう見られたいか
- メーラーなら3ペイン、とか
- iPhoneアプリなら左上に戻るボタン、とか
- プラットフォームと密接に結びついてる
- 支配者的なポスチュア: フルスクリーンなアプリとか
- 中級者メイン（脱初心者しやすい）
- リッチなアプリ作りやすい
- 無難な（疲れづらい）ビジュアルスタイルを使うと吉
- 単発的ポスチュア: 小さなウィジェットとか
- デーモン的ポスチュア: タスクバーとかに表示するとよさそう
ファインダビリティ
- 情報Webサイト
- トランザクションWebサイト
- Webアプリ
一般的なデザイン原則
- 製品をコンピュータだと思わない
- ハードとソフトの体験を統合
- コンテキストに従ってデザインする（運転しながらカーナビ使えるか、とか）
- モードはよく考えて使え
- ナビゲーションと表示のバランス
- 入力は単純に
キオスク端末、車載システム、テレビ、音声デバイス、などの話も
ユーザーがフローに入るには、インターフェイスは透明になれないといけない
- 脳内モデルに従う、小は大を兼ねる、議論しない
- 必要なボタンは見える範囲に: 上級者用メニューは隠してもよい
- モーダルやめろ
- 蓋然性に従え: 殆どの場合Aを選ぶ、みたいな選択肢だすな
- 不要な報告するな
- 白紙じゃなくてデフォルトテンプレートの状態でアプリ起動するとよさそう
- 質問するな、選択肢だせ
- 危険ボタンは隠せ
- だんまりするな、「ロードしてます」とか出せ
- 上級者には初心者向けの補助輪はずせ
- 無駄な通知とかダイアログ出すな
- ユーザに許可を求めさせるな
- なんでもWYSIWYG
- ナビゲーションは基本的に間接税的な操作だ、減らせ
-
行く場所を減らす、道標を用意する、全体像を示す、コントロールと機能のマッピングを適切に（ガスコンロ）、階層構造を避ける
-
注釈付きスクロールバー
-
単射グループ（ネストが1段階までのグルーピング）
- 思慮深い製品
- ユーザーに関心を示す
- ユーザーに敬意を払う
- 先を見て行動する
- 常識
- 質問しすぎない
- エラーよしなにする
- 自身を持ってる
- 賢い製品
- アイドル中、バックグラウンドで仕事する
- 物覚えがよい、タスクコヒーレンス考える
- 殆どのときに殆ど正しい
-
ビジュアルデザインの主なパラダイム: 実装中心、メタファ的、イディオム的
-
メタファ→保存ボタンとか→フロッピー知らない問題ある グローバルメタファ辛い問題
-
実装中心: ユーザーに実装モデルの理解を求める
- 組織図中心のインターフェイス: Webサイトは、ユーザーが持つ理解よりも、企業の組織構造に従って構成されやすい。
-
メタファ的
- 「人間の頭脳が持っている類推という偉大な力を効率よく利用する方法」
- 「ユーザーの頭脳という気まぐれな存在に寄りかかった方法」
-
イディオム的
- 学習を必要とするが、優れたイディオムは身につきやすい
- ブランドロゴとかも
-
概念のメタファ見つけるのむずい
-
「イディオム的なデザインは、インタラクションデザインの未来だ」
-
プリミティブ→複合要素→イディオム
-
マニュアルアフォーダンス
- 優れたアフォーダンスを持つUI + ユーザーの学習 → 良い体験
-
グラフィックデザイナと違い、デザインは自己表現ではなくコミュニケーション
-
形状、サイズ、メイド、色相、向き、テクスチャ、位置
- サイズ、明度、位置は「順序のつけられる量的な変数」
- サイズは「解離性のプロパティ（形状など、他の変数が解読しづらくなる場合がある）」
- テクスチャはアフォーダンスの手がかりに役立つ
-
ビジュアルインターフェイスデザインの原則
- 要素にグループと階層構造を作れ、関係を視覚で把握できるようにしろ
- 流し目でテストすると良い
- ちょっとメタな単位で構成と流れを提供する
- グリッド最高
- 論理パスを意識する
- 凝集力、一貫性があり、コンテキストにあったイメージを使う
- アイコンが写実的でも特にメリットないよね
- 目的をはっきりさせてスタイルと機能を統合する
- 企業やブランドにとって、インターフェイスの第一印象は大事だよ、とか
- 単純を保て
- レバレッジ: 単一のインターフェイス要素を複数の関連する目的のために活用する
- ただの通知アイコンだと思ったらドロップダウンメニューだった、みたいな
- レバレッジ: 単一のインターフェイス要素を複数の関連する目的のために活用する
- テキスト
- 話を複雑にしてユーザーの混乱を生む危険もある。注意が必要
- 色は派手すぎず地味すぎず効果的に
- 要素にグループと階層構造を作れ、関係を視覚で把握できるようにしろ
-
ビジュアル情報デザインの原則
- 必ずビジュアルな形で比較対象を提供する
- Photoshopのフィルタのプレビューとか
- 因果関係を示す
- 複数の変数を見せる
- いろんな軸でグラフみたいよね
- テキスト、グラフィックス、データを1つの表示にまとめる
- コンテンツの品質、優位性、関連性を保証する
- 経時変化を示すときは、重ね合わさず、空間的に隣り合わせにする
- 量的データの数量を消さない
- 円グラフにはちゃんと数字もだせ
- 研究発表でやって怒られるやつだ……
- 必ずビジュアルな形で比較対象を提供する
-
インターフェイス標準に従うと楽
- いつ破るべきかを考える
- 位置検索、ID検索、連想/属性ベースの検索
- フォークソノミー = ユーザーが自分で表現する言葉やタグで情報を分類すること
- リレーショナルDB対デジタルスープ
- 自然言語出力 （←ぼくは絶対使いづらいと思うんだよなあ）
- 差分的操作と手続き的操作（DBに変更がある→差分、ない→手続き的）
- 手続き的のほう、UI stateやView stateって呼ばれるよね
- 手探りアンドゥと説明的アンドゥ
- シングルアンドゥとマルチアンドゥ
- グループ化マルチアンドゥ
- Backspaceはアンドゥの一種
- アンドゥの対象外となるデータもある
「ディスクとファイルの管理はユーザーのゴールではない」
- 単一ファイルモデル
- 自動セーブ: ドキュメントと設定
- コピーの作成: backupやaliasではなく、clone
- 名前の指定と変更: keynoteみたいに、タイトルバーで変更できるとか
- 位置の指定と変更
- ドキュメントのフォーマットの指定
- 変更の取り消し: アンドゥ
- 全ての変更の取り消し: git checkout
- バージョンの作成: git commit
- データ完全性 vs データ免疫性
- ユーザーの入力はバリデーションして、モーダルでないフィードバックを返すべき
- ファッジアビリティ: 多少おかしなデータにも対応出来る性質
- 直接操作
- 「ナビゲーションと選択には、マウスとキーボードの両方をサポートせよ」
- ホットスポット: マウスカーソルの先端とかで、現在の座標を示す必要がある
- プライアンシー: ユーザの操作に応答するか否か
- 不連続選択と連続選択、相互排他、加算的選択、グループ選択、
- ドラッグプライアンシー、ドロップ候補、挿入ターゲット
- 縦のドラッグに反応しにくくすることで、横方向へのドラッグしやすくするなど
Alto : PARCで生まれた初のGUI、WYSIWYG編集
- PARCの原則
- ビジュアルメタファ
- モードを避ける（モーダル○○）
- オーバーラップウィンドウ
- タイルウィンドウ、仮想デスクトップ、マルチペインアプリ
- ウィンドウやダイアログをむやみに増やすな − マルチドキュメントインターフェイス
命令コントロール、選択コントロール、入力コントロール、表示コントロール
- 命令コントロール: ボタン、バトコン、ハイパーリンク
- バトコン(but-con) ツールバーにアイコン並んでるけど、実はボタンみたいに押せる
- 選択コントロール: チェックボックス、トグルバトコン（太字ボタンみたいな）、リスト
- フリップフロップボタンはやめたほうが良い？
- 再生ボタンが一時停止ボタンになるみたいな
- コンバトコン: アイコン押したらドロップダウンでるやつ
- 最初むずいけどイディオム的にはアリ
- リスト
- イヤーマーキング: 複数選択可能なチェックボックスのリスト
- 要素は、ドラッグドロップでリスト外に移動できたり並び替えできたりするよね
- コンボボックス: 文字入力ボックスからドロップダウン出るやつ。フォントとか
- フリップフロップボタンはやめたほうが良い？
- 入力コントロール: テキストボックス、スピナ、ダイアル、スライダ
- カオスパッドみたいなのも含まれる
- バリデーションと親切なフィードバックを心がけよう
- 表示コントロール
- スクロールバー
- いま何ページ目か、とか
- 波形編集でminimapみたいなのだしたり
- シーケンシャルで階層的なメニュー: inquirerみたいな対話型メニュー
- メニューは、ツールバーに比べ上級者向けの機能を隠すことが多い
- 教育目的にはメニューを使え
- カスケーディングメニュー: 階層構造のメニュー
- リボン: メニューとツールバーを統合したもの
- 直接実行メニュー？？？？？？？？？？？？？？？？？わからん
- ツールバーのバトコンと同じ機能を持つ要素には、同じアイコンをふると吉
- ツールチップは表示されるまでにタイムラグあると良いよね
- DnDでカスタマイズできたりするよね
- あんまり使うな
- モーダルじゃないダイアログは必要ないことがおおい
- ダイアログのしゅるい
- プロパティダイアログ: 環境設定とか
- 機能ダイアログ: ファイル書き出し時のモーダルとか
- プロセスダイアログ: 保存中です……みたいな
- Ubuntuのアップデートじのやつとかは、詳細情報を表示できたりして親切で便利
- キャンセルボタンは、プロセスを全部ロールバック出来るべき
- 告知ダイアログ
- 一時告知:バックグラウンドでプロセスが続くタイプの告知
- エラーの告知だすときはプロセスを停止すること。一時告知じゃだめ
- ダイアログのみせかた
- タブ、展開、カスケーディング
- カスケーディング: ダイアログがどんどん開く奴
- できるだけエラー出すな
- 入力が変でもうまくやれ
- やむを得ず使うときは、「礼儀正しく、問題点を明らかにし、よい解決方法を提案」すること
- RVMF(Rich Visual Modeless Feedback)
- ユーザーの習熟レベル毎に、いろんな方法で一つのことを出来るようにすると良い？？？？
- ぼく「複雑になるのでは？」
- 筆者「両方のグループを満足させないといけない」
- 特異的にモーダル
- ワーキングセット: 普段使う機能は限られる
- ペルソナとワーキングセットは対応する
- 環境内情報と環境外情報
- 初心者は、画面内にある情報だけで操作しないといけない
- 中級者のために、ショートカットキーみたいな記憶初段を
- ニーズ毎にテンプレートを
- ヘルプは中級者向けに作れ
- ヘルプのウィザードはやめてくれ……
- 自分が満足していないデザインアプローチを示すな。ステークホルダーがそれを気に入る可能性がある
- （◞‸◟）
- 形による経済
- ユーザーは、実際のロード時間よりも、自分のゴールを達成できるかどうかによってロード時間の長短を感じる