この記事は食べログアドベントカレンダー2021の24日目の記事です。
12/24 担当、デザイナーの @s_kohei です。
経緯と自己紹介
私事ですが、食べログのデザイナーとして入社して約1ヶ月が経過しました。
今までWeb制作を中心にやってきたこともあり、ネイティブアプリのUIデザインに携わるのは実は初めてです。私が現在担当しているデザインの範囲はPJ内のごく一部に過ぎませんが、そんな狭い範囲の中でも自分なりに気づいたこと、学んだことがありました。初々しく純粋で幼気なこの気持ちを忘れてはいけない気がしますので、ここに記していきます。
前置きが長くなりましたが、最後まで読んでいただけると嬉しいです!
トンマナの偉大さを再確認した日
デザインや制作に関わる全ての人類にとってトンマナが重要であることは言うまでもありません。トンマナがなければデザインとは呼べないとさえ思っています。しかし、今まで自分が認識していたトンマナはトンマナではなかったのかもしれないです…?
今まで関わってきたWebデザインではビジュアルの世界観を統一するためのルールとして捉えていたのに対し、ネイティブアプリのUIデザインでは機能性とサービスの目的を担保するためのルールという捉え方だと感じました。
その違いを考察してみました。
-
Webサイト
-
ビジュアルがユーザーに与える印象がアクションやコンバージョンに影響する
- 与える印象が正しければトンマナだけがすべてではない
- 数値を守るよりも見た目上の整合性を優先する場合もある
-
ビジュアルがユーザーに与える印象がアクションやコンバージョンに影響する
-
ネイティブアプリ
-
ゴールまでの操作性、使いやすさが継続利用に繋がる
- 使いやすさを定義したトンマナがブレることはない
- アップデートが前提にあるため共通の数値などがより重要になる
-
ゴールまでの操作性、使いやすさが継続利用に繋がる
例えば、ユーザーの行動としては
企業の求人ページであれば「アットホームで風通しがよく少数精鋭で新人が活躍できそうな職場だなー、エントリーしよう!」となりますし
店舗で使用する予約管理アプリであれば「忙しい時でもミスなくスムーズに管理ができて便利だなー、今後も使いたい!」となります。
なので、ゴールまでの操作性を担保するトンマナが最重要であるし、ビジュアル以前にそれがブレることは有り得ないのだと解釈しました。ビジュアルとUIの違いとも捉えることができますが、いずれにしても自分の中に新たな考えが増えました。
余白とユーザビリティを考えると見える世界
トンマナに引き続き余白の捉え方も少し変わりました。Webデザインでは、ボタンのタップ、ページ遷移以外で要素が切り替わることはあまりなかったです。(静的ページの話です。)なので、与えたい印象のための余白感や視線誘導させるための余白として扱うことが多かったです。
一方、アプリUIでは余白に機能が付随することが多いので、余白の目的が異なるように感じました。
HIGに余白とレイアウトの説明もあります。
特にWebとの違いとして、このようなことを感じました。
- アクションが含まれる要素の余白はタップエリアにも関係する
- リスト内の要素の羅列もタップやアクションによって表示される余白が動的に変わる
- スイッチやボタンの enable/disable によって前後の要素の視認性が変わる
つまり余白で見た目上のバランスをとることは大前提として、それに加えて操作性を向上させる余白を設定する必要があるということです。これは、Webデザインでも活かせるところがありますし、今まで感覚的に考えていたことが間違っていたと痛感させられました。
結局よく見るデザインが完璧な機能美説
よく見るデザインというのはこんなやつです。iPhoneユーザーであればよく見慣れたデザインかなと思います。
このようなテーブルのデザインについて、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 の記事はこちらだそうです。
苦戦した理由は主にこの2点です。
- 記事によって Level のニュアンスが違う
- 結局 Atoms (Lv.1) の定義がわからない
ですが、色々と考えた結果、概念を理解しようとしていたことが間違いだと気づきました。曖昧な表現になるのも当然なのです。PJや組織ごとに規模も制作フローも担当領域も違うからです。つまり、PJ内における Atomic Design の目的と考えを理解することが答えであり、一般化する必要はなかったのです。
それを踏まえて、現在のPJにおける目的と答えを考えてみました。
- 流動的(レスポンシブ)なコンポーネント管理
- デザイナーとエンジニア間での認識差を無くし効率的な実装を実現
- 関連PJとの操作性(トンマナ)を同一に保つ
- Atoms (Lv.1) は独立して機能する、UIにおける最小単位の構造体
- Atoms (Lv.1) の組み合わせが Lv.2 という定義
自分なりの解釈ですが概ね合っていると思います。(違ったら教えてください…)
これらを意識しながら制作することは今までなかったので、苦戦した部分は多かったですが「これが Atomic Design というものか!」と感激しています。しかし感激している場合ではないので、いち早く理解して使いこなし次のステップへ進めるよう精進します。
ベタ塗りには白文字という幻想を打ち砕く
これはもはやアプリとかUIとかの問題でもないのですが、アプリUIに関わる中で学んだことなので。
濃いめの背景色に文字を乗せる時、なんとなく白文字だと視認性が高い気がするという現象によく遭遇します。ですが、そう言い切れる根拠は持ち合わせていなかったのです。強いていうなら、グレースケールにして比較するくらいでした。
このくらいの色味だったらどうでしょう?
どちらが視認性が高いか、明確に説明するのはかなり難しいと思います。なぜなら目だけで判断するということは感覚に頼ることになるからです。時には好みに引っ張られてしまったり。しかしアプリのアクセシビリティを考えたとき、それでは良くないわけです。
色覚の多様性についても考える
そもそもなぜ、視認性について感覚に頼ってはいけないのかを考えなければいけません。それは、全員が同じ見え方ではないからです。身長や体重が皆違うように見え方も千差万別なわけです。
さらにその度合いが強くなれば、緑が認識できない、赤が認識できないなどという見え方もあるのです。
(色だけでなく、弱視などの視力が著しく低い場合も同様です。)
そういった色覚の違いに配慮したデザインを定義するために CUDO(NPO法人カラーユニバーサルデザイン機構)が定義した **CUD(カラーユニバーサルデザイン)**などがあったりします。
CUDOでは、色弱者をこのように定義しています。
色使い(配色)の配慮がなされてない社会において情報が伝達されにくい人を総称してCUDOでは「色弱者(しき・じゃくしゃ)」としています。
さらに、日本における色弱者の割合はこんな感じ。
日本では男性の約20人に1人、女性の約500人に1人、日本全体で約300万人以上いると考えられています。静岡県の人口、AB型の血液の男性の割合に匹敵します。
つまり、配色に配慮がされていない場合、これだけ多くの人に正確な情報が伝わらない可能性があるわけです。先程の配色をD型色覚(先天性色覚異常のなかで最も割合が高い色覚)に当てはめてみるとこのようになります。
もちろん人によって差はありますが、赤をほとんど認識していないのがわかると思います。ユーザーごとの色の見え方をコントロールすることはできないので、感覚値ではなくコントラスト比によって視認性を確保する必要があるわけですね。
超絶便利なツール
そこで Adobe® Color の出番です。
「Adobe」「Adobe Color」は、米国および/またはその他の国におけるAdobe の登録商標または商標です。
Adobe® Color に含まれるアクセシビリティツールは、色の上に文字が乗った時のコントラスト比を数字で表してくれます。そして視認性が良いか悪いかを教えてくれるのです。文字サイズや図形による視認性の違いも教えてくれたり、配色を提案したりしてくれます。
先程の色を突っ込んでみるとこんな感じになります。テキストは **#000000(黒)**の方が視認性が高いということでした。自分の感覚的には白文字の方が落ち着きますが、アクセシビリティを考えればこのような結果になります。(そもそもこんな配色を使うのかというツッコミは置いといて…)
Adobe製品のスクリーンショットは、Adobeの許可を得て転載しています。
このツールを用いれば、根拠に基づいたアクセシビリティの高い配色ができるということです。ツールだけに頼って全てを鵜呑みにするのも違う気がしますが、こういったツールを使いこなすこともUIデザインでは求められるのだと感じました。デザインをロジカルに説明するという永遠のテーマを実現するためにも。
さいごに
最後まで読んでいただきありがとうございます!!
色々と語ってみましたが、正直なところこの一ヶ月間、実力不足と経験不足を感じる日々でした…。ですが、だからこそ気づけたことがありますし課題も見えてきました。そしてそんな日々を楽しく感じています。
提供するサービスによる違い、チーム制作による違い、色々な良いギャップを感じつつ、ちょっとした気づきを大切に日々成長していきたい、そんな所存でございます。そして、ユーザーファーストのイケてるサービスを提供できるように頑張っていきます!
明日(12/25)は @tkyowa さんの「食べログのエンジニア組織を段階的に改善する取り組み」です。お楽しみに〜