今回から、UIデザインについて、お話させて頂きます。
UIデザインとはユーザー・インターフェースを意味します。
分かりづらい概念ですが、実際はシンプルです。
みなさんは、日々、色々な道具を使っていますよね。
例えば、テレビやエアコン、スマートフォン。
他にも、パソコンや洗濯機など、たくさんの道具に囲まれています。
UIとは、そうした道具のうち、人間が触れ、操作する部分です。
例えばテレビのリモコンなら、ボタン配置の面。
洗濯機なら操作パネル。
スマートフォンなら画面。
パソコンならディスプレイに表示されたツールやキーボード。
テーブルならテーブルの面がそうですし、ソファーなら座る面です。
このように、道具のうち人間が操作したり、触れたりする箇所がUIです。
そして、操作したり触れる面のデザインを、UIデザインと呼びます。
WEBサイトであれば、見た目と機能もUIですね。
WEBサイトやアプリであれば、いかに使いやすくわかりやすいか。
情報が伝わりやすく、把握しやすいか。
UIのデザインによって、便利さも売上も大きく変わります。
UIデザインの概念はどこから始まった？
道具との接点がUIですから、UI自体は道具が生まれた時から存在します。
ただ、UIという概念が確立されたのは、近年に入ってからです。
特に今、みなさんが使っているパソコンやスマホの画面。
ディスプレイで表示するUIが開発されたのは、1973年のことです。
それまでコンピューターと言えば、コマンドでの操作が一般的でした。
みなさんのパソコンにもコマンドで操作するアプリが入っていますね。
ターミナルやコマンドプロンプトです。
1973年までは、コンピューターは文字を打って操作していました。
すべてが変わったのは、ゼロックスのパロアルト研究所からです。
Altoというコンピューターが生まれたのです。
Altoは世界初のGUI(グラフィカルインターフェース)コンピューターでした。
GUIとは今、みなさんが触り、操作している画面です。
文字ではなくグラフィックでコンピューターを動かせるUI。
それこそがGUIです。
開発を主導したのはアラン・ケイと呼ばれる人物ですね。
彼はGUIの第一人者として、数々の書籍を残しています。
ぜひ、読んでみると良いでしょう。
しかしAltoそのものは研究でしかありませんでした。
その後、スティーブ・ジョブズがAppleで技術を再開発。
Apple Lisaとして、世の中に送り出したのでした。
これが、現在に至るGUIの誕生です。
Apple Lisa自体は商業的に失敗しました。
ただしその後、Macintoshが誕生し、大きく成功したのです。
GUIになったことでパソコンは、誰もが使える道具に進化しました。
GUIの誕生は、パソコンが一般に普及する大きなきっかけとなったのです。
そして昨今、GUIはスマホからタブレットまで、幅広く使われています。
いずれも普及させたのはAppleでありスティーブ・ジョブズです。
彼がいかに優れたイノベーターなのか実感できる物語ですね。
UIデザインの流れ
では、具体的にUIデザインの制作方法に進みましょう。
今回はGUIを主に扱いますが、どのUIにも応用できるはずです。
そもそもUIとはGUIだけを扱うものではありません。
ソフトウェアからハードウェアまで、すべてUIデザインです。
機会があればWEBやアプリ以外にも挑戦してみてください。
具体的なUIデザインの方法は下記の流れで行います。
チームによって誤差はありますが、基本的な流れは似ています。
- 共感とタスク分析
- オブジェクト指向設計
- レイアウトパターン設計
- プロトタイプとユーザビリティテスト
- デザインルール策定
- ビジュアルデザインと実装
まず、ざっくりとご説明させて頂きます。
今回のカリキュラムは上記を順に追っていく内容です。
なので、目次みたいなものですね。
詳しい内容については次回から学習し、ここでは概要を掴みましょう。
共感とタスク分析
まず、ユーザーを徹底的に調べます。
すべてに共通することですが、ユーザー視点になることが大事です。
徹底的に調べ、ユーザーに共感しなければなりません。
共感したら、ユーザーが「何をUIで実現したいか」書き出します。
UIを使って、どんなタスクを完了することを求めているのでしょうか。
ユーザーが完了したいタスクをピックアップしましょう。
オブジェクト指向設計
ピックアップしたタスクを元に、UIの構造を作ります。
どんなページや機能を作るか考えるイメージですね。
WEBサイト制作で言えばサイトマップに近い部分です。
ここで大事なのがオブジェクト指向という設計思想です。
後ほどご説明しますので、今は言葉だけ覚えておいてください。
オブジェクト指向を使って、UI構造を設計していきます。
レイアウトパターン設計
構造の設計が終わったら、今度はレイアウトに落とし込みます。
WEBサイト制作で言えば、ワイヤーフレームのようなものです。
ただ、UIやオブジェクト指向の原則から、ある程度パターン化されます。
レイアウトなので、まだビジュアル(装飾等)のデザインは入りません。
大事なのはシンプルで分かりやすく、使いやすいことです。
プロトタイプとユーザビリティテスト
レイアウトが決まったら、いよいよプロトタイプを開発しましょう。
作るのはあくまでもプロトタイプです。
今後、何度も変更が加えられること前提でざっくり作ってください。
そして、実際にユーザーに使ってもらって、テストをしましょう。
繰り返し改善とテストを行って、少しずつ理想に近づけていきます。
プロトタイプでUIの精度を上げた後、本格的なビジュアル制作に入ります。
デザインルール策定
ここでは、他のデザイナー等と分業する場合もあります。
UIデザイナーが設計し、WEBデザイナーがビジュアルをデザインする。
そんな分業も、中にはあります。
WEBの場合、ディレクターがUI設計を担当しているかもしれません。
ともかく、他に手を動かすデザイナーがいれば、一緒に考えましょう。
どんな色が良いのか、どんな表現がいいのか。
ある程度デザインもルール化、パターン化、モジュール化します。
デザインのルールをまとめたものをスタイルガイドと呼んだりもします。
通常スタイルガイドづくりは、トップページの作成と共に行われます。
ページの全体像が分からなければ、ルールも決められません。
まずトップページを作って、デザインを具体化しましょう。
それから、トップページの要素にあわせて、ルールを決めます。
見た目のデザインと実装
ルールを作り終えたら、いよいよ本格的に見た目のデザインを作ります。
トップページは完成済みなので、ルールに沿って残るページをデザインします。
見た目のデザインまで終わったら、コードを書いて実装に進みます。
ただ、実装すると言っても今後、何度も改善が加えられる可能性があります。
いつでも改善できるように作らなければなりません。
HTMLやCSSの設計も、メンテナンス性が高い形で作りましょう。
こうしてUIは出来上がっていきます。
2種類のUIデザイン
大体の流れが分かったところで、今度はUIの開発思想です。
大きく分けてUIには2つの方法論が存在します。
タスク指向UI
最も初期の方法論とでも言えるでしょうか。
タスク指向とは、人間のタスクに沿ってUIを考える方法です。
例えば銀行のATMなどは代表例と言えるでしょう。
まず「何をするか」が基本となっていますよね。
ATMのボタンを確認してみてください。
振り込む、引き出す、預ける、といった「動詞」になっています。
これが、タスク指向の特徴です。
まず自分が何をするかという行動を選んで実行します。
主にユーザーのすべきことが確定している時に使います。
一方通行で、その他の動作を自由な手順で実行できません。
ATMも指定された手順以外は実行できませんよね。
厳格にすべきことが決まっているならタスク指向がうってつけです。
しかしタスク指向の弱点の1つが「ページが増える」ことです。
例えば、ファイル削除の機能を作ったとしましょう。
タスク指向では、最初「削除する」というボタンを押します。
それから「どのファイルを消すか選び削除」という流れです。
必ず最初に何をするかという動作を選ぶ必要がありますからね。
その分、動作を選ぶページが必要になるわけです。
結果、処理が煩雑になります。
そこで必要になるのが、オブジェクト指向UIです。
オブジェクト指向UI(OOUI)
タスク指向はユーザーの行動を「縛る」考え方でした。
一方で、ユーザーによって「自由に使って欲しい」時はどうでしょう。
すべてのUIが手続きのようなものばかりではありません。
例えばスマートフォンはどうでしょう。
全員が、まったく同じ使い方を必ずするわけではありませんよね。
カスタマイズや使い方は、ユーザーの自由です。
ユーザーの数だけ使い方があるのが、オブジェクト指向です。
現在の新しいUIは、ほとんどがオブジェクト指向と言って良いでしょう。
オブジェクト指向の場合、最初に選ぶのは名詞です。
あなたのパソコンのUIを見てみてください。
何かしたいと思ったら、まず自由にアプリを選びますよね。
「何を」したいかではなく「何で」したいかを選ぶのです。
上記も基本「名詞」を選んでますよね。
先程のファイル削除の機能を考えてみましょう。
OOUIの場合、まず選ぶのは「ファイル」です。
削除したいファイルを選択し、削除ボタンを押す。
機能を1ページで実装するので、よりシンプルになります。
iPhoneはもちろん、Photoshopもそうです。
Photoshopの場合、図形を移動させたい時に使うのは「移動ツール」です。
決して「移動する」ではありません。
「移動ツール」として用意することで、様々な移動がこれ1つで出来ます。
線を書く場合も「線を書く」ではなく「ブラシツール」です。
ブラシツールとして機能をまとめることで、これ1つで様々な線を引けます。
なんとなく、OOUIの設計思想についてイメージできたでしょうか。
今はまだ、なんとなくで構いません。
これからUIについて学んでいくうちに、理解できてくるはずです。
焦らず、じっくりと理解していきましょう。
人間中心設計 ( ISO 9241-210 )
UIを学んでいく上で、知っておいて欲しい言葉が２つあります。
まず1つが「人間中心設計」です。
人間中心設計とは「人間のための設計をしよう」という設計プロセスです。
かつて、アプリケーションを始めとして使いづらいものが膨大にありました。
というのも「機械で出来ることを軸に」設計が行われていたからです。
そこで、使いやすさを進化させるため、人間中心設計プロセスが生まれました。
機械のルールよりも「人間の活動に合わせてデザイン」すれば使いやすくなる。
そう考えて「人間中心で道具を設計する方法」プロセス化したのです。
考えてみれば、当然のことなんですけどね。
新しい概念とは「世界にその考えが無ければ」気づけ無いものです。
たとえ、今の世界では当たり前だったとしても。
1999年に人間中心設計は国際規格ISO13407として制定されました。
人間中心設計は1999年以前にもありましたが、広まってませんでした。
国際規格として制定された後、概念が広まったのです。
ただ、この頃の人間中心設計は、まだ発展途上と言えるでしょう。
開発プロセスや、UIの使いやすさ視点だけしか、含まれていませんでした。
今の形になったのは、2010年にはISO 9241-210へ改変されてからです。
ISO 9241-210は従来の設計プロセスに「UX」を取り込んだ内容となりました。
これで、単純な開発だけでなく「体験をどう作るか」も規格化されたのです。
人間中心設計プロセスには、6つの原則があります。
■ ユーザー、タスク、環境の明確な理解に基づいたデザイン
徹底的にユーザーを理解して、ユーザーがどんな問題を解決して欲しいのかを調べ抜き、ユーザーにとって使いやすいシステムにすること。
■ デザインと開発全体のユーザー参加
開発そのものにユーザーを交え、ユーザーと一緒にシステムを開発すること。
■ ユーザー中心の評価によるデザインの実施
開発者ではなく、ユーザーに評価してもらいながら開発すること。
■ プロセスの繰り返し
何度もプロセスを繰り返すことにより、精度を高めていくこと。
■ ユーザー体験(UX)全体に取り組むデザイン
UIや開発だけではなく、ユーザー体験のデザインを根本に意識すること。
■ 学際的なスキル・視点を含むデザインチーム
異なる学問や研究など分野をまたがって、横断的に活用できるチームであること。
このように、人間中心のシステム開発がルール化されているのです。
また、大事なのは原則やルールだけではありません。
人間中心設計は、規格化されたプロセスがあって大きな価値となります。
プロセスとは、システムづくりの手順そのものと言っても良いでしょう。
開発プロセスは、下記の4ステップで成り立ちます。
1つずつ説明していきましょう。
利用の状況の把握と明示
まず、情報収集と理解を深めるところからです。
どのようにユーザーがシステムを使うのか、把握します。
ユーザーの利用状況やシステムの使い方を具体化しましょう。
この段階の本質は「自分がユーザーの視点になること」です。
ユーザーに共感し、問題意識を共有できるまで理解を深めます。
単純に情報をピックアップすればいいというものではありません。
自分がユーザーとなり、同じ感覚で物事を考えられること。
問題意識に深い共感を感じられるまで、調べつくしましょう。
ユーザーと組織の要求事項の明示
次に、ユーザーがシステムに対して何を求めるのか具体化します。
一体、どんなタスクをシステムでこなしたいのか。
どんな問題が解決されたら、システムの価値が生まれるのか。
解決したい問題含め、ユーザーの欲求を書き出しましょう。
ここで大事なのが「言われたことがすべてじゃない」ということです。
人間は自分の本質的な欲求を、あまり上手く言語化できません。
例えば、パソコンが欲しいと言っている人がいたとします。
ところが、その理由が「動画を見たいから」ならどうでしょう。
もしかしたらタブレット端末でこと足りるかもしれません。
ユーザーが本質的にどんな問題に悩まされているのか。
何をユーザーは本質的に実現したいのか。
言葉だけではなく、本質的な課題に踏み込む必要があります。
本人でさえ言語化しきれない欲求を読み取りましょう。
設計による解決案の作成
ユーザーの要求が分かったら、今度は解決策を作ります。
見つけた問題や要求は、どうすれば解決できるでしょう。
具体的な解決策こそがUIUX、そして事業になります。
そしてプロトタイプを作成してください。
予算も時間も最小限、単純かつ簡単なもので構いません。
大事なのは、解決策が「有効だ」と判断できることです。
最初の試作で上手くいくはずもなく、その後、更新を重ねます。
要求事項に対する設計の評価
プロトタイプを使って得た意見を元に改良を続けましょう。
改良を続けた結果として、人間中心のシステムが誕生するのです。
誰もが一発で最良を出せるわけではありません。
何度も試行錯誤しているうちに、生まれるものなのです。
もし、それでも最良に行き着かないなら、最初に戻ります。
そもそもの前提が間違っていることもありえるでしょう。
改めて利用状況を把握し直してみてください。
知見が溜まった上で再度調べると、新しい発見も生まれます。
あとは、延々と同じサイクルを繰り返すのです。
以上が人間中心設計の基本プロセスです。
慣れることで、どんどん効率的にシステムを作れるようになるでしょう。
そして、この流れこそ、今の事業づくりの基本フローそのものです。
今後学んでいくことで、深く理解できていくでしょう。
ルックアンドフィール
UIデザインにおける基本思想とも言えるでしょう。
ルックアンドフィールというと「見て感じろ」と捉えられるかもしれません。
ただ、UIデザインにおいては意味が全く異なります。
ルック ( 見た目 )
文字通り見た目のことで、色やレイアウト、フォントなどを意味します。
見た目としてのデザインを指してルックと言います。
商品や企業のブランディングそのものと言っても良いでしょう。
良いルックなら、ひと目見ただけで、その企業を認識できます。
例えばApple製品はiPhoneやiMacなど、雰囲気が統一されていますよね。
一定の統一感を出すことで、ブランドが認識されやすくなります。
フィール ( 構造・機能 )
ボタンやメニューなど、機能や構造を意味します。
ユーザーが何か押せたり触れられたりする機能。
アプリであれば使い方そのものになります。
例えばサービスやアプリが変わっても、同じ構造を持つならどうでしょう。
1つその企業のアプリを使っていれば、即、他のアプリも使いこなせますよね。
構造や機能に統一感をもたせることで、習熟が早まります。
このように、ルックアンドフィールが備わったサービスは強いのです。
見た目でも認知されやすく、アプリもすぐに習得しやすい。
見た目も構造も、ブランドとしての価値を引き出すことができるでしょう。
もう1つの理由
ルックアンドフィールの優れているのは、見た目だけではありません。
近年、プログラミングで見た目と機能を分ける概念は一般的になりました。
例えばWEB制作もそうです。
デザインを表現するHTMLとCSS。
そして、会員登録など裏側の機能はPHPやRuby、Python。
この2つは、デザインとシステムを完全分離する考え方を基本とします。
ソースコードも、なるべく互いに交わらない設計にするのが基本です。
なぜなら、2つが入り交じると管理が大変だからです。
1つのファイルにHTMLとPHPがぐちゃぐちゃに混在していたらどうでしょう。
基本的にフロントエンドとバックエンドは異なる人が担当します。
数名が同時に同じファイルをいじることになっても、おかしくありません。
こうなると、ミスも増えますし、管理も面倒です。
何より、同時に作業もできません。
そこで、なるべく2つの構造を分離するような作りにします。
具体的にはフロントエンドとバックエンドを別ファイルに分離します。
分離されていれば、同時に作業することも可能です。
ミスも減りますし、管理も簡単になります。
何より、使いまわしが可能になります。
フロント側で必要な時に必要なシステムを呼び出せる状態を考えてください。
例えば、会員登録のページが3つ必要となった時を考えましょう。
1つのファイルにすべてのソースコードが混在するなら面倒です。
3ページすべてに会員登録のシステムを作る必要があります。
一方で、もしフロントとバックが完全に分離していれば。
会員登録のシステムを1つ作り、必要なページで呼び出せばいいだけです。
機能を別ファイルで作れば、適切に呼び出すだけで機能が実装できます。
何も3ページ分ソースコードを書く必要が無いのです。
こうした効率化やメンテナンス性を考えるのはUIも一緒です。
ルック(見た目)とフィール(機能・構造)を分けて考えること。
理解すると、メンテナンス性の高いUIの基本方針が作れます。
WEBデザインとUIデザインの違い
最後に、よく尋ねられる質問についてお答えします。
WEBデザイナーとUIデザイナー、一体何が異なるのでしょう。
WEBデザイナーも見た目をデザインする役割です。
UIデザイン全般も含まれると考えられても、おかしくありません。
実際のところ、WEBデザイナーはUIの「一部」を担当するデザイナーです。
今回ご説明した通り、UIデザイナーは構造から考えます。
しかし基本的に会社で働く場合、WEBデザイナーは構造をほぼ考えません。
担当するのは、あくまでも見た目として、どう良くなるかだけです。
まずディレクターと呼ばれる人が、レイアウトや企画を作ります。
そして用意されたレイアウトに沿い、WEBデザイナーがデザインを加えます。
基本的には上記の流れでWEBサイトやアプリは制作されます。
UIデザイナーの「構造」部分を担当するのは、主にディレクターです。
むしろディレクターのほうがUIデザイナーに近いかもしれませんね。
WEBデザイナーは主に「見た目」をデザインする人と言えます。
ルックアンドフィールのルックの部分ですね。
UIにおける「見た目」の仕事を担当するのが、WEBデザイナー。
明言はされていませんが、多くの場合上記の図式になっています。
また、UIデザイナーは構造だけ担当すると思われがちです。
実際はそうではなく、見た目のデザインも担当します。
WEBデザイナーの作業領域ですね。
むしろ、UIデザイナーがどちらも出来た方が良いでしょう。
なぜならユーザーインターフェースの使いやすさは装飾にも左右されます。
見にくい配色や混乱するデザインなら構造の良さも失われます。
ユーザーインターフェースの構造からデザインまで含めてUIなのです。
なので、特にWEB制作会社の場合、UIデザイナーの業務は分裂しています。
WEBデザイナーとディレクターが、2人で1人のUIデザイナーとも言えます。