UIデザイン再考――UIデザインの3要素と仮説精度|連載モジュールデザイン3

2016年6月8日

こんにちは、rdlabo.incの榊原です。
先日開催された「FRONTEND CONFERENCE 2016」で、『グロースハックを実現する「モジュールデザイン」とCSS設計』というタイトルで登壇しまして、そこで話したこと、話したらなかったことを連載形式で紹介します。

第一回 Webデザイン再考ーー紙面デザインとの対比からみるWebデザイン
第二回 UXでWebデザインを評価しようーーいいWebデザインとは何かを考える
 
今回は、UIデザインを3要素にわけて、その仮説精度から「UIデザインにとって重要なこと」を考えていきたいと思います。

 

UIデザインとは

UIは、「ユーザインターフェイス」を指します。ちょっと昔だと、同じものを指して「インターフェイス」とか「I/F」とかいろいろな表記がありましたが、最近はUIに一本化された感じがありますね。
 
よくUIを説明するときに、自動販売機の例が用いられます。どこから硬貨を入れるか、どうやって入れるか(入力)、商品を選択する(入力)、商品がでてくる(出力)、というようなユーザが関わる部分をUIといいます。ちなみに、WebのUIを指して、Web User Interfaceといって、技術・性質・構成で考えた時代もありましたが、IoTなどがでてきてWebのUIもWebに留まらないことからあまり使われなくなりましたね。
 
話を戻しますと、UIはユーザが関わる部分ですので、例えば「ボタンをクリックしたあと、それがRestAPIに飛んで、RestAPIのInterfaceがModelに値を引き渡し、(中略)、結果が画面に表示される」という処理があったとしたら、UIは「ボタンをクリックする」「処理待機」「その結果が表示された」の3段階でしかなく、ユーザがかかわらないバックグラウンドの処理はUIとはいいません。
けれど、そのボタンがどこにあるのか、どういうデザイン・表記で案内されているのか、押した後の処理中はどう見せるのか(停止なのかローディングアイコンを表示するのか)などなど、ユーザに接している部分(接地点)はすべてUIということができます。
 
ですので、UIデザインとは、「ユーザとWebとの接地点をどのようにデザインするか」ということができます。
 

UIデザインの構成要素

とはいえ、「ユーザとWebとの接地点をどのようにデザインするか」だと対象がぼやけすぎて、UIデザインについての言語化ができていません。ですので、実務からみてUIデザインを3つの構成要素に分割して詳しくみていきましょう。「1. 情報設計、2. グラフィック、 3. アニメーション」であり、本稿でそれぞれについて詳しくみていきます。
 
スクリーンショット 2016-06-08 13.28.40
 

1. 情報設計

UIを設計しようと思うと、まず何からはじめますか??
大体の人は構造図を書くところからはじめるかと思います。階層型にするか、直線型にするか(詳しくは「5つのサイトストラクチャ(Webサイト情報構造)を実際のサイトと照らしあわせて考える」をご覧ください)。
 
それが決まったら、トップページを用意して、会社情報をおいて、問い合わせページも必要だな、とサイト構成を考え、そのあとトップページにはこの情報を用意して、この情報はここに置く、とワイヤーフレームを手元で書き出す人がほとんどではないでしょうか。クライアントビジネスの場合は、この時点で一度承認をもらったりもしますよね。
 
理論と実務に乖離があることを承知の上でいうと、本来このあとに、ワイヤーフレームを元にしてモックアップを作成します。
ワイヤーフレームの小見出しは<h1>なのか、<h2>なのか。リストは<ul>と<ol>のどちらで実装するのか、sectionとdivどちらなのか、とざくっとマークアップを行います。
 
