この記事の概要と注意事項
Webやアプリ、UIデザイン（以降、これらをまとめてオンスクリーンデザインと表記します）をこれから学びたい人に向けた記事です。
細かいことや具体的なテクニックについてはあまり記載していませんが、全体像を大まかに掴んでもらうには役立つかと思います。
この記事は私が大学や専門学校へお招きいただき話した内容がベースです。
対象となる学生は、以下のような属性です。
- デザイン自体を学び始めたのが最近
- Webやアプリ、UIなどについてはまだほとんど知らない
- 今後学校の講義で詳しく学ぶ予定ではある
講義の時間がそこまで長くないのもあり、正確性よりも感覚的な分かりやすさを重視しています。
また、今後の講義・授業にて補完される前提で話している箇所も多くあります。
オンスクリーンデザインという呼称について
「オンスクリーンデザインとは？」と思われる方も多いと思いますが、Webデザインやアプリデザイン、UIデザインなどをひっくるめたものをそう呼称します。
WebデザインとアプリデザインとUIデザイン、よく似ているんですがそれぞれ違いもあって、厳密に話しているとかえって分かりづらくなってしまう場合もあります。
私は、まだ色々なジャンルに精通していないうちに細かな違いばかりに着目してしまうと、全体的な理解が遅くなってしまうと考えています。
というわけで、今日は細かな違いではなく全体的なイメージをお伝えするために、WebとかアプリやUIをすべてひっくるめてオンスクリーンデザインと記載します。
あまり一般的な言葉ではないので、あくまでこの記事で説明をしやすくするための言葉だと思ってください。
グラフィックデザインとの違い
まず最初に、オンスクリーンデザインをざっくり理解するために、グラフィックデザインとの違いについて説明します。
分かりやすく対比させる次のように説明できると思います。
| グラフィックデザイン | オンスクリーンデザイン | |
|---|---|---|
| 一言で言うなら | 固定的 | 流動的 |
| 表現の制約 | 物理 | スクリーン |
| インタラクティブ性 | ない | ある |
| 状態 | 持たない | 持つ |
一言で言うなら
グラフィックデザインは、一言で言うなら固定的です。
一度印刷したものは（再び印刷し直す以外に）内容を変更する方法はありません。
サイズは固定で、A1サイズのポスターはどこに持って行ってもA1のままです。
見る人が操作してA2にするとか、体格にあわせてA1.5にするとか、そういうことはできません。
初めからバリエーションを作成する計画であれば、A1のポスター・A4のチラシ・ポストカードなどを用意することはできますが、あくまでそれぞれのサイズにあわせて新規に作っているようなものです。
対してオンスクリーンデザインは流動的です。
伝わりやすい話だと、同じサイトやアプリでも、使っているデバイスや環境にあわせて見た目が変わります。
デスクトップの大きなモニターで見るときと、スマートフォンの小さな画面で見るときでは、同じコンテンツでも随分見た目が違います。
また、仮に同じデバイスであっても、使う人ごとに設定が違う場合もあります。
年齢が高い方などはスマホの表示文字サイズを大きくしていることも多いです。
そのため同じスマホを使っていたとしても、1行に表示される文字数が変わり、行数が変わり、結果的に全体的な印象も変わります。
流動的とは、そのときどきで最適な見え方になるとも言えますし、作り手が思う良い見え方を提供できるわけでもない、とも言えます。
ただし作り直すのは比較的簡単で、変更した箇所はサービスに訪れているすべてのユーザーに反映されます。
紙媒体で誤字があったら謝罪や改修騒ぎになることもありますが、オンスクリーンの場合は「じゃあ、今から修正しましょう」で済んでしまう場合も多いです。
表現の制約
もう少し具体的な説明をするとして、表現の仕方や制約についての違いがあります。
グラフィックデザインは物理的で、例えば色を表現するためにはインクを用います。
インクということは減法混色で、どうしても表現しづらい色も多いです。
また、パネルに印刷した場合はその厚みや重さも考慮する必要があります。
天井から吊り下げたいと思ったらあまり重くはできない、などの制約が発生します。
対してオンスクリーンデザインは文字通りスクリーン上で完結しています。
RGBで表現する＝加法混色なので色の幅が広く、物理的には難しいことや不可能なことでもスクリーンの上でなら表現できます。
また、要素を動かすのもオンスクリーンでは当たり前ですが、紙の上ではできません
ただし当たり前ですが一長一短があります。
たとえば高級感ある表現をしたいとき、紙の上であれば箔押しやエンボスなど加工を施して、物理的な高級感を演出できます。
しかしオンスクリーンの場合はあくまでそれらをピクセル上で再現しているだけなので、リッチさでは劣ることが多いです。
インタラクティブ性と状態
インタラクティブ性と状態については、グラフィックデザインとの対比というより「オンスクリーンに特徴的なもの」として紹介した方が分かりやすいかもしれません。
オンスクリーンのサービスではユーザーが画面をタップしたり、クリックしたり、スクロールしたりといった動作が当たり前に存在しています。
これらの動作は、グラフィックデザインでは存在しません。
ポスターやフライヤーは、あくまで見ることしかできませんが、Webサイトやアプリでは、ユーザーが直接関わって操作できる、という違いです。
例えば、ボタンを押すと画面が切り替わる、スライダーを動かして画像のサイズを変更する、商品リストをスクロールして次々に見ることができる、といった体験はオンスクリーンならではのものです。
このようなインタラクティブな体験が含まれるため、オンスクリーンデザインでは見た目の美しさだけでなく、どのように操作されるかを考えるのが非常に重要です。
後は、少し難しい話ですがオンスクリーンデザインでは状態について考える必要があります。
例えば以下のような場合、2つの画面はかなり違います
- ログイン前とログイン後
- ECサイトでカートに何も入っていないときと入っているとき
- ユーザー登録時に正しく情報を入力したときと不備があったとき
グラフィックデザインの場合、いつ誰に対しても同じ情報を提供します。
例えば同じ雑誌なのに、見る人によって文章が変わるなんてことはあり得ません。
（地域にあわせて刷り分けている、といった場合はあり得ますが、それはあくまで違う雑誌を違う人に届けています）
しかしオンスクリーンデザインの場合は、ユーザーの動作だったり、タイミングだったりで中身が変わることも多いです。
こういった場合「状態にあわせてコンテンツを変える」などと表現します。
UIとUX
次はUIとUXについてです。
この2つの言葉、聞いたことがある人は多いと思いますが、何を意味しているのかから説明します。
UI
UIというのはユーザーインターフェース(User Interface)の略です。
とても簡単に言うなら、ユーザーが実際に操作する画面のことです。
例えば、ボタンやメニュー、入力フォーム、画像など、画面上で見えるすべてのものはUIと言えます。
UIのデザインは、見た目が美しいことはもちろん操作しやすいことが非常に重要です。
少なくない場面で、見た目の美しさよりも操作しやすいことが一番重要、ということもあります。
UX
一方で、UXはユーザーエクスペリエンス（User eXperience）の略です。
つまり「ユーザー体験」を意味します。
UXはUIよりも広い概念で、見た目や操作性だけでなく、ユーザーがそのアプリやWebサイトを使ってどんな体験をするのか、どれだけ快適に使えるのか、といった全体の体験に関わってきます。
たとえば、アプリを使って商品を注文するときに、迷わず簡単に注文できた場合、その体験はポジティブなものと言えます。
しかし途中で迷ったり、エラーが出たり、何か使いにくいと感じたら、それはネガティブな体験になります。
また、日頃提供している体験によって、同じ内容でも与える体験や印象は変わります。
例えば新機能が出たときに、まったく同じ機能であっても、日頃良いアップデートを提供しているサービスなら「新しい機能が出たのか、使ってみたいな」と反応してもらえます。
しかし、日頃よく不具合を出しているサービスなら「げ、いつも新機能が出るとバグだらけになるから嫌だな」と反応されてしまうこともあるでしょう。
どちらのパターンでも、まだ実際には使っていないにも関わらず、もう心の中に体験が形成されています。
このように、実際に使う場面だけでなく、使う前や使った後のこともユーザー体験に含まれます。
UXはよくこのような図で説明されます。
使う前、使っている最中、使った後、日々使っているサイクル、と色々な時間軸におけるユーザー体験があることを理解しておいてください。
よく利用中の体験だけ、つまり一時的UXだけに終始してしまっているのを見かけます。
UIとUXの違いの整理
UIとUXの違いを簡単に整理すると、UIは見た目や操作部分、UXはその操作を通じてユーザーが得る体験と言えます。
UIが綺麗で分かりやすいほど、UXも向上しやすく、逆にUIが複雑で使いにくいとUXも悪化しやすいです。
UIが良いほどUXも向上しやすいという記載なのは、UIが良くてもUXが悪い、という状態も当たり前に存在するからです。
例えばショッピングアプリを使っているとします。
商品の写真が見やすく配置されていて、ボタンが大きく、価格やレビューなどの情報がすぐに見られる状態だとしましょう。
この場合、UIは良いと言えそうです。
しかし商品を探すまでは良くても、商品の注文手順が複雑だったり支払い方法がわかりにくいと、最終的な購入は大変です。
どれだけ見た目が良く分かりやすかったとしても、複雑な手順を強いられればUXは悪くなります。
このように、UIが良ければ常にUXが良い、というわけではありません。
もちろん逆もまた然りで、UXは良いけどUIが悪い、という状態も起き得えます。
UIデザインの主目的は「見た目が美しく操作もしやすい」ことで、UXデザインの主目的は「ユーザーが使っていて快適で満足できる」ことです。
この両方を考慮しながらデザインすることが、オンスクリーンデザインにおいて重要なポイントになります。
UIとUXを両方しっかりとデザインすることで、ユーザーは自然とアプリやWebサイトを快適に使えるようになり、結果としてそのアプリやサービスに対する満足度も高まります。
オンスクリーンデザインを学ぶ上で、UIとUXの両方に配慮することが非常に大事だということを、ぜひ覚えておいてください。
インタラクションデザイン
次にインタラクションデザインについてです。
インタラクションという言葉はユーザーとシステムのやり取りを指します。
もっとわかりやすく言うと、ユーザーがボタンを押したり、スクロールしたり、画面をタップしたりする動作と、それに対するリアクション全般のことです。
ここで重要なのが、ユーザーが何か操作をしたときに、その操作に対して画面がどう反応するか、という部分です。
インタラクションデザインの中でも「ユーザーの操作に対する、短く小さな反応」を「マイクロインタラクション」と言い、分かりやすいので取り上げて説明します。
| ボタンを押した際の反応 | スライダーを動かした際の反応 |
|---|---|
 |
 |
