デザイナさんと一緒に検討すること・検討しておいて欲しいこと

　アプリ開発をしていて設計・実装者の立場から、デザイナ・UIUX担当との連携の初期段階で共有しておきたいことをリストアップしました。

　要望をデザインに落とし込む手法とかとかは専門外なので、ここでは設計・実装者の立場から、デザイナ・UIUX担当との連携の中で漏らしてしまいそうな検討事項をまとめてます。

1. 一緒に検討したい仕様

まず、設計・実装上の理由から「こんな場面があるのでUIUX・デザインを考えて欲しい」という項目。

1. アクセス許可の取得箇所と許可してもらうための工夫

   • 必要とするアクセス許可とその理由をデザイナと共有して、画面遷移のどこに挟むのがいいのか、なるべく許可してもらうための説明方法（ダイアログだけでいいのか、画面案内にしたがって許可を促すのか等）を検討。

2. 情報がない場合のデザイン

   • サーバからデータ取得中で情報がない場合の見せ方
     初回起動で情報がない、キャッシュが古いのでキャッシュ表示はできない、という場合のデザイン
   • 表示件数が０件の場合の見せ方
   • サーバエラーや通信エラーで表示するものがない場合の見せ方

3. サーバアクセス中や時間のかかる処理中のインジケーター

   • 画面操作をブロックしてはダメな場所、良い場所（ブロックせざるを得ない場所）を振り分ける
   • 操作ブロックしてはダメな場所でのインジケーターの見せ方（画面の一部をぐるぐる表示、画面の一部にプログレスバー配置等）
   • 操作ブロックする場合、そのキャンセル方法の検討
     • キャンセルボタンを配置
     • ヘッダ等の戻るボタンタップでキャンセル
     • 画面のどこかをタップするとキャンセルダイアログ表示、等
   • 進捗付きのインジケーターにするか・否か

4. アプリ起動時に表示する画面

   • アプリ強制終了時の画面を表示するのか（操作の継続性を優先）
   • 一定時間が経っていたら最新情報が集まる画面等、なるべく見せたい画面を表示するのか
   • 常に決まった画面を出すのか

5. ページングの見せ方
   検索結果等、大量のデータを例えば100件毎に読み込んで表示する場合の見せ方。

   • スクロールして「もっと見る」ボタンタップで続きの読み込み
   • スクロールして自動で続きの読み込み（インジケーターあり）
   • スクロールして自動で続きの読み込み（インジケーターなし）

6. 表示する情報の更新方法

   • 表示する情報の賞味期限により、更新の仕方が変わるので情報を分類。
     • ログ情報・・・過去の出来事で変わらない情報。例）利用履歴、購入実績
     • 即時情報・・・更新されたら即座に伝える必要がある情報。例）残額、住所等の個人情報
     • 期限付き情報・・・一定頻度で更新が必要な情報。　例）セール情報、レコメンド情報
   • 分類した情報のシチュエーション別の更新要否判断
     • リロードボタン／プルリフレッシュ等、利用者操作による更新要否
     • アプリ起動時の情報更新要否
     • バックグラウンドでの情報更新要否
     • アプリフォア時の情報更新要否
     • 一定時間での自動更新要否
   • 情報のキャッシュ要否
     分類した情報別にキャッシュの有無、キャッシュ期間を決める

7. オフラインでできること、できないこと

   • 画面毎にオフラインでの制約事項の明確化と、その際のUIUX・デザインを決める

8. アプリストアのレビュー訴求

   • ★評価アラートを表示する条件とタイミングを決める

9. DynamicType対応要否
   工数がかかるし、後で対応するのも大変なので関係者納得の理由で判断

10. アイコンバッジに表示する件数の定義

11. Appスイッチャー/タスクスイッチャーの状態で表示する画像

    • セキュリティ等の対策のため、OSのAppスイッチャーにスクリーンショットを表示したくない場合、何を表示しておくか

12. その他

    • オープンソースライセンス表記どこにするか？
    • Siri ショートカットを使える場所はないか？（音声コマンドによる操作が適した場所はないか？）
    • VoiceOver／TalkBack対応要否

2. デザイナさん主体で決めてもらいたい仕様

ここはデザイナ・UIUX担当さんに忘れずに考えて欲しい項目。

1. 条件を満たさない場合のボタンタップ可否ルール
   • 非活性にして押させないのか、押させて動作しない理由の説明表示をするのか。