ちょっと実感を持てない人は、お気に入りのサイトをCSS抜きで表示してみて下さい。GoogleChrome拡張の「Pendule」を入れると簡単にCSSを無効化することができます(詳しくは「今更聞けないChrome拡張「Pendule」の使い方」をご覧ください)。
例えば弊社Webサイト(http://rdlabo.jp/)だと、以下の通りになります。
 

CSS適応時

スクリーンショット 2016-06-08 13.49.35
 

CSS無効時

スクリーンショット 2016-06-08 13.49.05
 
このCSS無効時の画面をつくるのが、「マークアップ」という情報設計です。HTMLのマークアップは、CSSを適応するための土台づくりという一面に注目されることが多いですが、本来は文章構造にしたがって適切にマークアップしていく作業であり、情報設計のひとつに分類されます。
 
で、ワイヤーフレームとマークアップに沿って、BootStrapやFoundationといったCSSフレームワークをつかってモックアップを作成します。そのモックアップを元に、サイト構造・構成、モックアップが適切であったかを検討するというこの一連の流れが、情報設計に部類されます。
 

2. グラフィック

「デザイン」といったら、グラフィックを皆さん最初に想像するのではないでしょうか。
UX,ペルソナに沿った配色パターン・トンマナ(トーン&マナー)の決定からはじまり、デザインパターンの作成、レイアウトの基本である「整列・グルーピング・余白・コントラスト」による情報設計の強化といった「見せ方」の作りこみを行います。
 
ネットゲームやテレビゲームでキャラクターをつくる時に、髪型や髪の色などを変更することができます。エンジニアな筆者としましては、モックアップまでできている情報設計(キャラクター)に当てはめるための外見がグラフィックデザインのイメージを持っています。

スクリーンショット 2016-06-08 14.44.19
 
Webデザインをはじめたばかりの時は、情報設計とグラフィックをごっちゃ――――というか、グラフィック優先で「見栄えがいいから、この要素はこっちに置こう」とかしがちですが、この二者は密接に関わりながらも別物ですので、それを意識しながら設計する必要があります。
 
グラフィックを専門の人が行う場合は、IllustratorやPhotoshopなどのグラフィックソフトでつくったあとで、それを元にコーディングを行う場合がほとんどです。ちなみに、グラフィックが苦手なエンジニアが行う場合は、モックアップに直接手を入れながらデザイン案をつくったりという無茶をやったりします。
 

3. アニメーション

jQuery登場以降、アニメーションはUIにとってなくてはならないものになりました。
例えば、ひとつ下の階層に遷移する時は右から新規ページが表れて、上位階層に戻る時は左から元のページが表示されるといった「処理の明示化」であったり。もっとみなさんが親しみがあるのは、「上に戻る」ボタンでしょうか。一瞬で上に移動すると、ページ内移動なのか、ページ遷移なのかの区別がつかないので、上に戻るアニメーションを表示することによって、ページ内移動であることを明示的に表現します。
ローディング画面に代表される非同期な処理がバックグラウンドで行われていることを表現したりと、現在のUIとアニメーションは密接に関わっています。
 
アニメーションは、ほとんどの場合において、モックアップ作成後に検討されます。密接に関わっている反面、「なくても、動作はする」ので、プラスオンというポジションでみるのが素直です。
そういう意味では、情報設計という下地に、グラフィックというレイヤーを重ね、その上にアニメーションを乗せると考えると、この三者の役割がイメージしやすいかもしれません。
 

おまけ:実務的な話

実務においては、特にクライアントビジネスでWebサイトをつくる時、ワイヤーフレームの承認をもらったら、グラフィックをつくって、そのあとグラフィックを実現するためにマークアップ作業とCSSコーディング――――というように情報設計段階におけるマークアップ、モックアップとそのレビューは省略します。
工数削減工数削減。
 
 

仮説精度を考える

第二回の「UXでWebデザインを評価しようーーいいWebデザインとは何かを考える」で「UIとUXの関係は仮説と検証」だと書きました。
その視点に立つと、UIの3要素は、仮説を3つに分類して作成・検証することになります。しかしながら、実際実務をまわすとわかるのですが、この仮説精度はそれぞれで全く異なります。具体的には、情報設計の仮説精度がどうしても低くなってしまうのです。
 
スクリーンショット 2016-06-08 15.26.48
 
特に情報設計の中でも、ワイヤーフレームレベルでの「パーツの配置」についての仮説精度は最悪です。ここにこのパーツを置いたらクリックしてもらえる、最初に目を通してもらえる、という仮説外れまくります。ですので、パーツの配置についての基礎知識と、外れまくった実例を紹介しようと思います。
 

1. 巨人の肩に乗ろう|パーツの配置

パーツの配置に限りませんが、パーツの配置はGoogleやAmazonといった巨人の肩に乗ることが前提となります。
例えば、ユーザは当たり前のように左上にロゴを探して、トップページに戻る時はそのロゴをクリックしようとします。これは別にWebのルールであるわけでも、Webの規格をつくってるW3Cが推奨しているわけではなく、GoogleやAmazonという有名サイトと、それを見習った他のWebサイトによってユーザが学習した結果なのです。
ユーザは、学習項目があまりに多いWebサイトは「使いにくい」と判断します。ですので、パーツの配置を考える時は、まずは同類型のサイト群の「しきたり」を参考にすることが重要です。
 
スクリーンショット 2016-06-08 15.40.47
 

2. ユーザは思い通りには動かない

といって、同類型のサイト群のパーツの配置を参考にしても、仮説は外れまくります。ユーザは思い通りには動きません。おそらく筆者の力量の問題もありますが、それでもこんなに想定外の動きをしなくても・・・・。
いくつか、具体的事例をご紹介します。随分前に開発した、まちづくりをeラーニングで学ぶ「AirLec」というサイトの事例です。
 

タイムラインは見ないよ

最初、eラーニングを受講するためにログインしたら、必ずタイムラインを表示するようにしていました。強制的にタイムラインをみることによって、他の受講生の進捗であったり、ユーザのレポートへのコメントであったりをみる習慣をつけてもらうことが意図でした。
スクリーンショット 2016-06-08 15.43.20
 
しかしながら、これが見ない。使い始めた時はみんなみていたのですが、どんどんタイムラインを表示しても中身を見ずに受講画面へ移動するようになりました。
 
そこで、もうタイムラインを見せることは諦めて、最初から受講画面に飛べるショートカットをつくった代わりに、右上にそのユーザにとって重要なタイムラインについては「通知」がいくように変更しました。そしたら、ちゃんと見るんですね。仮説が外れたために、変更した一例です。
 
スクリーンショット 2016-06-08 15.43.38
 

でも意外にパーツ自体には気づきます

こちらは、仮説として「チケットを使うときはユーザがUIに慣れない初期だろう」「どこから使うかわからないだろう」ということで、「チケットを使う」というボタンをHeaderに置きました。ここにあれば、分からないということもないだろうと。
 
スクリーンショット 2016-06-08 15.50.34
 
しかしながら、ユーザが使う様を観察していると、本機能はHeaderにある必要はない。ダッシュボードにあれば気づけるというか、「使ったら得するんだからちゃんと探して使うし、容易に見つけれる」様子がわかりました。けど、どこにあるかというより、「チケットって何?」と。「チケット」よりも「クーポン」の方が得する感じがするし、ちゃんと使う、と。うん、仮説の時は全く出てこなかったよそんな考え。
 
スクリーンショット 2016-06-08 15.52.56
 

3. まぁ、びっくりするぐらい仮説は外れます

上記なんて極々一例で、特にアプリの情報設計を行ったことがある人は「こんなに外れるのか」と日々実感していると思います。
そして、それはUI作成中にはどうしても気づけずにα版であったり、リリース後にユーザを観察・解析してようやく気づけるものばかりです。ですので、理想の世界としては「UI完成した!コーディングも終わった!あとはリリースして終わりだ!!」なんですが、現実的には、公開後にUI修正の本番がやってきます。
 
スクリーンショット 2016-06-08 16.05.51

冗長的UIデザインを行うために

少し長くなりましたので、一旦ここまでの論を整理しようと思います。

  • UIデザインは、情報設計、グラフィック、アニメーションに分けることができる
  • 情報設計の上にグラフィックがきて、そこにアニメーションが乗っかるレイヤー構造
  • 仮説であるUIの中でも、情報設計――――特にパーツの配置は仮説精度がめちゃくちゃ低い
  • だから、実際はローンチ後こそUI修正の本番がやってくる

で、ここで改めて見つめないといけないのは、「Webデザイン再考ーー紙面デザインとの対比からみるWebデザイン」で述べた「Webデザインは修正されるものである」という現実です。仮説検証のサイクルをまわせばまわすほど修正が入り、しかもその仮説検証の精度が一番低いのは土台となる情報設計です。
つまりは、UIデザインをガチガチにすればするほど、土台の部分が変更される可能性があるので、待っている将来は悲惨です。WebのUIデザインを考える時は変更可能性に優れた――――言い換えると、冗長的なデザインである必要があります。
 
では、冗長的なデザインとはどういったものでしょうか。実務的なところから考えますと

  • 一箇所を変更して、予期しない部分まで変更が入らない
  • 一箇所を変更すると、同類型のパーツは全て変更される
  • 最小の変更は、最小の人員で行うことができる

という条件を満たし、仮説検証を小さく回す必要があります。もっと実務的なことをいうと、HTMLごとパーツを使いまわせるUIデザイン・コーディングが必要です。
私は、それを実現するためには、UIデザインはデザインのみではなくコーディングまでの範囲を見据えることによって成立すると考えています。コーディングがわからないと、どうやってパーツを使い回すか、パーツの最小単位をどうしよう、といったことを考えることはできませんので。

「仮説が外れた→情報設計を変更する→パーツの使い回しができない→デザイナーにデザインからやり直してもらう→コーディング」
 
ではなく

「仮説が外れた→情報設計を変更する→パーツの使い回しでコーディング」
 
を実現するための技術が求められるのです。
実際に、AirLecでは、以下のような、かなり大きな変更を何度か行っていますが、デザインどころかほぼCSSも使いまわして、これを実装するために書いたCSSはごくわずかでした。
 
スクリーンショット 2016-06-08 16.19.27
 
ですので、UIデザインにおいては、3つの構成要素から実装、その仮説精度まで一貫して考えることが一番重要ではないかと思っています。「FRONTEND CONFERENCE 2016」で実行委員長が「デザイナーはコーディングを学んで欲しいし、エンジニアはデザインを学んで欲しい」といってたのがまさにその通りで、自分の領域だけではなくプロジェクト全体を見据える力が冗長的なデザインを生み出すのではないでしょうか。
 
 
そうはいってもここまでscratchで一貫して見つめるのは現場において現実味は薄いので、次回はこれを実現するための「デザインのモジュール化」とその手法についてみていこうと思います。
 
それでは、また。
 
[追記] 上記で変更例として紹介したAirLecですが、水交デザインオフィスの深沢さんにグラフィックデザイン – デザインパターンのコーディングまでやっていただいておりますー。