例えば、ボタンを押した瞬間に少しだけ光る、スライダーを動かすと数値が表示される、といったものです。
このマイクロインタラクションについてもう少し掘り下げてお話します。
マイクロインタラクションには、主に以下の3つの役割があります。
- フィードバックの提供
- システムの状態を伝える
- ユーザーの誘導
フィードバックの提供
フィードバックの提供については、ユーザーがボタンをクリックしたり、タップしたりした時に、何かしらの反応がなければ、操作が成功したのかユーザーには分かりません。
マイクロインタラクションはこのような場面で、ユーザーに対して「操作が成功しましたよ」と知らせる役割を果たします。
例えば、フォームに入力して送信ボタンを押した時、ボタンが押し込まれたように見えることで、操作が受け付けられたことを示すことができます。
これによってユーザーは不安を感じず、スムーズに操作を続けることができます。
システムの状態を伝える
システムの状態を伝えるについては、例えばページがロード中の時、何も表示されていないと「システムが固まってしまったのでは？」と不安になることがありますよね？
こういう時に、ロード中を示すアニメーションがあると、ユーザーは「今、処理が進んでいるんだな」と安心します。
このように、システムがどのような状態にあるかを視覚的に伝えるのも、マイクロインタラクションの重要な役割です。
ユーザーの誘導
ユーザーの誘導については、例えば、フォーム入力の際に、未入力の必須項目が赤くハイライトされたり、正しい形式で入力されたフィールドにチェックマークが表示されたりすることがあります。
これらはユーザーに「ここを修正しなきゃ」とか「ここは合っているな」という判断をさせるサポートをしてくれます。
インタラクションデザインが上手くいっていると、いっていないと
インタラクションデザインがうまくいくと、ユーザーはスムーズにアプリやWebサイトを操作できるようになります。
逆にインタラクションデザインが不十分だと、ユーザーは混乱してしまい、どう操作すればよいかわからなくなることがあります。
ボタンをクリックしたけど反応がなく、「本当に押せたのかな？」と何度もクリックしまった経験がある方も多いと思います。
それはインタラクションデザインが適切でないケースの一例です。
また、インタラクションデザインは、単に見た目や操作感を良くするだけでなく、ユーザーに対して「アプリやWebサイトがどう機能するか」を説明する役割も果たしています。
例えば、スワイプすることでページが切り替わるアニメーションは、ユーザーはそのアプリが「スワイプ操作を受け付ける」と自然に理解します。
このように、デザインを通じてユーザーに使い方を伝える、というのもインタラクションデザインの重要なポイントです。
要するに、インタラクションデザインは「ユーザーがどう操作するか、そしてその操作に対してどんな反応が返ってくるか」を設計することです。
これによって、Webサイトやアプリをより使いやすいものとして提供できます。
デバイスにあわせた可変性
次はレイアウトやコンテンツの可変性について説明します。
Webサイトを使っていて、スマホで見る時とパソコンで見るときではレイアウトや見え方が違う、という経験はあると思います。
これは、デバイスごとに適切な表示となるようにデザインされているからです。
グラフィックデザインは固定的で、オンスクリーンデザインは流動的という話にも繋がります。
この動画のように、デバイスの大きさに応じて調整されたデザインをレスポンシブデザインと言います。
スマートフォン・タブレット・パソコンなど色々なデバイスから見ても適切に表示されるよう制作します。
例えば、スマホの画面幅なら、画像やテキストが縦に並ぶように配置し、パソコンのような画面幅では画像とテキストを横に並べる、といった具合でレイアウトを変えます。
やや具体的過ぎる話かもしれませんが、ブレイクポイントというものについて触れておきます。
ブレイクポイントというのは、デザインを変えるタイミングを決める画面幅の基準のことです。
画面の幅が600ピクセルを超えたらナビゲーション内のメニューを横に並べ、600ピクセル以下なら縦に並べる、というように扱います。
レスポンシブデザインを行う上では、このブレイクポイントの設定が非常に重要になります。
適切なブレイクポイントを設定することで、どんなデバイスでもストレスなく閲覧・使用がしやすくなります。
ブレイクポイントを細かくすればするほどユーザーにとって最適な見た目を提供しやすいですが、一方で開発や保守は大変になります。
オンスクリーンデザインの場合一度作って終わりということはまずありません。
日々新しい機能を追加したり、より便利に使えるようにしたりと、アップデートを行っています。
その際に1つの画面をアップデートするだけで良いのか、5つのパターンをアップデートするのかで、大変さが変わるのは想像がつきますよね？
アクセシビリティ
次にアクセシビリティについてです。
まず、アクセシビリティという言葉ですが、これは「誰もが利用できること」を意味します。
言わばWebの生みの親と言える、Tim Berners-Leeという方がいるのですが、その人の言葉を引用します。
The power of the Web is in its universality.
Access by everyone regardless of disability is an essential aspect.訳：
Webのパワーとはその普遍性です。
障害の有無に関わらず誰でもアクセスできることは、Webの本質的な側面です。
ですから、障害を持つユーザーや高齢者、または特定の状況下でデバイスを利用するユーザーであっても問題なく使えるように配慮したデザインが重要です。
また、アクセシビリティは単に道徳的・倫理的な義務であるだけでなく、法律や規制にも関わってきます。
例えば多くの国では、公共のWebサイトやサービスが障害を持つユーザーにとって使いやすいものであることを求める法律があります。
これに違反すると、罰則を受けることもあります。
しかし、アクセシビリティは法律を守るためだけに意識するものではありません。
誰もが平等にWebやアプリを利用できるようにすることは、ユーザー体験の向上にも繋がります。
あくまで障害を持つユーザーだけに配慮するのではなく、そういった方にとっても使いやすいものを作れば、自ずから万人にとって使いやすいものができあがります。
では、具体的にどのような点に注意すればアクセシブルなデザインを実現できるのでしょうか？
以下に、アクセシビリティを考慮したデザインの基本的なポイントを挙げます。
- 色のコントラストや組み合わせ
- キーボードナビゲーション
- 音声読み上げ対応
色のコントラストや組み合わせ
まず色のコントラストや組み合わせについて。
色覚特性を持つユーザーや視覚に制限があるユーザーでも読みやすいように、色のコントラストを高めることが重要です。
背景とテキストのコントラストが不十分だと、ユーザーは情報を視覚的に捉えるのが難しくなります。
また、コントラスト以外でも色の組み合わせにも注意する必要があります。
例えば赤と緑の区別が上手くできない人は20人に1人くらいはいると言われています。
そのため、テキストの色と背景色の組み合わせには注意を払い、アクセシビリティの基準に沿ったカラーパレットを維持するようにします。
キーボードナビゲーション
マウスやタッチスクリーンを使用せず、キーボードだけでWebサイトやアプリを操作するユーザーもいます。
そのためキーボードだけで操作可能であることも必要です。
例えばタブキーを使ってページ内の要素を順番に移動できる、フォーカスされた際にその要素が明確に表示される、などをクリアできるように作ることが求められます。
音声読み上げ対応
音声読み上げ対応は、主には視覚障害を持つユーザーのために実施します。
視覚障害を持つユーザーは、スクリーンリーダーというソフトにWebページやアプリの内容を音声で読み上げてもらい、情報を理解しています。
スクリーンリーダーは、ページ上の要素やテキストを読み上げるため、テキスト以外の要素（画像やアイコンなど）には代替テキストを設定することが重要です。
画像に説明がない場合、スクリーンリーダーではその情報が伝わらないため、適切な代替テキストを付けることで視覚障害者にも情報が伝わります。
アクセシビリティと他要素のバランス
ここまで話してきたようにアクセシビリティを考慮することは非常に重要ですが、視覚的な美しさやブランドの一貫性をないがしろにして良いわけではありません。
誰でも使えるけれど、見た目が良くない・分かりづらいなどでは本来達成したかった状態とは言えません。
アクセシビリティとデザインのバランスを取るためには、デザインの初期段階からアクセシビリティの要件を取り入れることが重要です。
あまりアクセシビリティについて考慮しないまま見た目や機能を作り出してしまうと、後からちゃんと対応するのは至難の業です。
今日は詳しく紹介しませんが、おおよそ見やすい色の組み合わせや文字の大きさというのは決まっているので、最初からそれを取り入れた上で作り始めるのが良いです。
ユーザビリティ
次はユーザビリティについてです。
ユーザビリティというのは「ユーザーがどれだけ使いやすいか」の尺度です。
デザイナーがどれだけ良いデザインだと思っていても、実際に使うユーザーがどう感じるかは別問題です。
ユーザビリティテストといって、その名の通りユーザーがどれだけ使いやすいかを実際にテストすることをよく行います。
ユーザーに実際に使ってもらってフィードバックをもらうことがとても重要です。
たとえば、作ったアプリのデザインが、とても美しく整っていたとしても、実際にユーザーが使ってみたら「ボタンの場所がわかりにくい」とか「文字が小さすぎて読みづらい」といった問題が発覚するかもしれません。
こういった点は、デザインを作っている側だと気づきにくい部分でもあります。
「プロなら気づくんじゃないの？」と思われるかもしれませんが、これが本当に何故か気付けないものです。
だからこそ、ユーザビリティテストは非常に大切で、ユーザーがどう感じ、どう使っているかをリアルに観察することで、改善のヒントを得ることができます。
ユーザビリティテストのプロセスは、実際にあるサイトだったり、仮に作ったプロトタイプだったりをユーザーに実際に使ってもらいます。
そして、ユーザーの操作を観察し、どの部分でつまづくのか、どの操作がわかりにくいのかを確認していきます。
ユーザーに自由に使ってもらうのも一つの方法ですし、特定のタスクを与えてその進行具合を見るという方法もあります。
たとえば「サイトに訪れて商品名を検索し、カートに入れて購入する」といった具体的なタスクを設定し、その過程でどんな問題が起こるかを調べる、といった具合です。
そしてテスト結果を受けて、デザインの改善を行います。
ユーザーがつまづいた箇所を修正し、より使いやすいものに改良します。
これを何度も繰り返すことで、ユーザビリティが高い、つまり使いやすく、ユーザーにとって快適なデザインを実現することができます。
プロトタイピング
次にプロトタイピングについてです。
プロトタイピングというのは、デザインの完成形を作る前に、その試作版を作ってテストすることです。
たとえば、アプリやWebサイトをいきなり全部完成させてしまうと、修正が必要な場合に多くの時間や手間がかかります。
細かい部分まで色や形を完成させた上で「やっぱりこの機能も必要」なんてことになったら大変です。
また、先ほどユーザビリティテストについて記載しましたが、まずは簡単な形で動作する試作版を作り、ユーザビリティテストを行うことも多いです。
プロトタイプは、最初は非常にシンプルなもので構いません。
全ページをきっちり作り込む必要はなく、ページ遷移や基本的な操作感をテストするために、ワイヤーフレームと呼ばれる線だけで構成された簡易なものを使うことも多いです。
ワイヤーフレームでのプロトタイピングでは、ボタンの位置やナビゲーションの配置など、UIの基本的な構造についてを確認できます。
これにより、細かいビジュアルデザインへ入る前に、使いやすさをチェックすることができます。
最近では、プロトタイプを作るための便利なツールがたくさんあります。
たとえば、Figmaはワイヤーフレームの作成から、ある程度のインタラクションまで簡単に再現することができます。
少し話は逸れますが、ユーザー中心のデザインを実現することや最終的にユーザーが満足して使ってくれるかどうかが成功の鍵です。
だからこそ、テストと試作を繰り返しながら、デザインを改善していくことが非常に大切です。
上手にプロトタイピングを作れば、完成品をリリースする前に問題点を発見し、解決することができ、成功へと繋げやすいです。
コーディング
さて、デザインが固まって、ユーザビリティテストやプロトタイピングを通して改善が進んだら、次に必要なのは実際にそのデザインをコードで実装することです。
コーディングと呼びます。
フロントエンドやバックエンドの定義、境界などについて、この記事では細かく扱うことはしていません。ご了承ください。
デザインツールで見た目を作ることは、どこまでいってもプロトタイプであって、完成品ではありません。
例えばFigmaやSketchで作ったデザインは、見た目が綺麗に作り込まれていても、それだけでは実際にインターネット上で動くサイトやスマホ上で動くアプリにはなりません。
コードを書いて実際に動作するものにする必要があります。
具体的には、HTMLやCSSといったマークアップ言語を使ってブラウザに表示される画面を作り、JavaScriptなどを使って、インタラクティブな機能を実装していきます。
例えばボタンをクリックしたときに何かが起こる、フォームに入力したデータがサーバーに送られる、といった動作は、コードを使って初めて実現します。
また、デザインの中にはアニメーションやインタラクションなどの動きが含まれることも多いです。
これらも、コードを書いて実際に実装する必要があります。
例えば、ボタンが押されたときに少し浮き上がるようなアニメーションをつけたり、ページをスクロールしたときに内容が動いて見えるような効果を加えたりします。
さらに、バックエンドと呼ばれるサーバー側での実装も必要です。
ユーザーがフォームに入力したデータを送信したり、アカウント情報を保存したりするためには、データベースやサーバーとの連携が必要になります。
見た目を作るだけでなく、実際に動くコードを書いて、インターネット上でアクセスできる状態にすることが、Webやアプリ開発では必須です。
デザインと実装は密接に関わっており、良いデザインがあってもそれを適切にコードで実装しないと、ユーザーにとって使いにくいものになってしまいます。
コードを理解していないままでオンスクリーンデザインを作ると「見た目は綺麗だけどとても実現しづらい」ようなものが生まれがちです。
デザイナーの全員が全員コードを書いて実装できるようになる必要はありませんが、最低限の知識やリテラシーは持っておく必要があると思っています。
パフォーマンス
デザインがコードで実装されても、ただ動くだけではいけません。
パフォーマンスを考える必要もあります。
どんなに素晴らしいデザインでも、ページがなかなか表示されなかったり、操作に遅延が生じると、ユーザーは離れてしまいます。
したがって、オンスクリーンデザインでは、見た目やインタラクションと同じくらい、パフォーマンスの最適化が重要になります。
まず、パフォーマンスがなぜ重要なのかを確認しましょう。
ユーザーがWebサイトやアプリを使用する際、表示速度や操作の滑らかさは、全体的な体験に大きく影響します。
たとえば、ページが読み込まれるまでに数秒かかるだけで、ユーザーはイライラし、最悪の場合そのサイトを離れてしまうことがあります。
特に、モバイル端末ではネットワークが不安定であったり、処理能力が低かったりするため、軽量かつ高速な設計が重要です。
パフォーマンスの最適化は、ユーザー体験を向上させるための重要なステップです。
パフォーマンスを最適化するためには、デザインだけでなく、実装やインフラにも気を配る必要があります。
ここでは、パフォーマンス最適化の基本的な考え方をいくつかご紹介します。
- 画像の最適化
- 速く効率の良い書き方
- 見栄えとパフォーマンスのバランス
画像の最適化
まずはじめに画像の最適化です。
デザイナーとしては、画像はできるだけ綺麗にユーザーに届けたいですよね。
しかしあまりにも高解像度の画像を使用すると、ページの読み込み時間が大幅に増加します。
できるだけ見た目は綺麗に保ったまま、軽い画像を使用するのは非常に重要です。
速く効率の良い書き方
また、先ほどコードを書いてWebサイトやアプリを動かすとお話しました。
このときのコードの書き方次第でもパフォーマンスは大きく変わります。
具体的なテクニックの話はしませんが、同じ動作をさせるなら速く効率の良い書き方をする必要があります。
見栄えとパフォーマンスのバランス
更に、見栄えとパフォーマンスはしばしばトレードオフの関係になります。
例えば、リッチなビジュアルやアニメーションをふんだんに使うと、ページの見た目は美しくなりますが、読み込み時間が増加してしまう可能性があります。
一方で、あまりに軽量化を重視すると、見た目の品質が低下してしまうかもしれません。
このバランスを取るためには、パフォーマンスを意識したデザインを初期段階から取り入れることが重要です。
例えば、必要以上に大きな画像やリッチなアニメーションを避け、パフォーマンスに優れたデザインを選択します。
見栄えとパフォーマンスを両立させるために、常にどちらも考慮しながら進める必要があります。
パフォーマンス向上の意義
パフォーマンスはオンスクリーンデザインにおいて、見た目や機能と同様に重要な要素です。
特に、読み込み速度や操作の滑らかさは、ユーザーの満足度や利用継続率に直結します。
パフォーマンス最適化を意識しながらデザインと実装を進めることで、ユーザーにとって快適で信頼性の高いプロダクトを提供できるようになります。
デザインシステム
次に、デザインシステムについてです。
デザインシステムかコンポーネントライブラリなどの定義、境界などについて、この記事では細かく扱うことはしていません。ご了承ください。
Webやアプリをデザインする時、1人で全てを作ることはほとんどありません
特に大規模なプロジェクトでは、多くのデザイナーや開発者が協力して作業することが一般的です。
そんな時に問題となるのが、デザインや実装の一貫性です。
例えば、デザイナーAの作ったボタンとデザイナーBの作ったボタンが微妙に異なっていると、ユーザーは違和感を感じますし、使い勝手が悪くなってしまいます。
また、UIの色、フォント、サイズがページごとに異なると、全体として統一感のないプロダクトになってしまいます。
これを防ぐために、多くのチームでは「デザインシステム」を導入しています。
デザインシステムとは、デザインのルールやガイドラインを定めたドキュメントやツールのセットのことです。
たとえば、ボタンはこのサイズ、色、フォントで統一しましょうとか、アイコンはこの種類を使いましょう、というようなルールを定めて、全員がそれに従ってデザインを進めていきます。
これによって、どのデザイナーがどの部分を担当しても、見た目や操作感に一貫性が保たれます。
さらに、デザインシステムは開発者にとっても重要です。
デザインが一貫していれば、開発者もそれに基づいて統一されたコードを書けるので、実装もスムーズに進みます。
最近では、多くの企業が自社のデザインシステムを公開しており、有名なものにGoogleのMaterial DesignやAppleのHuman Interface Guidelinesなどがあります。
これらは、あらゆるプロダクトに共通するデザインのルールを定めており、誰が作っても一貫したデザインを実現できるようになっています。
デザインシステムの導入によって、デザイナーや開発者の間でのコミュニケーションがスムーズになり、結果としてユーザーにとっても使いやすいプロダクトが完成します。
特に、大規模なプロジェクトや複数のプロダクトを並行して開発する際には、デザインシステムが重要な存在となっています。
デザインプロセス
ここまで、オンスクリーンデザインにまつわる考え方を個別に話してきましたが、制作プロセス全体についてもお話します。
あくまで一方通行のものではありませんが、便宜上ステップに分けて説明します。
ここで紹介するものはあくまでプロセスの一例であり、これがベストであるとか、どんな組織でもこうするべきだ、という意図はまったくありません。
リサーチ
まず最初に行うのは、リサーチです。
どのようなユーザーがそのWebサイトやアプリを使うのか、どんな課題やニーズがあるのかをしっかりと調査することが重要です。
この段階では、競合サイトやアプリの調査（競合分析）や、実際のユーザーの行動を観察する（ユーザーリサーチ）ことが行われます。
コンセプト決め
リサーチをもとに、コンセプトを策定します。
ここでは、どんなデザインの方向性にするのか、どんな機能を持たせるのか、ゴールを設定します。
コンセプトがしっかりしていれば、後のデザインフェーズでも迷わずに進められます。
ワイヤーフレーム
次に、デザインの骨組みとなるワイヤーフレームを作成します。
ワイヤーフレームとは、Webページやアプリの構造や要素をシンプルに表したレイアウト図のことです。
この段階では、細かいデザイン要素（色や画像、フォントなど）は省略し、画面のどこに何が配置されるかを大まかに決めます。
ワイヤーフレームを使うことで、ページのレイアウトが合理的か、ユーザーがスムーズに操作できるかを確認します。
この段階でユーザビリティの問題があれば修正しやすく、完成度を高めることができます。
プロトタイプ
次に行うのが、実際にユーザーが操作できる試作版、つまりプロトタイプの作成です。
プロトタイプは、デザインが完成する前に、ユーザーがどのようにページを操作するかをテストするためのツールです。
この段階では、ワイヤーフレームをさらに発展させ、基本的なナビゲーションやボタンの動作など、インタラクションの部分を組み込みます。
この段階で作るものは特にローファイプロトタイプ、と呼ばれることもあります。
（その場合、ビジュアルデザインが終わった後のほぼ完成版をハイファイプロトタイプとして対に扱うこともあります。）
この段階でユーザビリティテストを行い、ユーザーがどこでつまづくか、どの操作がわかりにくいかを確認することができます。
プロトタイプは、実際のUIに近い見た目を持っていることが多いため、ユーザーからのフィードバックも具体的なものになりやすいです。
ビジュアルデザイン
次に進むのは、ビジュアルデザインの作成です。
この段階では、色、フォント、画像、アイコンなどを使用して、実際のデザインを作り上げていきます。
ビジュアルデザインの目的は、ブランドの一貫性を保ちながら、ユーザーに視覚的な魅力を提供することです。
ここで重要なのは、デザインが単に美しいだけでなく、ユーザーにとって直感的で操作しやすいものであることです。
例えば、ボタンのサイズや配置、色の使い方によって、ユーザーの注意をどこに向けるかが決まります。
また、フォントの選び方や文字の大きさは、可読性に直接影響するため、ユーザー体験に大きく関わります。
コーディング
デザインが固まったら、次は実装（コーディング）の段階に移ります。
ここでは、フロントエンドの開発者がデザインを実際にWebやアプリ上で動作するようにHTML、CSS、JavaScriptを使って実装していきます。
デザインと実装の段階では、密接なコミュニケーションが重要です。
デザイナーと開発者が緊密に連携することで、デザインが実際に機能として具現化され、ユーザーに正しく届くことが可能になります。
また、この段階でパフォーマンスの最適化を考える（読み込み速度や操作の滑らかさを保つ）のが非常に重要です。
テスト
実装が終わったら、実際のWebサイトやアプリをユーザーにテストしてもらい、フィードバックを集めるテストフェーズに進みます。
この段階では、ユーザビリティテストやバグチェックを行い、想定通りの動作ができるか、ユーザーの期待に応えられているかを確認します。
テストの結果を基にして、必要な修正や調整を加えていきます。
この段階で集めたフィードバックをしっかり反映させることが、完成度の高いデザインを実現する鍵となります。
リリース
最後に、テストが終了し、デザインと実装が問題ないことを確認できたら、Webサイトやアプリをリリースします。
しかし、リリースがゴールではありません。
保守・改善を続けることで、ユーザーのニーズの変化やテクノロジーの進化に対応し続けることが重要です。
リリース後も、定期的にユーザーの声を反映し、改善を繰り返すことで、プロダクトの品質を保ち、ユーザーの満足度を高めていきます。
全体像
このように、デザインプロセスは
リサーチ→ワイヤーフレーム→プロトタイプ→ビジュアルデザイン→実装→テスト→リリース
という流れで進行します。
とは言え途中で記載したように、完全に一方通行ではありません。
例えばビジュアルデザインの内容をプロトタイプに反映させるとか、実装後にビジュアルデザインの内容に戻るとか。
細かい違いや行ったり来たりを含めると実際はたくさんのパターンがあります。
とは言え、おおまかにはこういったプロセスを踏むのだと理解し、各段階で考えるべきことを漏らさないようにするのが重要です。
まとめ
オンスクリーンデザインデザインは流動的、スクリーン上の表現、インタラクティブ、状態を持つなどの特徴があります。
UIはユーザーインターフェースの略で見た目や操作部分に関わり、UXはユーザーエクスペリエンスの略でその操作を通じてユーザーが得る体験に関わります。
オンスクリーンデザインではユーザーが操作することは前提のため、どう操作するか？そしてその操作に対してどんな反応が返ってくるか？を考える必要があり、これがインタラクションデザインです。
ユーザーがどんなデバイスで見ているか分からないからこそ、どれでも対応できるようにレスポンシブデザインがあります。
オンスクリーンデザインにおいては障害のある方や老人などでも等しく使えることは重要であり、誰もが使えるか？という概念がアクセシビリティです。
一方でユーザビリティは、情報にアクセスはできるという前提で、どれくらい使いやすいか？の概念です。
このように色々と考えることも多いため、いきなり本番相当のものを作るのではなくまずは簡単に、動くものから作って試すような作り方が主流で、それをプロトタイピングと言います。
オンスクリーンデザインの場合はデザインツールで作っただけではまだ顧客が実際に使える状態にありません。
手元のデバイスで使えるようにするためにはコーディングが必要です。
動いてはいても、動作や読み込みが遅いと誰も使ってくれなくなってしまいます。
そのため、オンスクリーンデザインにおいてパフォーマンスは非常に重要です。
ここまで話してきた内容を1人で作ることはなく、複数人で作るのが基本です。
そのため、誰がどこを作っても同じルール、クオリティになるようにデザインシステムというものを用意する場合も多いです。
これらを実際に制作するプロセスとしては、リサーチ→ワイヤーフレーム→プロトタイプ→ビジュアルデザイン→実装→テスト→リリースといった順番になります。
謝辞
今回記事の投稿を快諾してくださったトライデントコンピュータ専門学校様、名古屋学芸大学様、心より感謝申し上げます。