UX/UI強化型プロダクトマネージャーによる、デザインガイドラインサンプル
※現在Flutterの採用も増えてきている為、クロスプラットフォームのガイドラインが作りやすく記載しています
プロダクトマネージャーがHowの部分を作っていく事は多くはないですが、UX/UIデザイナーの方や、エンジニアの方と開発を進めていく上で、「どういうものがリリースされるか？」「ユーザーにとって設定した課題に価値を届ける事ができるUX/UIになっているか？」などの観点で、レビューや時に一緒に考える場もあるかと思います。
その上で、デザインのガイドラインが存在し、そのガイドラインを知っておく事は、プロダクトの一貫性を保つ事、再現性を持つ事、ユーザビリティーを向上させる事によるクオリティーの担保と制作時のコスト削減に繋がります。
デザインガイドラインは、プロダクトの共通認識ルールを持つためのガイドラインです。
プロダクト開発をすすめる上で、状況に合わせてガイドラインが変わることもあります。
ユーザビリティー向上の為の基本思想
・ユーザーにとってユニバーサルなデザインとする為、デファクト・スタンダードである、Apple Human Interface Guidelines, Google Material Design Guidelinesを参考とする。
デファクト・スタンダードである規格をベースに考える事でユーザビリティーを向上させる。(アプリは設計思想がHuman Interface GuidelinesとMaterial Design Guidelinesで大きく異なる為、大きな差分と共通となる設計部分を参考とする。）
Apple Human Interface Guidelines
▪️思想（Apple Human Interface Guidelines）
1. 外観の整合性 | Aesthetic Integrity
2. 一貫性 | Consistency
3. 直接操作 | Direct Manipulation
4. フィードバック | Feedback
5. メタファ | Metaphors
6. ユーザによる制御 | User Control
・Apple Human Interface Guidelines：https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/)
Google Material Design Guidelines
▪️ 思想（Google Material Design Guidelines）)
1. マテリアルはメタファーである | Material is the metaphor
2. 大胆、グラフィカル、意図的 | Bold, graphic, intentional
3. 動きには意味がある | Motion provides meaning
4. 柔軟な基盤 | Flexible foundation
5. クロスプラットフォーム | Cross-platform
・Material Design Guidelines：https://material.io/design)
▪️その他
・カードに影を使う場合は、中に配置するボタンに影をつけないようにする。フラットボタン、アウトラインボタン、テキストリンクを使用する
・カード内でスクロールは基本できない
・主要機能はメニューに内包しない（利用頻度が低い機能をメニューに内包）
・メニュー内が一つのリストの場合は適切なラベリングでボタンとしてインターフェイスに表示する
制作時のpxについて
- pxは奇数でなく偶数になるよう制作する。
- Retina環境、スマートフォンなどの2倍のサイズとなる環境で奇数pxの画像を縮小すると、稀にボケてしまう為
- 8の倍数のpxで制作する。（8では無理なミクロなUIコンポーネントは、4の倍数(4, 12など)などでも良しとするルールで行うとデザインに柔軟性が出る。）
- 多くのデバイス、ディスプレイは8の倍数で出来ている為
フォント（アプリ）
▪️iOS
・欧文: San Francisco（OS標準）
・和文: ヒラギノ角ゴ ProN（OS標準）
▪️Android
・欧文: Roboto（OS標準）
・和文: Noto Sans CJK JP（OS標準）
フォントサイズ
・Text Size Micro（極小） 12px
・Text Size Small（小）：14px
・Text Size Medium（標準）：18px
・Text Size Large（大）： 22px
▪️line-height
・font-sizeの1.5〜1.77倍程度（個人的には見出しの場合はもう少し狭くします）
▪️colorの比率
※比率（7：2.5：0.5の配色黄金比に基づく ※Accent Colorが無いページは7.5:2.5）
・ Primary Color: 70%
・Secondary Color: 25%
・Accent Color: 5%
▪️ Elevation
▪️Shadowを使い分ける
#### Button
- Shadow
- color: #○○○○○○
- Alpha: ○○%
- X: ○
- Y: ○
- Blur: ○
- Spread: ○
#### Card
- Shadow
- color: #○○○○○○
- Alpha: ○○%
- X: ○
- Y: ○
- Blur: ○
- Spread: ○
#### Button
- Shadow
- color: #○○○○○○
- Alpha: ○○%
- X: ○
- Y: ○
- Blur: ○
- Spread: ○
#### On Mouse
- Shadow
- color: #○○○○○○
- Alpha: ○○%
- X: ○
- Y: ○
- Blur: ○
- Spread: ○
制作方法
▪️Atomic Designを使用する。（チーム開発時の全体的なデザインの統一、共同作業の実現、管理/制作/編集コスト削減の為）
・最小の単位、Lv1: 原子（Atoms）:、Lv2: 分子（Molecrus）、Lv3: 生体（Organisms）、Lv4: テンプレート（Templates）、Lv5: ページ（Pages） の順に分け順に制作を行う。
・Lv1をシンボル化し、Lv2、Lv3、Lv4ですぐに呼び出せるようにする。
・Lv2をシンボル化し、Lv3、Lv4ですぐに呼び出せるようにする。
・Lv3をシンボル化し、Lv4、Lv5ですぐに呼び出せるようにする。
・シンボル化した、Lv1、Lv2、Lv3を使用し、Lv4を作成する。
・Lv4: テンプレート（Templeats） を使用し、Lv5: ページ（Pages）を制作する。
・作成したデザインガイドラインは、一つのページにまとめ、管理/制作/編集コストを削減する。
・シンボルは、1つのページで管理し、管理/制作/編集コストを削減する。
・デザインガイドラインで設定したカラールール、フォントルール、シャドウルールは、Appearanceに登録し、いつでも呼び出せるようにする。
・配置したシンボルの、色変更、文言変更、Lv1, Lv2, Lv3の変更はOverridesを使用し、制作・編集コストを削減する。
ヴォイス&トーン
▪️ここでは、Workday Canvas Design Systemのヴォイス&トーンの思想に準拠する
1. 「Simple」
専門用語を避けること
過剰な説明を避けること
2. 「Fast」
短くするように努めること
ユーザに二人称で話しかけること
3. 「Clever」
親しみやすく、直感的であること
正確であること
アラートモーダル
▪️ここではApple Human Interface Guidelineの内容を記載
▪️動作
・アラートの外観が独立しているように見えるので、アプリケーション・デバイスの変化を意味し、ユーザが最近行った結果ではないことを感じさせる
・ユーザはアラートを閉じなければ現在実行中のアプリケーションの使用を継続できない
・少なくても一つのボタンを含み、テキストフィールドを含めることが可能
・アラートの幅・背景の外観・テキストの配置（中央揃え）については変更ができない
ガイドライン
1. デバイスの向きによる外観テストを行う
2. 一般的に、二つのボタンを設置 ※3つ以上の選択肢の場合はアクションシート推奨
3. ボタンには適切な色を使用する
一般的に左側のボタンは暗い色、右側のボタンは明るい色を使用。ユーザがリスクを伴う可能性のある場合は、キャンセルボタンは右に配置する。ユーザが望む、害のない場合はキャンセルボタンは左に設置
▪️次の場合にはアラートの使用は非推奨である
1. アプリケーションの標準機能に関する情報など、単に情報を目につかせるだけの場合
2. 正常に進行しているタスクの状況をユーザに伝える場合
この場合は、アクティビティインジケータを使用することが推奨されている
3. ユーザが開始したアクション確認の確認を求める場合
削除などのリスクがある場合でも非推奨。この場合はアクションシートの使用が推奨されている
4. エラー・問題についてユーザに通知する場合
重大な問題についてはアラートを使用する場合もあるが、可能であればUIに統合するべき
▪️アラートのテキスト
・用語の確認
・タイトル形式の大文字化: すべての単語の一文字目を大文字表記にすること
・文形式の大文字化: 最初の文字だけを大文字表記にし、残りは小文字表記
▪️ガイドライン
1. アラートが表示された理由・ユーザがどのボタンをタップすべきか理解させる
2. タイトルは1行で表示し(完全な文より、文の断片を使用する)アラートメッセージを簡潔に
3. ネガティブな情報をユーザに知らせるのをためらわない
4. 「あなた」、「私」という単語は避ける
5. 大文字化と句読点を適切に表示する
- ※一つの文の場合に句点は使用しない、質問形式であれば大文字化と疑問符の使用
▪️ActionSheet
▪️ここではApple Human Interface Guidelineの内容を記載
アクションシートは次の目的で用いる
・タスクを完了する別の方法を提示する
・危険な可能性のあるタスクを完了する場合の確認
・常にユーザが選ぶボタンが少なくても二つ含まれる
▪️動作
画面の一番下から現れ、アプリケーションの最前面に浮いてくる
▪️ガイドライン
1. 害を及ぼす可能性のあるアクションを実行するボタンを抵抗する必要のある場合は、赤のボタンを使用する
ユーザの目に付けるためにアクションシートの一番上に赤のボタンを設置する
2. ユーザにアクションシートをスクロールさせない
3. アクションシートの背景の外観は、ナビゲーションバーおよびツールバーと調和させる
- 黒のナビゲーションバー、ツールバーを用いる場合は、半透明の黒の背景を用いる
- デフォルト(青)のナビゲーションバー、ツールバーを用いる場合は、デフォルト(青)の背景を用いる
4. 一番下にキャンセルボタンを含め、ユーザが簡単かつ安全にタスクを中止できるようにする
ModalView
▪️ここではApple Human Interface Guidelineの内容を記載
▪️動作
・アプリケーション画面全体を占めるので、ユーザに何かを達成する他のモードに入る印象を与える
・タスクを完了してビューを閉じるボタン、タスクを中止できるボタンを含む
▪️ガイドライン
1. 適切な場合は、タスクが何か分かるようなタイトルを表示する
2. モーダルビューを表示するのに適したトランジションスタイルを選ぶ。妥当な理由なしにスタイルを変えてはならない
- 垂直: 画面の下端から上に向かってスライドし、閉じると下端に向かって戻る
- フリップ: 現在のビューが水平にフリップして、右側から左側へモーダルビューを表示する。現在のビューの背景のように見える
- 部分カール: 現在のビューの1つの隅が巻き上がり、その下のモーダルビューを表示する。設定オプションを示すビューのようにユーザとのやり取りをさほど必要としない時に適している
4. 一番下にキャンセルボタンを含め、ユーザが簡単かつ安全にタスクを中止できるようにする
5. モーダルビューの全体的な外観とアプリケーションの外観を調和させる
ドロワーメニュー
（ここでは、Material Designガイドラインの内容を記載 ※Material Designで使われるナビゲーションの為）
▪️モーダルドロワー
・画面左側（左からというのはアプリ）からスライドしてくることで表示できる通常のドロワーメニュー
・画面左側（左からというのはアプリ）からスライドしてくることで表示できるメニュー、ドロワーを開く、メニューを押すことで表示または非表示にできる
・アプリが右から左への言語に設定されていない限り、画面の右側からのスライドにしない
・デスクトップでは常に表示されて、左側にピン止めされたような形になる
ドロワー上部には何らかのヘッダーがあり、その内容部分にはメインコンテンツの内容を示すメニュー等が表示される
・メニュー以外には基本用いない
・メニューはリストで表示される
・ドロワー内のメニューは、ユーザーの重要度に従って配置される。関連する目的地がグループ化される
▪️下部ドロワー
（ここでは、Material Designガイドラインの内容を記載）
・下部ナビゲーションドロワーは、下部アプリバーで使用するための特殊なタイプのモーダルドロワー。
下部のアプリバーのメニューアイコンからの到達可能性を高めるために、画面の横ではなく下部から開く。
▪️仕切り（Divider）
・水平方向の仕切りを使用して、リスト内のナビゲーション先のグループを区切ることができる。
▪️ヘッダー
・ナビゲーションドロワーのヘッダー領域は、ブランド表現（アプリのタイトルやロゴなど）、アカウントスイッチャーなどに使用できる柔軟なスペースとして利用できる。
▪️TABとセグメントコントロールの違い
セグメンテッドコントロールと Tab は見た目は似ているが、役割が異なる。 Tab は情報を並列で扱う。（カテゴリ毎に Tab を使う etc） セグメントコントロールは情報の絞り込み、画面の切り替えで使用する。
加えてこちらの記事である程度網羅できるはずです。