amoye-ui-ux

Amọ̀ye インターフェースとユーザー体験

現在のプロダクトやプロジェクトの情報と、長期的に通用する UX／デザインの判断に基づいて、一貫したインターフェースの方向性を定めます。独自のフレームワーク、フォント、スタイルのカタログや、コード化された推奨レイヤーを維持しないでください。

ワークフロー

1. 方向性を推奨する前に、実際のプロダクト、既存のブランドガイドライン、スクリーンショット／デザイン、プラットフォーム、コンポーネントの規約、トークン、関連するプロジェクトマニフェストを確認します。既存の承認済みアイデンティティとプロダクトの規約は、同梱された例より優先されます。
2. ユーザー／タスク、主要なサーフェス、プラットフォームの制約、コンテンツ／データの形状、アクセシビリティのニーズ、情報密度、既存のデザイン上の決定事項を特定します。実装をレビューする場合は、採用済みの方向性と、正確に描画された候補／根拠も特定します。必要に応じて amose を使用します。
3. 該当するインタラクション／レイアウト／デザインの分岐については、クイックリファレンスを確認します。ネイティブ／モバイル向けの仕上げや最終的なアプリレビューでは、プロフェッショナルアプリのルールも確認します。
4. 方向性が重要な点で本当に定まっていない場合、実質的に異なる構成が複数成立する場合、または実装済みの結果をデザイン面で収束させる必要がある場合は、デザインの収束を確認します。実質的な選択肢を明らかにするのに必要な範囲でのみデザインの可能性を探り、現状の根拠から方向性がすでに定まっている場合に、無理にバリエーションを作らないでください。
5. 内部の根拠だけでは、ビジュアル表現、コンポーネントの構成、インタラクションの詳細、または仕上げを十分に判断できない場合は、リファレンスに基づく構成を確認します。実例を参考に判断力を高めますが、判断を委ねたり、デザインをコピーしたりしないでください。
6. プロダクトのパターン、ビジュアルの個性、意味的な色の役割、タイポグラフィの振る舞い、情報密度、レイアウトの階層、インタラクション／状態の振る舞い、モーションの方針、データ／グラフの表現、短いアンチパターン一覧を含め、方向性を一つに定めます。推奨内容を変えうる、変化しやすいプラットフォーム／フレームワーク要件に限り、最新の一次情報を参照します。これらをここに保存しないでください。
7. スクリーンショット、モックアップ、プロトタイプ、その他の視覚的な参照が受け入れ可否を大きく左右する場合、視覚的に確認できるインタラクティブなアフォーダンスと、基盤となるセマンティックな機能を分けて列挙します。それぞれについて、採用、維持、適応、または却下のいずれかを明示します。セマンティックなノード／状態／コンポーネントに対応していることを、視覚的なアフォーダンス、階層、見つけやすさ、またはインタラクションが採用済みの方向性と一致している根拠として扱わないでください。
8. 必要に応じて brand を使用します。

判断ルール

• 一般的な業界の固定観念より、現在の製品やブランドに関する根拠を優先します。
• 依頼で再検討の対象とされていない、承認済みの製品やブランドの制約は、目新しさのために変える要素ではなく、不変条件として扱います。
• 重要な判断が実際に未決の場合に限り、代替案を検討します。同じ構成の配色や装飾だけを変えた案は、有意義な代替案ではありません。
• 範囲が明確なデザイン上の問いに答えるために外部の参考資料を使います。方向性を裏付ける根拠が揃った後に、目新しさを求めて調査を続けてはいけません。
• 応用可能な階層、構成、インタラクション、モーション、情報密度、状態表現の原則を抽出します。特徴的なレイアウト、イラスト、コピー、ブランディング、または独自のアセットを再現してはいけません。
• セマンティックな色の役割と、アクセシブルな前景色・背景色の組み合わせを使います。テンプレートで青や緑が一般的だとされているからといって、配色を独自に作り出してはいけません。
• Web サーフェスでは、現行の WCAG ガイダンスをアクセシビリティの基準とします。ネイティブ／モバイルサーフェスでは、該当するクロスプラットフォームの原則とともに、現行のプラットフォームアクセシビリティガイダンスを適用します。カスタムまたは複合型の Web ウィジェットで、ネイティブ機能やライブラリの挙動を超えるインタラクションセマンティクスが必要な場合は、アクセシビリティマニュアルを独自に維持するのではなく、現行の WAI-ARIA Authoring Practices (APG) を推論や参考の拠り所とします。
• 装飾的な目新しさより、確立されたプラットフォームのプリミティブと予測しやすいインタラクション挙動を優先します。
• サーフェスで必要な場合は、通常、読み込み中、空、エラー、無効、フォーカス／押下、復旧の各状態を明示します。
• 固定されたデバイスサイズに関する通説ではなく、コンテンツと階層に基づいたレスポンシブな挙動にします。
• モーションは状態や関係性を説明し、視差効果を減らす設定を尊重する必要があります。
• グラフは、意図した比較や関係性をわかりやすくし、色だけに頼ってはいけません。
• フレームワークやコンポーネントライブラリ固有の内容は、実装担当者や現行ツールに関する根拠として扱い、永続的な UX の真理とはみなしません。
• ビジュアルやインタラクションの忠実度が重要な場合は、実際にレンダリングされた挙動を確認します。ソースコードの意図だけから合格と判断してはいけません。

出力

推奨事項

以下を提示してください。

• ユーザー／ジョブ
• 選定した製品／インタラクションパターン
• ビジュアルの方向性
• セマンティックな色、タイポグラフィ、レイアウトのルール
• 状態、モーション、アクセシビリティの制約
• 該当する場合は、グラフ／データの方向性
• 実装への引き継ぎに関する制約
• アンチパターン

提示されたビジュアルリファレンスが合否判定に大きく影響した場合は、以下も明示してください。

• セマンティックな機能への期待
• 視覚的またはインタラクティブに重要なアフォーダンス
• それぞれのアフォーダンスに対する adopt | preserve | adapt | reject の判断
• レンダリングまたはインタラクションによる検証が合否判定にまだ必要なアフォーダンス

重要な検討が方向性に影響した場合は、未解決のデザイン上の問い、検討した実質的に異なる候補、選定した方向性と判断を左右した根拠、そして今後の実装を制約する場合に限り却下した代替案も明示してください。

外部の参考資料が方向性に大きく影響した場合は、以下も明示してください。

• 範囲を限定したデザイン上の問い
• 選定した参考事例
• 採用した応用可能な原則
• 合わないために却下した要素
• 根拠の不足や未確認の点

レビュー

以下を提示してください。

• 承認された方向性、または判断の基準となる根拠
• 重要な場合は、正確なレンダリング済み候補／根拠
• 違反している UX／デザイン原則、方向性の制約、または重要なアフォーダンスへの期待
• 影響を受ける挙動
• 根拠
• 有効な範囲で最小限の修正
• 残っている重要なデザイン上の欠陥、または根拠の不足や未確認の点

重要な欠陥が残っていない場合は、再レビューを求めないでください。