これは何？
会社のAdvent Calendarだから、というわけではないですが、たまには技術記事以外を書いてみようと思います。Kurogoma4Dです。
社会人デビューしてこれまでモバイルアプリメインのエンジニアとして働いてきましたが、デザイナーの方と一緒に仕事するときにWebのデザインはやってたけどモバイルはほとんどやったことがないという状態の方が結構いました。
単に経験の話ではあるので、じゃあいきなりモバイルのプロジェクトなんて走れないか、というとそうではないです。基本的にはデザイナーとエンジニアのコミュニケーションを心がけていれば解決できることですし、感覚的にでもモバイルの事情を察していい感じの提案をしてくださる方もいます。
ただ、できれば知っておいていただけるとありがたいな〜って思うことがちょいちょいあるので、今回はそういった点を文章にしておくことにしました。
1. UIコンポーネントの構造、Typography等は各OS標準があることを念頭においてください
Android、iOSはそれぞれGoogle、Appleが定めるデザインシステムに基づいて設計されています（ご存知の方もいるかと思います）。
- Android: Material Design
- 以下
Materialと略します
- 以下
- iOS: Human Interface Guidelines
- 以下
HIGと略します
- 以下
この話をすると、「また標準コンポーネント使えって言ってるよ……」みたいな空気になると思ってるんですが、自分が言いたいのはそこではありません。
確かにMaterialやHIGには様々なコンポーネントが用意されており、これだけである程度アプリも組めるくらいには充実してます。
しかし、これらのデザインシステムにはUIコンポーネントを作るにあたって必要な定義（あるいは原理原則）の部分が含まれています。
つまり、標準コンポーネントを使わなくても、ある程度「良い感じ」のアプリが作れるような構造になっています。
Materialの方では Foundations という大項目でそのような定義がまとめられています。
例えば、各種ボタンがタップしやすくなるためにはボタンそのもののタップ領域をある程度確保することが必要です。
その定義が Target sizes にまとめられています。
Touch and pointer target sizes
For most platforms, consider making touch targets at least 48 x 48dp. A touch target this size results in a physical size of about 9mm, regardless of screen size. The recommended target size for touchscreen elements is 7-10mm. It may be appropriate to use larger touch targets to accommodate a larger spectrum of users.
ほとんどのプラットフォームでは、タッチターゲットを少なくとも48 x 48dpにすることを検討してください。このサイズのタッチターゲットは、スクリーンサイズに関係なく、約9mmの物理的サイズになります。タッチスクリーンエレメントの推奨ターゲットサイズは7-10mmです。より多くのユーザーに対応するためには、より大きなタッチターゲットを使用することが適切かもしれません。
HIGの方にも同じような記述があります。
Give all controls and interactive elements a hit target that’s large enough. For example, on touchscreen devices, a hit target needs to measure at least 44x44 pt; in visionOS, place controls so that their centers are at least 60 pt apart.
すべてのコントロールとインタラクティブ要素に、十分な大きさのヒットターゲットを与えましょう。 例えば、タッチスクリーンデバイスでは、ヒットターゲットは少なくとも44x44ptの大きさが必要です。visionOSでは、コントロールの中心が少なくとも60pt離れるように配置します。
Webサイトでは例えば font-size: 16px; line-height: 20px なテキストをそのままリンクにして他の画面への導線を作る、みたいなことはよくあると思います。
その場合、line-height が 20px なので大体 20px * 文字の長さ分 * 16px(font-size) の大きさでクリック領域が設けられることになります。
こんな感じ
これを実際にモバイルアプリとしてそのまま実装してみると、「操作できなくはないけどなんか反応悪いような……？🤔」といった感触になるはずです。
（試してないですが、Figma Mirror等で試してみるとわかりやすいかもしれません）
ではどうすればいいかというと、先ほどの記述に則ってある程度paddingを設けてあげればいいです。
こうしたい
もちろんAndroidやiOS、あるいは開発で使っている他のフレームワーク（Flutter）等で使われているようなボタンに置き換えてもいいし、カスタムコンポーネントとして単にpaddingを増やすといった対応でもいいです。そこはエンジニアの方の裁量や、チームで話し合って決めるべきです。
重要なのは、このタップ可能な要素に十分なタップ領域が確保されていることにあります。これだけで、「使いやすい」モバイルアプリに一段階近づきます。
また、上記のようなFoundationsの中には、Typographyも含まれます。
これはアプリ内でどういった種類の大きさのテキストを使うか、といった定義になります。
これらの定義は、エンジニアが使うツール（SDK, Software Development Kit）に標準で組み込まれています。
つまり、もしこれらの定義をそのまま使う場合、デザイナーはこれらの用意されたTypographyだけを使えば良くなるし、エンジニアも新たに定義を一覧化してコードに落とし込む作業が必要なくなります。まさにwin-winです。
2. たまにOS標準のコンポーネントが登場することがありますが許してください
正直これはアプリの要件によりあったりなかったりで、都度エンジニアがコミュニケーションを取ったほうがいいものなので書くか悩みましたが一応。
ことモバイルアプリにおいては、ある機能を使うときには必ずシステム上で決められたUIを呼び出さないといけない状況があります。
自分が今パッと思いつくところでは、以下の機能が該当します。
- アプリに対する権限許可
- 写真などのファイルアクセス、位置情報、マイク等
- 生体認証・画面ロックの解除
- 画面収録
例えば権限許可はこんな感じのダイアログが表示されます。
よく見るやつ
様々なアプリで権限許可は行われているので、恐らく普段スマホを使っていて一度くらいは目にしたことがあるかと思います。このダイアログはAndroidにおいては文言もスタイルもカスタマイズすることはできません。プログラム上でできることはこのUIを呼び出して、ユーザーが選択した結果を受け取ることだけです（iOSでは説明文言のみカスタマイズできます）。
また、生体認証に関してはまず端末によって顔認証なのか、指紋認証なのか、虹彩認証なのか、はたまた生体認証が設定されていないためパターンやPINコードの認証になるのか……といったバリエーションが存在します。
| 生体認証 | PINコード | パターン |
|---|---|---|
 |
 |
 |
