Webデザイン畑だった人間がアプリUIに関わって気づいた5つのこと

この記事は食べログアドベントカレンダー2021の24日目の記事です。
12/24 担当、デザイナーの @s_kohei です。

# 経緯と自己紹介

私事ですが、食べログのデザイナーとして入社して約1ヶ月が経過しました。
今までWeb制作を中心にやってきたこともあり、**ネイティブアプリのUIデザイン**に携わるのは実は初めてです。私が現在担当しているデザインの範囲はPJ内のごく一部に過ぎませんが、そんな狭い範囲の中でも自分なりに気づいたこと、学んだことがありました。初々しく純粋で幼気なこの気持ちを忘れてはいけない気がしますので、ここに記していきます。

前置きが長くなりましたが、最後まで読んでいただけると嬉しいです！

# トンマナの偉大さを再確認した日

デザインや制作に関わる全ての人類にとってトンマナが重要であることは言うまでもありません。トンマナがなければデザインとは呼べないとさえ思っています。しかし、今まで自分が認識していたトンマナはトンマナではなかったのかもしれないです…？

今まで関わってきたWebデザインでは**ビジュアルの世界観を統一するためのルール**として捉えていたのに対し、ネイティブアプリのUIデザインでは**機能性とサービスの目的を担保するためのルール**という捉え方だと感じました。

その違いを考察してみました。

- Webサイト
    - **ビジュアルがユーザーに与える印象**がアクションやコンバージョンに影響する
        - 与える印象が正しければトンマナだけがすべてではない
        - 数値を守るよりも見た目上の整合性を優先する場合もある

- ネイティブアプリ
    - **ゴールまでの操作性、使いやすさ**が継続利用に繋がる
        - 使いやすさを定義したトンマナがブレることはない
        - アップデートが前提にあるため共通の数値などがより重要になる

例えば、ユーザーの行動としては
企業の求人ページであれば「アットホームで風通しがよく少数精鋭で新人が活躍できそうな職場だなー、エントリーしよう！」となりますし
店舗で使用する予約管理アプリであれば「忙しい時でもミスなくスムーズに管理ができて便利だなー、今後も使いたい！」となります。

なので、**ゴールまでの操作性**を担保するトンマナが最重要であるし、ビジュアル以前にそれがブレることは有り得ないのだと解釈しました。ビジュアルとUIの違いとも捉えることができますが、いずれにしても自分の中に新たな考えが増えました。

# 余白とユーザビリティを考えると見える世界

トンマナに引き続き**余白の捉え方**も少し変わりました。Webデザインでは、**ボタンのタップ**、**ページ遷移**以外で要素が切り替わることはあまりなかったです。（静的ページの話です。）なので、**与えたい印象のための余白感**や**視線誘導させるための余白**として扱うことが多かったです。

一方、アプリUIでは**余白に機能が付随する**ことが多いので、余白の目的が異なるように感じました。

HIGに余白とレイアウトの説明もあります。

https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/

特にWebとの違いとして、このようなことを感じました。

- アクションが含まれる要素の余白はタップエリアにも関係する
- リスト内の要素の羅列もタップやアクションによって表示される余白が動的に変わる
- スイッチやボタンの enable/disable によって前後の要素の視認性が変わる

つまり余白で見た目上のバランスをとることは大前提として、それに加えて**操作性を向上させる余白**を設定する必要があるということです。これは、Webデザインでも活かせるところがありますし、今まで感覚的に考えていたことが間違っていたと痛感させられました。

# 結局よく見るデザインが完璧な機能美説

よく見るデザインというのはこんなやつです。iPhoneユーザーであればよく見慣れたデザインかなと思います。

![iOSのデザイン.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2291682/20e049cc-80e6-f6f0-6ce6-aba3f3c2a44d.jpeg)

> このようなテーブルのデザインについて、HIGではこのように定義されています。
https://developer.apple.com/design/human-interface-guidelines/ios/views/tables/

過去に経験したクライアントワークでは**よく見るデザイン**というものは悪くとらえられることが多かったです。**見慣れたあしらいやレイアウトは個性がない**という認識になりやすいのです。なのでデザイナーとしては**いかに違う見せ方をするか**で日々奮闘していました。

