クライアントエンジニアが知るべき仕様とUIデザインの共通と独立の話
Table of Contents
近年のWebサービスはiOSとAndroidのネイティブアプリの同時対応が一般的なモデルです。 それら各プラットフォームのデザイントレンドやガイドラインを重視せずサービス共通のUIデザインを優先するのはアンチパターンです。 本来ならiOSはiOSのデザインガイドラインに則り、AndroidならAndroidのデザインガイドラインに則ったデザインをするべきです。 未熟なUI/UXデザイナーがこの間違ったデザインファーストをやりがちです。 もし現在組んでいるチームのデザイナーがアラートのUIデザインを独自デザインでカスタムダイアログ化しようとしてるなら即刻止めましょう。
自分はUI/UXデザイナーでもグラフィックデザイナーでもないBtoC向けサービス作るのが好きなエンジニアです。 今回会社でクライアントエンジニア向けにプラットフォーム横断するサービスのおいてプラットフォーム横断すべき情報とすべきではない情報について考える機会があったので記事にしました。
iPhoneユーザにとってアラートのベストUXは標準アラート
みなさんはiOSなのにAndroidみたいなアラート、 AndroidなのにiOSみたいなダイアログボックスをデザイナーから依頼されてアラートやダイアログをフルカスタマイズして実装した経験はないだろうか？ 私も経験あります。 あれ意味分からないですよね。 メリットよりデメリットの方が大きいです。 プラットフォームによって用意されたUIデザインは、そこを利用するユーザーにとってデファクトスタンダードになっており それと異なるデザインや動きは既存知識を使わず、デザイナーがユーザーに新たに使い方を押し付けることとなり 慣れるまで操作性や利便性において不慣れになるのでUX低下を招きます。 また他サービスは使い慣れたUIデザインなのに、うちのサービスだけ独自デザインとなると慣れることはないでしょう。
デザイナーはデザインするプラットフォームを理解せずUIデザインするとUX最悪でそのデザインを使うユーザーのことを考えていないオレオレデザインになります。
プラットフォームによってアラートのイメージが異なる
例えばアラートと言われたら最初に浮かぶイメージは何ですか？
- Webフロントエンドエンジニア「ブラウザ上部に表示されるしょっぱいボックス」
- iOSエンジニア「画面中央にポップアップで出てくるいわゆるダイアログボックス」
- Androidエンジニア「ダイアログボックスまたはトースト」
プラットフォーム毎に用意されたアラートはUIデザインが異なりますし、動きも違います。
プラットフォームによってエラー通知の手段は異なる
例えばエラー手段といえば何になりますか？
- Webフロントエンドエンジニア「エラー文言を帯やフォーム毎の下に表示。またはCSSゴリゴリの自作ダイアログボックス」
- iOSエンジニア「アラート、もしくはサードパーティの自作ビュー」
- Androidエンジニア「アラート、もしくはトースト」
プラットフォーム毎のトレンドも異なるため同じエラー通知でもその表現は異なります。
ここを統一するメリットは各プラットフォームにとってありません。 なぜならサービスを使うユーザーは大抵が1プラットフォームしか使わないので、 各プラットフォームのUIデザインを同じにしたところで知識再利用するケースが存在しないからです。
表現方法はプラットフォーム間で異なってもプラットフォーム内では統一されてる
前述で説明したとおり、同じアラートやエラー通知と言ってもプラットフォームによって表現方法は一致しません。 だけどその表現方法はプラットフォーム毎のユーザーからしたら標準で見慣れた物です。
つまり プラットフォーム間と比べるとバラバラだけど、アプリ内の表現方法は一致してますし、他アプリでも見たことある表現方法です。
機種変やネイティブアプリのインストールで複数プラットフォーム体験するユーザーもいますが、 体験人数や期間を考慮すれば明白です。
WebからiOSアプリに乗り換えてUIデザイン異なっていても、他iOSアプリとデザインが同じであればそこに既存知識利用があるからです。
仕様は合わせるが表現(デザイン)は合わせないこと
「ユーザーに入力不備エラーを通知する」という仕様があるとします。
各プラットフォームの表現方法は違います。
- Webフロントエンドエンジニア「入力フォームの下に赤文字で文言を表示する」
- iOSエンジニア「アラート(UIAlert)で通知、しかしリッチコンテンツの場合はアプリ内共通の通知ビューを構築し表示する。文字色は通常色だがエラーアイコンがついてたりする」
- Androidエンジニア「アラート(AlertDialog)やトースト。iOS同様必要であればアプリ内共通の通知ビューを構築し表示する」
つまり仕様は3プラットフォーム同じだけど、仕様の表現は3プラットフォーム異なります。
補足：各プラットフォームの表現方法は一例です
例に上げたプラットフォーム毎の表現方法はトレンドやデザインコンセプトによって変わります。 しかし各アプリ内においては統一されています。
WebとiOSとAndroid間で同じデザインのダイアログボックスを使うメリットはない
プラットフォーム間のデザインを統一するメリットはありません。 大まかな画面フローやトンマナやコンセプトデザインは合わせるべきですが、UIデザインにおいては合わせる必要ありません。 たとえあったとしても、そのプラットフォームの標準やトレンドからズレた表現をユーザーに見せることで ユーザーはその表現への学習コストがかかります
例：同じアラートでもバージョンで異なる
アラートのYes/Noボタンの配置はプラットフォームによって異なるバージョンが存在します。 iOSユーザーにAndroid向けのYes/No配置を見せると、iOSユーザーは操作を間違える。 なぜなら他iOSアプリとYes/No配置が逆だから。 これはUX最悪です。
例：MacアプリのウィンドウにWindowsのデザイン
Macアプリのウィンドウ左上の 「閉じる/最大化/最小化」ボタンが右上にあったらMacしか知らないユーザーは理解できないですよね。 しかも絶対使いにくいですよね。
UIデザインは合わせないがカラーや画面フローは合わせる
前述で説明しましたが、サービスデザインにおいてテーマカラーの違反はサービス全体としての一体感が薄れます。 サイトのテーマカラーとは異なる色を使うと、カラーが与えるサービス印象が変わりますし、ユーザーターゲットもズレます。
例えば、かわいい系のテーマカラーで若い女性をターゲットにしたサービスがあった場合
- そこのLPデザインが水色だらけだったら？
- 外部のクレカ決済サービス使うためそこへ遷移したら青色だったら？
LPでユーザーが好む色が配色がされなかったらLPとして価値はないでしょう。 突然配色が変わったことで怖くなってやめる人も出てくるでしょう。
もっと簡単に言うと
cookpadのWebアプリ版とiOSアプリ版を見れば分かります。
そもそもデザインはデザイナーの自己満足ではなくユーザー向け
- AndroidとiOSのデザインをあわせた所で、Androidアプリを使うユーザーからしたらiOSのデザインが合わさってる恩恵は受けません。
- WebとiOSのデザインをあわせた所で、iOSユーザーは見慣れない操作を体験しなければいけません。
- PC版WebとiOSデザインをあわせた所で、ポインティングデバイスが違いすぎてUXは最悪です。
各プラットフォームのユーザーに快適で見慣れて受け入れやすいデザインにしていくべきです。
だけど仕様はプラットフォーム跨いで合わせないと不便になる
WebのSEO強化でユーザー集客し、アプリ版へ導線ひく方法は一般的だと思います。
「Webで使ってみて便利だからアプリも使ってみよう」と思ったユーザーがアプリを使ったところ 「Webで使ってた機能がアプリではない」「Webで覚えた用語がアプリじゃ全然違う用語で使いにくい」 といった残念なUXになります。
Web、iOS、Androidエンジニアが知るべき仕様とUIデザインの共通と独立の話まとめ
上記を整理すると
- 全体のデザインガイドラインは全プラットフォーム準拠すべき
- 仕様やUXの表現はプラットフォーム毎に適切でかつ統一した方法にすべき
- 仕様やUXはプラットフォーム横断で合わせるべき（ただし独占仕様などは例外）