ちなみに、iOSではDynamic Island（ステータスバーの切り欠き部分の周囲に情報を表示できる機能）に対応している端末か否か、で挙動が少し違います。Dynamic Islandに対応している場合はDynamic Island上でFace ID（顔認証）のアニメーションが入るため、画面をさほどブロックしません。対して非対応の場合はモーダルダイアログ形式で認証を要求してくるため、画面をブロックする形になります。
……長々と話しましたが、頭の片隅に置いておいていただきたいのは、これらのシステムUIをカスタマイズしようとしないでください、ということです（一部UI中に表示される文言はカスタマイズ可能です）。残念ながらエンジニアはその要求に応えることは不可能です。
3. （要件から外してない限り）縦画面/横画面を気にかけてください
Webの場合、モバイル/タブレット/デスクトップみたいな形でレスポンシブ対応を意識することが多いかと思います。
モバイルではよく忘れられがちですが、縦画面で使う場合と横画面で使う場合があるので、デザイン上破綻しないように考える必要があります。
個人的には基本的にはWebでのレスポンシブデザインと同じような考え方で、なるべく多くの画面サイズに対応できるようなレイアウトを考える、といった方向性であれば大きな事故になることは少ないと考えています。
例えば、下のようにニュースアプリでタイトルと画像が一覧で並ぶようなレイアウトがあったとします。
今のデザイン的な定義は、画面を占める比率が 画像:タイトル=1:2 になるようにしています。これで縦画面はいい感じになっているように見えますが、横画面にしてみると……
画像の大きさが画面の横幅に依存している関係で横長になって、見え方が微妙になってしまいました😢
ここで定義を 画像サイズは120x120で固定 とすると……
画像の見え方としてはいい感じになりましたね。もっと調整したいですが今はアプリを作っている場合ではないので置いておきます。
実装方法の問題、と言われれば確かにそうではありますが、こういった点に気づかないままリリースをしてしまうと思わぬお問い合わせに繋がって、結果的に全員の工数を余分に使う可能性もあります。
とはいえ、諸々の事情により、「この画面では必ず縦画面を維持したい」や、むしろ「横画面は絶対サポートしない」みたいな要望が上がることはあるかと思います。
それが妥当なものであれば許容しつつ（ちゃんと画面回転の制限をする方法はあります）、とはいえ基本的には縦画面で使うユーザーもいれば横画面で使うユーザーもいる、といったことは念頭においていただけるとベストです。
最近はFoldable（折りたたみ）という選択肢もあるので、画面サイズの可能性は無限大です。自分もPixel 9 Pro Foldを常用しています。
先述したMaterialのページにはFoldableを考慮したレイアウトに関する記述もあります（どちらかというと、こういう種類の画面もあるよ、的な紹介っぽい感じですが）。
おわりに
ここまで読んでいただきありがとうございます。もしあなたがモバイルアプリに関わるデザイナーの方であれば、これを機にモバイルアプリのデザインに関して思いを馳せてみてください。
ちなみにMaterial DesignやHIGに一通り目を通すことはかなりおすすめの行動です。GoogleやAppleが長年培ってきたUI/UXの「あるべき論」が詰め込まれており、近年のアップデートではモバイルに限らずどんなプラットフォームでも最高の体験を設計するのに一読の価値がある内容となっています（※個人の意見です）。
Discussion