一方で、アプリUIでは**ユーザーが無意識的に理解できるデザイン**が答えなのだと再認識しました。システマチックなものであれば尚更です。

例えばアイコンについて考えてみても

| アイコン | ユーザーの認識 |
| ---- | ---- |
| 歯車 | 設定画面へのリンクボタンかな |
| ペン or 紙 | 編集画面へのリンクボタンかな |
| ハンバーガー（3本線） | メニューが開くのかな |

> HIGでのシステムアイコンのラインナップはこんな感じです。
https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/system-icons/

無意識に認識できるアイコンの方がテキストで書かれるよりも認識しやすいと思いますし、逆に違う表現をされるとユーザーとしては迷ってしまうのではないでしょうか。時代の先端を行く**攻めてるサービス**では、新機能を表す見慣れないアイコンが実装されることもありますが、初回タップするまで機能説明を表示したりすることで**ユーザーに学習してもらう工夫**がされていますよね。

なので、システマチックなUIに関しては、自分で見つけ出すことよりも**デファクトスタンダードを取り入れること**が正解への近道なのだと解釈しました。膨大なデータや先人たちの試行錯誤の上で出来上がったものがスタンダードであると思うからです。

ではデザイナーはスタンダードを当てはめるだけなのかといえば、そんなわけはなく、スタンダードだからこそ細部の工夫が必要であるしトンマナが重要になるわけです。さらには、常にアップデートされるスタンダードを理解して使いこなすことも必要になります。むしろそこが腕の見せ所なのではないかと思います。

# Atomic Design の正体を見破った

正直なところ「Atomic Design ってコンポーネント化のことでしょ」とか思っていました。なので唯一、知識としてではなく概念的に理解するのに時間を要しました。

ちなみに、元祖 Atomic Design の記事はこちらだそうです。

https://bradfrost.com/blog/post/atomic-web-design/

苦戦した理由は主にこの２点です。

- 記事によって Level のニュアンスが違う
- 結局 Atoms (Lv.1)  の定義がわからない

ですが、色々と考えた結果、概念を理解しようとしていたことが間違いだと気づきました。**曖昧な表現**になるのも当然なのです。PJや組織ごとに規模も制作フローも担当領域も違うからです。つまり、**PJ内における Atomic Design の目的と考え**を理解することが答えであり、一般化する必要はなかったのです。

それを踏まえて、現在のPJにおける目的と答えを考えてみました。

- 流動的（レスポンシブ）なコンポーネント管理
- デザイナーとエンジニア間での認識差を無くし効率的な実装を実現
- 関連PJとの操作性（トンマナ）を同一に保つ
- Atoms (Lv.1) は独立して機能する、UIにおける最小単位の構造体
- Atoms (Lv.1) の組み合わせが Lv.2 という定義

自分なりの解釈ですが概ね合っていると思います。（違ったら教えてください…）

これらを意識しながら制作することは今までなかったので、苦戦した部分は多かったですが「これが Atomic Design というものか！」と感激しています。しかし感激している場合ではないので、いち早く理解して使いこなし次のステップへ進めるよう精進します。

# ベタ塗りには白文字という幻想を打ち砕く

これはもはやアプリとかUIとかの問題でもないのですが、アプリUIに関わる中で学んだことなので。

濃いめの背景色に文字を乗せる時、**なんとなく白文字だと視認性が高い気がする**という現象によく遭遇します。ですが、そう言い切れる根拠は持ち合わせていなかったのです。強いていうなら、グレースケールにして比較するくらいでした。

このくらいの色味だったらどうでしょう？

![ベタ塗り＆白文字_1](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2291682/0e727e28-7847-52d9-af5a-ffa753a0f150.jpeg)

どちらが視認性が高いか、明確に説明するのはかなり難しいと思います。なぜなら目だけで判断するということは**感覚に頼ること**になるからです。時には好みに引っ張られてしまったり。しかし**アプリのアクセシビリティ**を考えたとき、それでは良くないわけです。

### 色覚の多様性についても考える

