KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

スマホアプリ開発とデザインガイドライン

こちらの記事は、カケハシ Advent Calendar 2022 の14日目の記事になります。

はじめに

こんにちは!KAKEHASHIでおくすり連絡帳 Pocket Musubi というサービスを開発している星川です。チーム内では主にFlutterを利用したスマートフォンアプリ開発を担当しています。

Flutter開発に関わるのは初めてなので、初心に帰って新鮮な気持ちで取り組んでいます。特にレイアウトやUIコンポーネントはFlutter独自の組み心地があり、改めてiOSやAndroidのデザインやUIに興味を持ちました。

ということで今回の記事では、iOS / Android 双方のデザインガイドラインについて調べてみようと思います。

モバイルアプリにおけるデザインガイドライン

モバイルアプリにおけるデザインガイドラインとは、ざっくりいうと「アプリを作る上で守ってほしいことがまとめられているガイドライン」です。

ガイドラインにはAppleが用意した Human Interface Guidelines と、Googleが用意した Material Design があります。それぞれ、各プラットフォーム向けに各種UIコンポーネントやフォント、レイアウトの使い方などを記しており、開発する上で非常に役立つドキュメントとなっています。

特に Material Design のドキュメントは、画像や映像をふんだんに使って事細かに使用例や悪例を解説しています。対して Human Interface Guidelines は、各種UIやデザイン、体験がどうあるべきかを述べるような内容になっており、Material Design ほど実装に対して細かく明記されていない印象です。

ガイドラインには従うべき?

デザインガイドラインはあくまでガイドラインですので、強制的に従ってアプリを開発しなくてはいけないということではないです(Appleのガイドラインには、項目によってはマストで従う必要のあるデザインも一部存在します)。

ただし多くのユーザーが意識せずに利用できるアプリというものは、よくあるコンポーネントと期待どおりの動作、慣れた使い勝手を備えています。これはやはりガイドラインに従って作られているがゆえである、と考えて良いでしょう。

例えば Human Interface Guidelines や Material Design には、それぞれボタンの領域について以下のように説明しています。

Human Interface Guidelines より引用

On a touchscreen, buttons need a hit target of at least 44x44 points to accommodate a fingertip.

タッチスクリーンにおいては、ボタンが指先にフィットするよう、少なくとも 44 × 44 ポイントのヒットターゲットが必要です。

Material Design より引用

For most platforms, consider making touch targets at least 48 x 48dp.

一般のプラットフォームにおいては、タッチターゲットは少なくとも 48 × 48dp にすることをお勧めします。

このようにサイズは微妙に違えど、両プラットフォームともボタンなどのタップエリアに対して明確に数値を指定しています。実装者もデザイナーも、このようなガイドラインの数値を把握しているかどうかで、ユーザーの使いやすさや思わぬ誤タップなどに影響を及ぼしてしまいそうですね。

アラート / ダイアログを用いたガイドラインの例

では、実際のガイドライン確認して行こうと思います。例には、アプリでよく目にするコンポーネントであり、イメージも湧きやすい アラート / ダイアログ を取り上げてみます。

1. 乱用を避ける

アラート / ダイアログは強制的にユーザーの操作を中断させるため、あまり頻繁に表示されてしまってはユーザーの操作の妨げになってしまう恐れがあります。iOSもAndroidも、慎重に使用するよう述べているようです。

Human Interface Guidelines より引用

Use alerts sparingly. Alerts give people important information, but they interrupt the current task to do so. Encourage people to pay attention to your alerts by making certain that each one offers only essential information and useful actions.

アラートは控えめに使いましょう。 アラートは重要な情報を提供しますが、そのために現在のタスクを中断してしまいます。アラートには、重要な情報と有用なアクションだけを提供するようにすることで、人々がアラートに注目するよう促します。

Material Design より引用

Dialogs are purposefully interruptive, so they should be used sparingly.

ダイアログは意図的に操作を中断させてしまうので、控えめに使用すべきです。

2. 簡潔で挙動を明確なボタンテキスト