2. 長いテキストの表示ルール
   • 右端で折り返して全部表示するのか、文字を縮小してでも表示するのか。
   • 行数の上限を設けるのか。
   • 行数の上限を設ける場合、「…」はどこに入れるのか、いれないのか。
   • 数値の場合、桁不足をどう見せるか。(NNN+とか)
3. 日時のフォーマットとそれを使う場所のルール
   • 202X年01月01日、202X年1月1日。202X/1/1
   • 00時00分、00:00
   • 12時間表記、24時間表記
   • あとX日、あとX時間
   • X日前、X時間前
4. タップ以外での画面遷移
   • スワイプで画面遷移できる画面とできない画面の明確化
   • エッジスワイプで戻れる画面の明確化
5. 表示要素のスケール
   • 大きな画面では、大きく見せたいのか、たくさんの情報を見せたいのか。
     大きく見せたい場合、各種アイコン・フォントのサイズは追従させるのか、させないのか。
     追従させるなら、エンジニアと一緒に追従させる部分を決める（追従させる範囲はなるべく限定したい）
   • 小さい画面の場合にどう見せるのか。
     構成要素を減らすのか、アイコン＋フォントの組み合わせならアイコンだけにするとか。
6. 表示する画像のアスペクト比がバラバラな場合の表示
   • 異なるアスペクト比の画像をどう敷き詰めるのか（グリッド状にするのか、隙間なく敷き詰めるのか）、Aspect Fit／Aspect Fillはどうするか。
7. ダークモード／ダークテーマの対応要否
   • 対応する場合、配色のルール
8. 対応するデバイスの向きとデザイン
   • スマホの縦横の専用デザインの有無
   • タブレットの縦横の専用デザインの有無
9. マルチウィンドウ対応要否（SlideOver、SplitView）

10. アラート

    • はい・いいえ、OK・キャンセル・閉じる or OK の文言の適用ルール
    • はい・いいえ の配置ルール（破壊的/非破壊的の考慮要否)

11. ボタンタップ時のフィードバック方法
    ボタンタップされたことを利用者にどのようにフィードバックさせるか。

    • ボタンの変化（色を明るくする、ボタンを縮小して凹ます、等）
    • 触覚フィードバック

12. その他

    • 既存アプリと同様のアクションをさせたいなら『XアプリのY部分と同じ』のようなデザイン指示をお願いしておく。

3. 進め方について合意しておきたいこと。

スムーズに作業を進めるためにデザイナさん（＆プロジェクト全体）で合意しておく項目。

1. デザイン環境
   • デザインツール
     開発するアプリの特徴にもよるが、なるべく意思疎通しやすいように動くもので確認したい。デザイナには高度な紙芝居ができるツール（AdobeXDとか）を使って欲しい（プロトタイプとして関係者に確認してもらいやすい）。
   • ツールの利用にライセンスが必要なら必要なラインセンス数の確認。
   • デザインデータのバージョン管理方法
     チケット・イシューと関係づけてどう管理するのか、変更箇所をどう記録するか、ツールが備えている機能と合わせて決める。
   • テキスト／メッセージの共有方法
     ダイアログに表示するメッセージやテキストを一覧化し開発者とデザイナで共有する。トンマナ・文言見直しに共有が必要。多言語対応の場合は全てのテキストを共有。
   • デザインツールで使っている色空間（sRGB、AdobeRGB、Display P3）
     実装時に色空間を合わせておかないと微妙にデザイン色と変わってしまうので注意。
   • デザイン素材の解像度（@2x,@3x）・ファイル形式（PNG、SVG）
2. 関係者との合意タイミング
   • 表示要素・ワイヤーの決定タイミング。
     これらが決まった後にサーバ側に用意してもらうAPI要件をまとめたりするため。
   • スマホ版／タブレット版のどちらを優先するか・同時にデザインするのかの順番、及び、先行する側を後続側で取り込むタイミング
     
   • トンマナ・文言の見直しタイミング
   • UIUX・デザイン承認者との合意タイミング、再レビューのタイミング

最後に

　デザイナさんと絡んだ経験は多くないので他にも検討すべきことは多々あると思いますが、このリストが少しでも役立てば幸いです。あと、こんな検討も必要だよね、というものがあれば指摘もらえると助かります。