そもそもなぜ、視認性について感覚に頼ってはいけないのかを考えなければいけません。それは、**全員が同じ見え方ではない**からです。身長や体重が皆違うように見え方も千差万別なわけです。
さらにその度合いが強くなれば、**緑が認識できない**、**赤が認識できない**などという見え方もあるのです。
（色だけでなく、弱視などの視力が著しく低い場合も同様です。）

そういった色覚の違いに配慮したデザインを定義するために CUDO（NPO法人カラーユニバーサルデザイン機構）が定義した **CUD（カラーユニバーサルデザイン）**などがあったりします。

CUDOでは、**色弱者**をこのように定義しています。

> 色使い（配色）の配慮がなされてない社会において情報が伝達されにくい人を総称してCUDOでは「色弱者（しき・じゃくしゃ）」としています。
>
><font color="DarkGray">*引用：[NPO法人カラーユニバーサルデザイン機構 -「色弱者」とは、どのような人ですか？](http://www2.cudo.jp/wp/?page_id=732#a001)*</font>

さらに、日本における色弱者の割合はこんな感じ。

> 日本では男性の約２０人に１人、女性の約５００人に１人、日本全体で約３００万人以上いると考えられています。静岡県の人口、AB型の血液の男性の割合に匹敵します。
>
><font color="DarkGray">*引用：[NPO法人カラーユニバーサルデザイン機構 - 色覚異常の人は、日本にどのくらいいますか？](http://www2.cudo.jp/wp/?page_id=732#a003)*</font>

つまり、配色に配慮がされていない場合、これだけ多くの人に正確な情報が伝わらない可能性があるわけです。先程の配色をD型色覚（先天性色覚異常のなかで最も割合が高い色覚）に当てはめてみるとこのようになります。

![ベタ塗り＆白文字_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2291682/d5983dfc-36e2-cd75-1822-a15ad77fe733.jpeg)

もちろん人によって差はありますが、赤をほとんど認識していないのがわかると思います。ユーザーごとの色の見え方をコントロールすることはできないので、感覚値ではなくコントラスト比によって視認性を確保する必要があるわけですね。

### 超絶便利なツール

そこで **Adobe® Color** の出番です。

https://color.adobe.com/ja/create/color-contrast-analyzer

<font color="DarkGray">「Adobe」「Adobe Color」は、米国および／またはその他の国におけるAdobe の登録商標または商標です。</font>

Adobe® Color に含まれるアクセシビリティツールは、色の上に文字が乗った時のコントラスト比を数字で表してくれます。そして視認性が良いか悪いかを教えてくれるのです。文字サイズや図形による視認性の違いも教えてくれたり、配色を提案したりしてくれます。

先程の色を突っ込んでみるとこんな感じになります。テキストは **#000000（黒）**の方が視認性が高いということでした。自分の感覚的には白文字の方が落ち着きますが、アクセシビリティを考えればこのような結果になります。（そもそもこんな配色を使うのかというツッコミは置いといて…）

![ベタ塗り＆白文字_3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2291682/27f3db6c-060f-3469-7569-a640f8e24580.jpeg)
![ベタ塗り＆白文字_4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2291682/9f2789f5-0189-0707-6506-d13701f44ed8.jpeg)
<font color="DarkGray">Adobe製品のスクリーンショットは、Adobeの許可を得て転載しています。</font>

このツールを用いれば、根拠に基づいた**アクセシビリティの高い配色**ができるということです。ツールだけに頼って全てを鵜呑みにするのも違う気がしますが、こういったツールを使いこなすこともUIデザインでは求められるのだと感じました。**デザインをロジカルに説明する**という永遠のテーマを実現するためにも。

# さいごに

最後まで読んでいただきありがとうございます！！

色々と語ってみましたが、正直なところこの一ヶ月間、実力不足と経験不足を感じる日々でした…。ですが、だからこそ気づけたことがありますし課題も見えてきました。そしてそんな日々を楽しく感じています。

提供するサービスによる違い、チーム制作による違い、色々な良いギャップを感じつつ、ちょっとした気づきを大切に日々成長していきたい、そんな所存でございます。そして、ユーザーファーストのイケてるサービスを提供できるように頑張っていきます！

明日（12/25）は @tkyowa さんの「食べログのエンジニア組織を段階的に改善する取り組み」です。お楽しみに〜