ユーザに選択を促す際、ボタンのテキストには「はい」「いいえ」などの曖昧な言葉は用いず、「削除する」「許可する」など、明確な行動を表す言葉を用いるのが良いとしています。こうすることで、ユーザーはボタンタップ後の処理を理解して操作することが可能になります。

⭕️ 良い例
削除するためにはどちらのボタンを押せばよいかが明確である

❌ 悪い例
ボタンだけではどちらで削除されるか判断できず、メッセージを正しく読む必要がある

Human Interface Guidelines より引用

Create succinct, logical button titles. Aim for a one- or two-word title that describes the result of selecting the button. Prefer verbs and verb phrases that relate directly to the alert text — for example, “View All,” “Reply,” or “Ignore.” In informational alerts only, you can use “OK” for acceptance, avoiding “Yes” and “No.”

簡潔かつ論理的なボタンタイトルを作成する。 ボタンを選択した場合の結果を説明する、1~2語のタイトルをつけましょう。例えば、"View All"、"Reply"、"Ignore "など、アラートテキストに直接関連する動詞や動詞句を優先してください。情報提供アラートのみでは、"Yes" や "No" を避け、"OK" を使用することができます。

Material Design より引用

Avoid presenting users with unclear choices. “Cancel” doesn't make sense here because no clear action is proposed.

ユーザーに不明確な選択肢を提示しないようにしましょう。明確なアクションが提案されていないため、ここでは「キャンセル」は意味をなしません。

3. ボタンの配置

メインとなる確認アクションのボタンは右側、却下アクションのボタンは左側に配置します(アラビア語は逆)。

⭕️ 良い例

主たる操作ボタンが右側にある

❌ 悪い例

操作ボタンが左側、取消ボタンが右側にあるのはよくない

Human Interface Guidelines より引用

Place buttons where people expect. In general, place the button people are most likely to choose on the trailing side in a row of buttons or at the top in a stack of buttons. Always place the default button on the trailing side of a row or at the top of a stack. Cancel buttons are typically on the leading side of a row or at the bottom of a stack.

みんなが期待する場所にボタンを配置する 最も選択しやすいボタンを、ボタン列の最後尾またはボタンスタックの最上部に配置します。デフォルトのボタンは、常に行の最後尾かスタックの一番上に配置します。キャンセルボタンは通常、行の先頭側またはスタックの一番下にあります。

Material Design より引用

Confirming actions are aligned to the ending side of the screen with dismissive actions on the leading side of the confirming action. For layouts using left-to-right languages, this means the confirming action is placed on the right, with the dismissing action to its left. This placement is reversed for right-to-left languages.

決定アクションは画面の終了側に配置され、キャンセルアクションは決定アクションの先頭側に配置しましょう。左から右への言語を使用するレイアウトの場合、決定アクションが右に配置され、その左側にキャンセルアクションが配置されることになります。右から左の言語の場合は、この配置が逆になります。

その他にもたくさん

今回は例として アラート / ダイアログ のガイドラインから3つほど紹介してみました。今回は特に、iOS / Android で共通するようなガイドラインのものをピックアップしてみましたが、iOS特有のガイドライン、Android特有のガイドラインもあります。

これ以外にも「タイトルの書き方」「メッセージのテキスト量」「ボタンの数」などなど、使い方や状況に応じたガイドラインがたくさん記載されています。

これらを知ることで、よりユーザーフレンドリーな アラート / ダイアログ の実装を行うことができるようになると思います。

まとめ

今回紹介した内容は、人によっては「当たり前」もしくは「意識したことがない」と感じるかもしれません。それはつまりこれまで手にしてきたアプリがガイドラインに従っており、意識せずにガイドラインの恩恵を受けているということなのかも知れません。

今回取り上げた以外にも無数のコンポーネントや機能が存在し、それらに対しても細かくガイドラインが用意されています。これらのガイドラインについてよりいっそう理解を深めていき、よりユーザーに寄り添った使いやすいアプリの開発を目指していきましょう!