はじめてのWebアプリケーションデザイン 前編 Webアプリデザインは「手を離れる」と心得る
ランディングページやバナーのデザインを手掛けているグリコさんが、はじめてWebアプリケーションのデザインを担当することに。そこで、百戦錬磨の先生にWebアプリケーションデザインのポイントをたずねています。エンジニアのグリスケくんの視点も合わせてどうぞ。
はじめに
一口に「Web」といっても、コーポレートサイトからECサイト、メディアサイト、キャンペーンサイトなど、その目的はさまざまで、それに伴う「Webデザイン」の考え方も違います。
このシリーズでは、特に動的に内容が変化する「Webアプリ」のデザインについて、初めの一歩を考えていきます。登場人物は、UIデザイン初学者のグリコさんと、ベテランUIデザイナーの先生です。
デザイナーの方だけでなく、エンジニアやディレクターの方にも、「Webアプリのデザイン」について考えるきっかけになればと思います。
登場人物
グリコ：勉強中のUIデザイナー。これまで、LPやバナーのデザインを担当してきた。HTML/CSSも勉強中。
先生：ベテランUIデザイナー。WebサイトやWebアプリのデザインを数多く手がけてきた、グリコさんの先輩。UIに関する知識が豊富で、JavaScriptやHTML/CSSといった実装の知識も持っている。最近気になるCSSプロパティは
field-sizing。この記事を読んで、「CSS Gridと比べたときのその回りくどさのなさよ！ はよ！」と思っている。実装者（グリスケ）：JavaScriptからHTML/CSSまでなんでもこなすエンジニア。今回はところどころで登場して、UIデザインに向き合うときの実装者の本音を教えてくれる。
「Webアプリ」をデザインする
先生：お、グリコさんじゃん。今日はリモートワークじゃなくて、出社だったんだね。
グリコ：そうなんです。実はちょっと相談がありまして。今度、社内用のWebアプリのデザインの担当になったんです。
先生：おー、いいね！ あ、もしかしてあれかな、ポイント用のWebアプリ？ 今度から社内で運用していくって、僕も聞いたことある。ログインして、社員それぞれのページでポイントを入力したり、精算用の領収書をアップロードしたりと、わりといろんな機能があるよね。
補足：ポイント用のWebアプリ
スタッフが自分の実装した機能やタスクをポイントとして計上し、記録していくためのアプリケーションのことです。
グリコ：それです、それです！
先生：社内アプリだから、人が増えたり減ったりしても対応できるようにしなきゃいけないんだね。
グリコ：そうなんです。私これまでLP（ランディングページ）とか、バナーとか、そういうのしかやったことがなくて。Webアプリのデザインって、何を気をつければいいのか全然わからないんですよね。それで、なんというか、心構えみたいなことを教えてもらえたらなと思って。
先生：なるほど〜。じゃあちょっと考えてみようか。
グリコ：すみません、そもそもなんですが……「Webアプリ」ってなんなんでしょうか？ LPみたいなページとはなにが違うんですか？ いえ、わかってはいるつもりなんですけど……。
先生：そうだね、そこから整理してみようか。
これまでグリコさんが作ってきたLPは、基本的には「一枚もの」だよね。そして、目的がはっきりしている。キャンペーンをお知らせするとか、サービスの新規申し込みをしてもらうためとか。だから、オーダーメイドでデザインできるんです。
たとえば、見出しに入る文字はたいていもう決まっているから、その文字量が入るようにレイアウトすればいい。「申込み」のボタンを押してもらうことが目的だったら、このボタンだけちょっと目立つようにしてみようとか、特別なデザインを採用しても、まあ別に構わない。それ用に、ユニークに作れるっていうんですかね。
グリコ：うんうん、そのイメージはわかります。私も、LPはそういうものだと思ってました。広告を作るみたいな感じというか。
先生：でも、アプリでそれをやられちゃうと、「じゃあ何パターンそのボタンがあるんですか？」っていう話が始まっちゃうんだよね。Webアプリは、こだわるポイントが、LPとはちょっと違う。
グリコ：LPのほうは、見た目にこだわれるってことですか？
先生：いや、そうじゃなくて、こだわるところが違ってくるということかな。
これは気をつけなきゃいけないんだけど、デザインをするうえで、LPは簡単で、Webアプリは高度とか、そういう話じゃないんです。単純にコンテンツの違いなんですよね。考慮しなきゃいけないものの幅が違うんだっていう話。目的を間違わないように、ということなんですね。
まずはそういうことを頭において、そこからWebアプリのデザインについて、もっと考えてみようか。
グリコ：はい！
ボタンのサイズの用意、汎用性
先生：具体的に見てみたほうが話がわかりやすいかな。グリコさん、今回の社内用のWebアプリのデザイン、もう考えている？
グリコ：あ、まだちょっとですが、こんなかんじです。
先生：うーんと……たとえば、このボタンを例に考えてみようか。このページでは、2つボタンを配置しているけど、微妙にサイズが違うよね。ちょっと取り出してみるね。
こういう2種類のボタンがある場合に、これはどういう違いを持って、どういう意図のもとに作ったのかっていうのがわからないと、実装者は困っちゃう。そして、ボタンの汎用性もなくなってしまう。
グリコ：私、これ、それぞれ一個一個のボタンとして考えちゃっていたし、汎用性とかは考えていなかったかも。
先生：なるほどね、やっぱり画面単位で考えてしまっているみたいだね。
たとえば、ログイン画面を作るとき、「ログイン」ってボタンが必要なので作った。よしできたぞ。じゃあ次はホーム画面作りましょうってなる。そのホーム画面にはプロフィール編集機能があって、そこには「アップロード」というボタンと「保存」ボタンがあるので作りましょうってなった時に、この「保存」ボタンと前のページの「ログイン」ボタンっていうものが同じものとしては認識しないってことですよね。
グリコ：そうですそうです。……いくつもあったら、いけないんですか？
先生：パターンになっていればいいですよ。たとえばボタンが5つあっても、1つ目と2つ目がlarge、3つ目がサイズがmediumで最後の2つがsmallでしたっていうんだったら、実装者は何も困らないんです。
こうやって5つのボタンが3つのパターンでもって構成されてるっていうのは、特に困らない。それはこういう意図があるからだよねっていうふうになるから。
グリコ：そうか、どんな種類があって、どれがここで使われているかというのがわかると、実装者もやりやすいんですね。
先生：そう。LPは極端な話、「こういう見た目で作りました」でも大丈夫なんです。
でも、アプリケーションの場合はこのボタンという機能から派生してどんどん作られていたら、結構困る。今回の社内用のWebアプリはそんなにページ数が多くないみたいだけど、これが何十ページ何百ページにもなるような大規模なWebアプリの場合は、ボタンひとつでも何十何百って使われるわけです。
その場合、実装者がいちいち「このボタンはどのボタンなの？ それとも新しいボタンの種類なの？」って考えなきゃいけないし、時間も取られる。
だから、ポイントの1つ目としては、ボタンなどのUIとしてよくある部品は、意図を持って汎用性を持たせておくこと。たとえば、large、medium、smallみたいな感じでということかな。
実装者グリスケの視点：Webアプリならパターンが気になる
Webアプリのデザインをもらった側は、デザイナーからの意図が何もわからないままのデザインがきた場合、まずそのボタンが同じなのか違うのか、バリエーションがいくつあるのかを確認するのに時間が取られてしまいます。そして、その5箇所分のボタンが違っていたら、「これはどういう意図でしょうか？」とデザイナーに確認しなくては実装できません。
もしボタンに5つのバリエーションが必要だとしたら、それぞれには名前をつけないと実装者は管理ができない。「ボタン」という部品はアプリ上に何度も出てきますから。だから、デザインファイル上でバリエーションに名前がついていたりして、パターンが意識されていると助かりますね。
対して、LPの場合は、基本的にはデザイナーが作った画のとおりブラウザで表示できればいいと思っています。たとえば同じようなボタンなんだけど、微妙にサイズが違うことがあっても、たぶん僕ならデザイナーに確認せずにそのまま数値を入れます。LPのコーディングって時間がないことも多いですしね。
デザイナーの手を離れる、ということ
先生：次のポイントとして、「デザインしたあと、自分の手を離れる」っていうことがあるんだよね。最終的にどの状態で使われるかが実は見えてない。「手を離れる」っていうのは、使われ方をあらかじめすべて想定はできないという意味です。
グリコ：ん？ でもLPも、デザインしたら手を離れますよね？ 実装するのはエンジニアさんだし。
先生：うん、そうなんだけど、LPの場合は、デザインしたものをそのまま実装してもらうことが多いから、あまり気にしなくてもいいんだよね。もちろん、表示する側のデバイスやブラウザが変わったりするという意味では、自分のデザインから手を離れる、ということはあるけど。でも、たとえば、ボタンの中の文字数が想定と変わって、それに伴ってボタンのサイズが変わったりすることはあまりない。「キャンペーンを説明する箇条書きが5つあります」って言われたら、5つを想定して作ればいい。
Webアプリケーションの場合は、あらかじめ作っておいた型に対して文字列が流し込まれることがとても多い。だから、デザインもその変化に対する柔軟性が求められるんだ。
たとえば、今回の社内アプリの場合も、社員が増えたらその人のページが追加されるわけだよね。そのとき、名前が長〜い人が新しく入社するかもしれない。まあ、日本人の姓の長さなんてたかが知れているけど、じゃあ外国の人だったら？ そうすると、名前をクリックするボタンから文字があふれることもありうるよね。だから、いろいろなことを想定しなきゃいけない。
グリコ：えー！ そんなことまで考えるんですか!?
先生：（笑）そうなんだよ。意外と考えることが多い。あとは、UIやサーバーの「決め」も重要だったりします。
グリコ：「決め」とは？
先生：たとえば、ユーザー名の入力欄があったとして、何もしなかったらサーバーが許容するラインまでは、ほぼ無限と言っていい文字列が入れられるよね。じゃあそれを50文字までにするのか、10文字までにするのか、というのはアプリの運用をどうするのかという決めごと次第。
その決めがあれば、表示側は決まっている上限の文字数を想定してれば良いんだけど、今度はUIの決めを考える必要がある。幅が狭いところに置くのだったら、50文字入力されたら改行しちゃう可能性もある。そうすると、複数行になることをUI側が想定できていないと表示が破綻してしまう。
それから、さっきも言ったように、日本語なのか英語なのかによっても文字の幅が全然違う。極端な例だけど、一番文字幅が小さいであろうアルファベットの小文字のiを50個打ったのと、広めなwを50個打ったのとでは表示に必要な幅も違う。このように未知な要素に対して、UIはどのような振る舞いをするのか事前に決めておく必要がある。
そういういろいろなことを想定して、「決め」を作っていかなきゃいけないんです。
グリコ：そうか、「自分の手を離れる」ことを想定して「決め」が必要なんですね。
先生：そう。ボタンで言ったら文字数なんだけど、リストで言ったらリストの項目数も変わる。今回は各社員のページで領収書の画像をアップロードする仕組みがあるけれど、フォルダは最初は空だから0件のアイテムのときの表示はどうするか？ アップロードしたファイルが増えて100個になったら、どう表示したらいいだろう？ 全部一覧にするの？ ページャーで分けるの？ とかもね。
グリコ：うーん、考えることがいっぱいあるなあ。
先生：Webならではの特性もあるよね。たとえば、ページャーで一覧を分けるとしても、そのページャーのUIにfocusした状態、hoverした状態、disabledの状態とか、いろいろ考えておかなきゃいけない。これは僕が前に作ったページャーの指定だけど、これくらいの状態を考えなきゃいけない。
あと、こうやってボタンの境界がはっきりしないんだったら、どこが押せる範囲のか？ とか。
グリコ：そうか、「どこが押せる範囲なのか」みたいなとこも、これもUIデザイナーの範疇ということかあ。押せる範囲によって、ユーザーにとっての使いやすさって変わってくるってことですよね。
実装者グリスケの視点：エンジニアも気遣いはするけれど……
たとえば、キャレットアイコンのところしか反応せず、周りのエリアは反応しないサイトがあると、それはやっぱりユーザーにとっては使いにくいわけです。小さなことかもしれないけど、積み重なればサービスからの離脱につながるかもしれず「UIとして質が悪い」という評価になってしまう。
もちろん、エンジニアが気を利かせて、指定されていなくても空気を読んで実装してくれたりすることもあるかもしれないです。でも、そうとは限らない。指定があれば確実だし、そういった付加情報をもらえると、エンジニア側も「このアプリでの空気の読み方」がつかめてきて、より良いUIになると思いますね。
アプリは常に変化する「状態」がある
グリコ：そういうWebの機能って、LPではあんまり考えていなかったかも。もちろん、ボタンをクリックしたら別の申し込みサイトに飛ぶ、とかはあったけど。
先生：Webアプリの場合、動的に内容が変化するんだよね。たとえば、「ファイルをアップロード」のボタンを押したら、ファイル選択のダイアログが開く。これって、ボタンを押したら何かが起こるっていうことだよね。で、ファイルを「送信」できたらいいけど、そうじゃなくて「送信エラー」になったらどう表示する？ とか。
グリコ：さっきのページャーの話もそうですけど、リストの数の増減の想定とか、送信エラーの想定みたいなやつは、そういう「決め」の仕様書みたいなのが先にあるんですか？
先生：そういった、UIの挙動に関する仕様をこれまでにもらったことはないですね（笑）。たとえば、「送信」って書いてあったり「保存」って書いてある仕様書があったとすると、これはサーバーとデータをやり取りするんだろうなと理解する。そうすると、通信を前提にしたUIの状態が必要だろうと思って、送信可能な状態Defaultとか、:focus、:hoverなんかに加えて、サーバーとの通信中であることを示すBusyや通信が正常に完了したことを示すDone、通信エラーが発生した場合の状態もつくっておくんです。
グリコ：「送信」のボタンなら、ある程度は決まってくるのかな、って思うんですけど、もっと複雑なUIの場合はどこまでどうやって考えたらいいんだろう。
先生：たとえば、これは案件であった話ですけど、クライアントからとあるチャットアプリの新機能として「複数人を同時にチャットへ誘う機能を付けたい」という要望があったわけです。そして、一番ざっくりとした要望の場合は、クライアントからの指示はこれでおしまい（笑）。
そうすると私は、依頼者が書き溜めてるアプリ用の資料や、これまでの機能拡充の経緯なんかの情報を集めてみます。競合サービスの調査もありえますね。もしアプリ内に似たような機能が先行で実装されているぞって聞いたら、それを確認して、依頼者（または利用者）が欲している機能に、自分なりの答えを構築していきます。ほかにも、このサービスにはモバイル用のアプリが別にあったりしたら、そちらとの関係性や共存なども考えたりするわけです。
グリコ：えー！ じゃあその案件というか、サービスについての知識がないとできないですよね。
先生：ああ、そうです、そうです。サービスについての知識がないとデザインは絶対にできないです。
で、まずは自分でいろいろ集めて考えた結果のUIをクライアントに見せて、「これでイメージ合ってる？」って聞く。なんかちょっと違うかもしれないって言われたら、どんなふうに違うのかメモしておいて、またいろんなことを考えて、また提案する。だから1個のUIを作るのにものすごくごちゃごちゃ考えているわけです。
グリコ：なるほど。どういう機能がほしいのかをしっかりヒアリングして、考えなきゃいけないですね。まずは社内アプリ担当の先輩に、ミーティングの予約を取ってみます！
機能から考えるか、見た目から考えるか
先生：機能の話が出たけど、UIデザインをするうえでは、「見た目」と「機能」を切り離して考えることもとっても大切なんだ。
さっきのボタンの例で考えてみよう。ボタンのバリエーションも、目立ち具合いの強度を見た目で表現してるに過ぎないよね。別に最初から3つのバリエーションを作らなきゃいけないわけではないけど、まあ経験的にたいていの場合は「Fill」ボタンと「Outline」ボタンと「Nude」ボタンっていう大きく3つに分かれてる。あとはそれぞれのボタンサイズが大中小あると使い回しがしやすいねっていうので作っているわけです。
グリコ：うんうん。3つ目の「Nude」もボタンなんですよね。これって、ユーザーへのアピール度は低いですよね。ヘルプボタンとか「いてほしいけど、すごく目立ってほしくない」みたいな場合に使いそうです。
補足：ボタンの強度
「ボタンの強度」などボタンデザインを例にしたデザインの考え方を知りたい方は、次のシリーズなどを参考にしてください。
- 「ボタンデザインから学ぶデザイン手順」シリーズ
先生：じゃあ、リンクのUIも追加してみよう。そうした場合、「機能」で分けるとこうなんです。上の3つと、下の3つで分かれる。
グリコ：同じ「見た目」でも、buttonかlinkかという「機能」は違うから、ということ？
先生：そう。実装の視点でいくと「機能」の区別が重要なんですよ。でもデザイナーにありがちなんだけど「見た目」で区切るとこうなっちゃうんですね。
グリコ：ああ、そうですよね。そうすると、このデザインは、ボタンとリンク、見た目が一緒だから同じでいいんですかね？
先生：そこでさっきの「機能」の話を思い出してほしいんだよね。見た目的には同じだけど、振る舞いがすべて一致するかな？ ボタンはボタンの振る舞いがあり、リンクはリンクの振る舞いがあるよね。
たとえば、ボタンは押し終わったあとのDoneの状態があったり、送信ボタンで完了しなかった場合のErrorの状態があったりするけど、リンクはこれらはない。逆に、リンクは一度訪れたことがあるリンクならvisitedの状態があったりするけど、ボタンにはない。機能が違えば、状態も違うわけです。
グリコ：そっか、なにもしないときの「見た目」は同じでも、「機能」が違えば、ユーザーがなにかしたときの「状態」も違うんですね。だから「機能」にちゃんと沿ったバリエーションがそれぞれ必要になる。
先生：実際にボタンやリンクの部品を画面に配置してデザインしていく、メンタルモデル側に寄せて考える、そんなときは「見た目」なんですよ。でもそれぞれの役割を果たすためのデザインのバリエーションには違いが出てくる。
このあたりのことは、CodeGridの記事にも書いてあるので、ぜひ読んでみてください。
UIデザイナーは、この頭の切り替えを意図的にできてないと、「見た目」と「機能」が混ざってしまいがちです。UIの部品が持つ「機能」を把握して意図を持って使い分けないと、必要なデザインが足りない場合がある。それと同時に、「見た目」を意識できないと、ユーザーにとっては使いにくいUIになってしまう。だから、デザイナーはこの2つの視点を持っておかないと。
グリコ：はー。考える点がLPとは違うなあ〜。
先生：まだまだ、最初の一歩だよ（笑）。「デザイナーの手を離れる」というポイントの次は「運用されていく」ということを考えてみよう。