Hatena::Groupoval-plan

思考地図:OVALPLAN このページをアンテナに追加 RSSフィード

2010-04-2610年品質のユーザインタフェース−その8

[][UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN

JR東海新幹線予約サイトのUI設計プロセス-8


f:id:OVALPLAN:20100426212752j:image:right

このマップはユーザ要望を俯瞰的に示したものですが、情報収集と分類を同時に行える大変便利な手法です。是非皆様も以下に示す方法で試して頂けると、その便利さがお分かりになると思います。(ユーザインタフェースコンセプトのプロセスと同時に思考地図の利用法も一緒に解説することになりますが、、、)


まず、ユーザの要望を軽く一人ブレストでいくつか出してみます。あまり多くなくて結構です。私がやるときは2〜3個アイデアを出した時点から次のステップにすすみます。もちろん多く出してからでも良いのですが、アイデアやニーズ収集というのは、自由想起型で行うと、個人の指向性がはたらいてついつい偏りが出てしまうもので、その意味からも最初のアイデア出しや要望出しは数個の少ない数でOKです。


次のステップは、アイデアを対概念(相対的意味)で捉えながら左右上下に配置します。仮に出したアイデアを相対的に空間に置いてみるのですが、その時役立つのが思考地図です。例えばこのマップでは、左右に認知-操作、上下に個人-社会を配置し、この2軸フレームをベースにさらにアイデア出しと分類を同時並行し、アイデアを展開していきます。2軸座標も固定的に考えるのではなく、抽出できた粒の要望やアイデア、それらの類似グループによって軸そのものも変更していくことも大事です。ただ、2軸の取り方は、思考地図の左右にPASSIVE-ACTIVE、上下にHOT-COOLの概念で構成することは大事で、具体的な軸の文言は2軸概念を踏まえていればいろいろと展開してみることも、全体のマップ完成度をあげるために有効です。(思考地図の軸については別のブログ参照して下さい)


その後のステップは、2軸座標の文言の展開検討と要望やアイデア出しを相互に繰り返し、グルーピングしながらそのグループのラベル、即ちグループにしている意味背景を文言化していきます。そのグルーピングがテーマにとって典型モデルとなれば、それがコンセプトです。複数のグループ間を相対的に考察していくことで、コンセプトの抽象度と典型性は高まり、普遍的な概念モデルとなります。


2軸座標をベースにしたブレーンストーミングと分類整理は、通常一人ではできないアイデアの広がりと、同時に素早い整理を実現してくれます。もちろん適切な2軸座標を適用することが前提ですが、同類を素早く見つけられてグルーピングが早い、座標軸とグループとの関係考察によって典型モデルが導ける、4象限全域を素早く整理できるので要望やアイデアの全体構成が見いだせる、そしてマクロな俯瞰を常にできるので網羅性が高いマップとなる、といった効能があります。


このマップでは4つの象限に一つずつの4つのコンセプトに分類していますが、もちろん2つ、3つ、5つ、子持ちを含んだ分類など様々なグルーピングができます。ちなみにこのグルーピングとそこから生まれたコンセプトは、JR東海新幹線予約サイトのユーザインタフェースの基本モデルとなり、基本構成はそのままに技術進化とともに細部の機能や画面は追加や変更が繰り返され、発足から10年のロングライフとなりました。JR東海様、有り難うございます。

2010-04-2110年品質のユーザインタフェース−その7

[][UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN

JR東海新幹線予約サイトのUI設計プロセス-7


f:id:OVALPLAN:20100421233143j:image:right

今日から数回にわたってユーザインタフェースコンセプトを導くための、具体的なプロセスについて書いていくことにします。事例としてはJR東海新幹線予約サイトですが、プロセスとしては汎用的な方法論として、多くのユーザインタフェース設計において有効だと思います。


ユーザインタフェース設計工程の最初は、ユーザ要求を収集するところから始めます。開発対象のユーザインタフェースがまだ世の中に事例がない場合は、そのユーザインタフェースが搭載されるシステムや機器の使われる場面を想定し使用シチュエーションを分解しながらブレーンストーミングしていきます。

既に類似のシステムや機器がある場合は、その事例を機能毎に具体的に使ってみて、使いにくいところに対する問題点と改良案を想起して要望を洗い出していくこともします。この時ヒューリスティック評価法で使うタスクを決めてウォークスルーしていくことも有効です。ただ、評価することを目的にタスクに添ってウォークスルーしたときは、評価対象の画面に対しての問題点や要望は抽出していけますが、タスクとは離れてもっとこんな使い方をしたい、といった新しい機能を発想していくような要望は、タスク型の評価では出てこないので、自由なブレーンストーミングを会わせて実行していく方がよいでしょう。

JR東海新幹線予約サイトの開発では、当時既に電話での予約受付はされていましたので、電話予約での利用をしているユーザを対象とした聞き取り調査をしていくことで、幅広い且つ電話予約で不便を感じていたことを解消するアイデアなどが拾い集めることができました。


こうしたユーザの要望を、細かなものから、大きな予約機能に及ぶものまで拾い集めていくブレーンストーミングは、際限なく集められそうで、どこで終わりにすればよいのか分からず、結局時間切れで終わりにする場合が多いものです。

つづく

2010-04-1110年品質のユーザインタフェース−その6

[][UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN

JR東海新幹線予約サイトのUI設計プロセス-6

「社会モデルの活用」というコンセプトから、「誰もが知っているモデル、カレンダーや路線図の利用」が導かれました。


f:id:OVALPLAN:20100412174500j:image


このコンセプトの元祖は勿論パロアルトのデスクトップをメタファとして捉えたGUIです。メタファという考え方は、他の世界で獲得した体験を喩えとして引用することで伝えにくい複雑な考え方を簡単に表現できるということで、とても自然な方法だと思います。その自然な考えをコンピュータとの対話に持ってきたことが、今日のコンピュータ文化を身近にした最大の功績ではないかと思います。もっとも、今時メタファや社会モデルをインタフェースとして活用することは、当たり前のことになってますので、こんなメタファの有り難みを感じるのは、初期のパソコンやワープロを四苦八苦しながら触れていた経験があるものだけの感謝の視点かも知れません。


さて、JR東海新幹線予約サイトにおけるメタファですが、

・日付指定にカレンダーを利用

・座席指定に座席一覧図を利用

・日本地図上に描いた新幹線路線マップ(これはまだグラフィックのみです)

いずれもメタファ(比喩)と呼ぶほどの例えではないかも知れませんが、コンピュータ黎明期と言わなくてもインターネット導入期のテキスト中心Web時代には、こんなグラフィカルUIは絶対通りませんでした。このプロジェクトが始まった10年前でも、Webアプリケーションで実装できるUIは、まだまだチェックボックスやプルダウンメニューが主流でした。


そう思うと当時としては大変先進的なWebUIを実現していたと思うのですが、今となっては当たり前???と思いきやさにあらず。例えばAmazonで本を買うプロセスを今すぐ辿ってみて下さい。


─検索窓にキーワードを入力、は店員さんに○○はどこですか?と問いかけか?

─出てきたリストは数千数百件の長蛇の列で、本屋の棚のボリューム感は想起できない

─表紙画像リストは本屋さんの平積みメタファの売れ筋感は見えない

─選んだ書籍の「こんな書籍も・・・」リコメンドは沢山あるが、書籍の中身は相変わらずのぞけない

─一冊買うにもカートに入れろ?

─カートを見ると今入れた本は文字だけになって、関連本のサムネールがやたらと並ぶ(知ってました?カートの中身表示ではサムネイル画像はないのです)どこがカートやねん!おこるよ〜(怒りのついでに、カートの中の本がどんな表紙だったかを見ようと選ぶと、該当書籍の詳細表示になりますが、その画面で右には[ショッピングカートに入れる]ボタンがデカデカと待機してます。これは私がUIデザイナーなら[ショッピングカート一覧に戻る]です。Amazonさんに誰か教えてあげて下さい。やれやれ、こんなせこいUIで2冊買いをさせる間違いを・・・私ともあろうものがしてしまったのです。しかも2度も・・・くやし〜)

─カート内の出し入れでも、いちいち画面書き換えしてますが、JR東海新幹線予約サイトでは、候補リストからの選択は一画面で処理してます。10年前からです。

─サインイン→宛先→???あれれ?商品確認とギフトは飛ばしいきなり配送ステップへ。なんでかな〜と戻ろうと思うと「本当にもう一度フォームを送信しますか?」アラートが表示される。サインインしてるのにもかかわらず、、、しかもクリッカブルなバスストップボタンかと思いきや、ナビゲーションは表示のみ。JR東海のナビゲーションボタンと雲泥の差です。

気持ちを立て直して戻って見ると、カート画面にギフトの選択チェックボタンが。ここのギフトチェックがされてるとギフトへ進行するが、、、商品確認はやっぱりとんだ!!!なんで、、、すごく焦りますよね。

─しかもギフトに遷移するとギフト包装300円!!!このステップをあらかじめ飛ばすために、カートでのチェックがあったのですが、でもいきなり配送ステップへ行って、その時にギフトしたいと思ってもカートまで戻らないとできない。しかもギフト画面に辿り着いたら300円?レコード屋さんでギフトパックしてもらって包装代取られたことないです!

─会計のクレジットカード入力も型どおり

─確認画面は文字だらけでなにがなにやら・・・

誤解のないようにコメントしておきますが、書店メタファーになれば嬉しいと言っているわけではありません。書店が画面上で出てきても、あの懐かしいSecondLifeと同じ事。デジタルだからできるパフォーマンスを人間の想像力と重ねたところに、ビューティフルなUIエクスペリエンスが創出できる、と考えています。


こんなAmazonがデファクトであることは、日本に取ってはありがたいと思うべきでしょう。さしずめこのAmazonは自動車におけるT型フォード。ユーザオリエンテッドなカローラやサニーが日本の道路を埋め尽くした60年代のように、真にユーザオリエンテッドなソフトウェアやサービスを生み出すのは日本です。ユーザ指向は米国からは生まれません。その理由は、創造者のジレンマがあるからです。(そんなことはない、あのアップルは世界中で指示されている?指示されているかも知れませんが本当にユーザオリエンテッドか・・・次回考察してみましょう)


10年品質のJR東海新幹線予約サイト、京都府観光情報システム、オムロン銀行ATM、ヒューマンインタフェース学会VI&ホームページ、(某企業のOA複合機UIの基本概念モデルを20数年前に開発し、現在も基本モデルは生き続けています)いずれも、人間の思考の空間配置原則を集積研究を続けてきた成果「思考地図」を使って概念モデル設計をおこなっています。


ロングライフを生み出す秘訣は、人間が望んでいる本質的な価値を探り出し、普遍的な概念モデルとして構築することです。「思考地図」を使ったUI設計プロセスなら、そんな概念モデルを設計することができます。

2010-04-0710年品質のユーザインタフェース−その5

[][UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN

JR東海新幹線予約サイトのUI設計プロセス-5


「使い込める実用性、機能性の提供」というコンセプトから、ユーザのサイクリックな利用の情報を活用する「いつもの列車を予約」メニューが導かれました。

f:id:OVALPLAN:20100407235654j:image

1.ユーザオリエンテッド要求仕様:いつも利用する列車を登録しておける、という機能は、UIコンセプトと言うよりはUI機能のコンセプトと言うべきかもしれません。すなわち、既に見ました「ステップナビゲーション」のような表示や操作の仕組みだけでなく、もっと上流のデータベースの構造にまで及ぶ機能提案だからです。会員毎のデータベースを持ち、ユーザ毎に自由に列車を登録しておいてそこから選択して予約できることは、繰り返し利用の多いビジネスユーザには有り難い機能です。


元々このコンセプトは弊社のユーザインタフェース指標フレームの中の「ユティリティ/使用性の拡張-個人への最適化」から生まれてきています。勿論ユーザニーズのブレーンストーミングからも得られるのですが、ユーザインタフェース視点から機能仕様を提案していくことは、UI設計を専門とする我々の役割でもあると考えているからです。そしてここで大事なことは、世の中にカスタマイズメニュー機能が既に存在しているから提案するのではなく、「自分に最適なものへ」という要求はユーザニーズとしてベーシックなものである、という確固たる知識から提案するのだ、と言う姿勢を、ユーザインタフェース設計者は持ち続けていることです。そうした設計者のプリンシプルによって、要求仕様設計とか要求開発といった構想設計をユーザインタフェース設計者が担え、結果的にそれがユーザオリエンテッドなものづくりにつながると考えます。


今でこそユーザカスタマイズ的な視点はユーザの囲い込み機能として当たり前のようになってきていますが、Webでのアプリケーションサービスが始まった頃としては、システム開発の現場にとってはリスクがある機能だったと思います。と言いますのは、これ以外にもダイレクトに空き席を見せて座席指定を実現したい(このサービスは当初は提案止まりでしたが現在実現されています)、とか見慣れた時刻表から指定したい、といったユーザ視点に立ったユーザインタフェースコンセプトを提案したところ、施主側のJR東海お客様係担当チームの皆様は大変喜んでおられました。インターネット予約としては後発となったが、こうしたユーザに喜んでもらえる仕様は是非実現したい、と言う方向性が、合同検討会で決定されていきました。


このように、ユーザインタフェースは、ユーザを代表する立場としてユーザインタフェース設計の専門家が要求仕様をまとめていくのが、良いユーザインタフェースを開発するためには重要なことだと考えます。もちろんシステム設計のエンジニアリング面を無視したようなユーザインタフェース要求を書いては、システムのリスク面から捉えても得策ではありませんし、最終的に施主にとっても嬉しい要求仕様とはなりません。あくまでも十分なシステム開発技術のノウハウを知った上で、ユーザを代表したユーザインタフェース要求仕様を書くと言うことです。良い建築を立てるためには、よい建築家が施主と施工業者の間に立って、建築というプロジェクトマネージメントを進める必要がある、と言うコンストラクション・マネージメントの仕組みが、米国では主流だそうで、同じようにシステム開発においても、施主とシステムインテグレータの間に立って、施主(ユーザ)とシステムインテグレータの両方の意見を吸い上げて最適なユーザインタフェース設計を行う、という、自立したユーザインタフェース設計ができる組織や人材があることが望ましいわけです。


建築の業界ははるかローマ時代にまで遡る歴史があり、そんな中から最適な分業システムが完成度高く作られてきています。ほぼこの建築業界システムを学ぶ形でシステム開発の世界も、プロジェクトマネージメントシステムを作ってきました。が、まだまだシステム開発の業界は歴史が浅く、建築業界のような設計と施工のバランスの良いシステムはできていません。特に建築業界での建築家に該当するユーザインタフェース設計家がいないというのが問題で、歴史は浅いのですがそろそろきちんとしたユーザインタフェース設計家を育てていく必要があると思います。そしてユーザインタフェース設計家に必要な素養はというと、まず先進的なシステム技術に明るいことと、このブログで紹介している概念設計ができるかどうか、だと考えております。


2.ユーザインタフェース技術:上記のユーザオリエンテッド要求仕様は、ユーザの立場を代表する要求を利用状況や機能の要望を調査する事によって導かれます。その時に必要なユーザインタフェース設計のシステムオリエンテッドな側面、例えば一瞥でも重要な気づきに役立つヴィジュアルエフェクトインディケーションを採用するとか、インクリメンタル技術を使ってユーザの操作ナビゲーションを提供する、と言った先進的でユーザに利益する技術を積極的に要求仕様に取り込む、ということです。もちろん闇雲に面白いからやってみようというのでは、結果的にユーザビリティの低いものになってしまいますので、全体のコンセプトにとって重要な役割があるかどうかの見極めは大事です。


JR東海新幹線予約サイトでも、当時としては技術サイドもあまり積極的ではなかった先進技術を我々ユーザインタフェース設計サイドから提案しました。今ではごく当たり前のJavaScriptです。複数の列車リストから選ぶところで、リストを何度でも選び直せるようにJavaの仕組みを取り入れたのです。当時HTMLで実装される技術では、通常一回オブジェクトをクリックすると、サーバへの問い合わせのセッションが始まって画面が切り替わりますが、列車候補のリストを選ぶ度に画面が切り替わるのは、ユーザにとっては嬉しくないのでJavaによるリスト選択の構造を提案したわけです。もちろんその動作がどのような体験かを施主にも分かってもらうために、Javaで作ったデモを持って行きました。簡単なプロトタイプやデモ画面は、そのユーザインタフェースを採用するメリット手早く伝えることができます。

このように、ユーザにとって利益するユーザインタフェースを設計するためには、時代の先端をいく技術についても明るくなければなりませんし、体験的にそうした技術による恩恵はどのようなものなのかを確認していなければなりません。もちろん同時にシステム設計や開発導入におけるリスクも学んでおく必要があります。

2010-04-0510年品質のユーザインタフェース−その4

[][UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - [UI Architecture][GUI][ユーザビリティ][UD][思考地図-周辺][小林] - 思考地図:OVALPLAN

JR東海新幹線予約サイトのUI設計プロセス-4


「ユーザのユースケースで選べる作法」というコンセプトからメインの三つの予約プロセスメニューが導かれ、サイトの入り口で提供する「エクスプレス予約メニュー」が創られました。


f:id:OVALPLAN:20100405191627j:image

1.ユニバーサルデザイン:ユニバーサリティは2000年の当時には既にユーザインタフェース設計現場では、一般的な理念として普及していました。ユニバーサルデザインが今ほど言われる前は、一般的には「イージーユース」というキーワードが使われていていました。ユーザインタフェースを設計するときの基本的目標として「イージーユースが目標です」とコンセプトには書いたものです。この時のイージーユースという考え方は、今となってはそんなの当たり前でしょうと思われるでしょうが、90年代のユーザインタフェース導入期では、「イージーユース」という言葉が標語として使われるぐらい、機器のインタフェースは使いにくいものであふれていました。だからまずはユーザビリティを評価して、課題を発見し、イージーユースを獲得しましょう、というユーザインタフェース設計の流れが一般化していったのです。そしてそのイージーユース指向を強力に後押しすることになった「ユニバーサルデザイン」が、当時共用品の推進やバリアフリーへの注目が始まったプロダクトデザインの現場と呼応して、ユーザインタフェース設計現場でも広がっていきました。

前置きが長くなりましたが、こうしたユニバーサルデザインの始まりの頃に、このJR東海新幹線予約サイトプロジェクトが始まりましたので、当然ユニバーサリティは重要なユーザインタフェースコンセプトの視点でした。

当時新幹線予約は既にJR西日本のインターネット予約で実行されていたのですが、当時の画面(添付参照)をご覧になれば分かりますように、予約プロセスのステップナビゲーションとその第1画面がトップページに配置されていました。実は当時インターネットを利用することそのものがまだ発展途上で、パソコン+Windowsの普及期ではあったのですが、実際の利用という面ではまだまだPCに対するリテラシーの差は大きく、この画面でチケットの予約がすいすいとできる人は限られていて、PCリテラシーの高いユーザを対象にしていたのです。JR西日本にとっては新幹線予約は何パーセントかのユーザの満足を得られれば良かったかも知れません。しかし、JR東海にとって新幹線予約はメインの中のメインユーザに向けてのサービスですので、PCリテラシーが低い人でも大いに利用してもらえる予約サイトでなければならない、と言う目標がありました。

そこで提案したのが複数の予約プロセスをメニューとしてシンプルに提供する現在のトップ画面です。


2.ステップ作法-山登りモデル:前回の「誰にも優しいステップバイステップ」3.サイトの構造システム(アーキテクチャ)でステップ作法については解説していますが、ここではユースケースとステップ作法との関係について解説します。

「いつもの列車を予約」「時間指定で予約」「列車名指定して予約」いずれも最終的には予約を実行すると言うことでは、同じ目的であり同じようなステップを踏んで決定していきます。新幹線のチケット予約ですから、チケットを予約するという目的は当然同じです。違うのはアプローチが異なるだけです。最終的に同じ座席指定になるかも知れませんが、アプローチが異なるということです。このようなモデルを山登りを例に話すことがあります。山登りは最終的に登頂する頂きは一点ですが、山登りの上り方や起点をどこにするか、途中の経路によってもルートは様々に異なります。この山登りモデルは複数のルートが有り、それぞれにユーザによって、ユースケースによって異なる、と言うモデルです。山登りのモデルのようにゴールは一点であっても複数のルートを提供する、と言うコンセプトはユーザにとっては選択枝が広がります。そしてそうした選択枝を並行的に同等の選択できるルートとして提供する、というルートメニューにしたことが、このJR東海新幹線予約サイトがロングライフを獲得している秘訣だと思います。

実はこの三つのメインのルートですが、そのルートの中身は10年の間に何度もバージョンアップが繰り返されています。使い続けている方はご存じだと思いますが、それぞれのルートの画面は、時代の要求と共に変化しているのです。その変化を受け入れられるきちんとした構造を設計できること、それがUI Architecture設計の要です。


f:id:OVALPLAN:20100405191619j:image

2010-04-0410年品質のユーザインタフェース−その3

[][][][][][][] 10年品質のユーザインタフェース−その3 - 思考地図:OVALPLAN を含むブックマーク

JR東海新幹線予約サイトのUI設計プロセス


「誰にも優しいステップバイステップ」というコンセプトから縦型のタブ構造のステップナビゲーションをUI概念モデルとして採用するに至った考察をご紹介します。


f:id:OVALPLAN:20100404102713j:image:left

1.人間の思考モデル:上から下への移動は現実世界の階段を下りていくというメタファとつながり、上位から下位へと順に細部へ分け入っていくモデルと一致します。水平の左から右へのステップナビゲーションと比較するとその階層感覚が全く違うことが分かります。水平というのは実は平等、対等といった関係性を示すときに使われる概念で、横展開、水平思考といった展開で使われる空間のモデルなのです。横の空間モデルでも左に始まりがあって右に終わりがあるスタート/ゴールのモデルで使われることもありますが、その場合でも、左から始まって右に行くに従って階層を下っていくイメージは無くはないですが強く意識されることはありません。上下の空間構造が持つ階層概念は、順に詳細を決定していくステップナビゲーションに最適といえるわけです。

まだまだ上下空間の持っている意味性と左右空間が持っている意味性には奥深いものが有りますが、この辺りの人間の思考モデルについては思考地図の解説をご覧下さい。


2.デザインの象徴性:パソコンやインターネット画面は、システムの表示構造が基本的に横組みです。Alphabetが横組みだというのが背景にあり、世の中に始めてグラフィカルUIが登場する以前のテキストでコマンド操作をしていた時代から、システム世界のレイアウトは横組みが基本です。皆さんは横組み以外に、すなわち日本の新聞や雑誌、書籍のような縦組みのユーザインタフェースというものを見たことがないかも知れませんが、実は以前リコーの学習用ソフト、その中の国語の学習をするためのユーザインタフェースを作ったことがありますが、そこでは縦組みのUIでした。確かワードプロセッサが全盛だった80年代には、日本製のシステム機器では縦組みの画面デザインもあったと思います。

話を戻しまして、下のマップをご覧下さい。このマップはJR東海新幹線予約サイトを設計していた2000年頃の日本を代表する企業のWebサイト画面を俯瞰したものです。こんな中へJR東海新幹線予約サイトが登場することになる、ということを踏まえ、デザインのアイデンティティを検討した結果、上から下への階層的タブ構造を左サイドに整然と並べ、ダークな紺色の上にくっきりとタブが浮かび上がるデザインが生まれたのです。さらにダークな背景にタブを並べることで、過去タブ、現在タブ、未来タブがしっかりと色分けできて、自然なナビゲーションを可能にしています。1.人間の思考モデルを象徴的なデザインに仕立て上げたビジュアルコンセプトワークがここにあります。ビジュアルアイデンティティの視点というのは、縦型のステップナビゲーションではなくても検討は可能ですが、縦型にこだわった背景として「ビジュアルアイデンティティをしっかり出せる!」という考え(コンセプト)が、重層的に見えてくることが大事だったわけです。(こうした蓋然性が感じられると言うことは概念設計では重要なことです)

一般的なWebサイトデザインでは、左サイドの縦スペースはカテゴリー分類に占拠される傾向があり、このJR東海新幹線予約サイトのような縦型のステップナビゲーションはあまり見かけません。その理由は、この予約サイトは新幹線予約の機能に特化しているからで、現在のポータル的な機能満載のWebアプリケーションと一緒に実現しようとすると、これほどのシンプルなアーキテクチャーは実現が難しかったかも知れません。


3.サイトの構造システム(アーキテクチャ):どんなに構造的な思考モデルがあっても、どんなにデザインの象徴性が高くても、サイト全体を俯瞰したときの構造システム=アーキテクチャとしてきちんと構成されていなければ、ユーザインタフェースとしては破綻します。JR東海新幹線予約システムで採用した縦型タブのステップナビゲーションが、サイトで実行する機能全体で一貫した作法となるよう構造が組み立てられなければ、良い概念設計とは言えないでしょう。予約、購入、変更、設定など中心機能を一貫したロジックのステップモデルに展開するには、ステップの粒度を揃えていく必要があります。粒度というのはステップ毎の表示内容とユーザ操作の範囲で、細かすぎると面倒なステップ進行になり、粗いと誤操作や思い違いが増えて戻りが増えてしまいます。システムの造り勝手とも絡めながらバランスの良いステップ構造を設計することは、根気のいる作業だと言えます。

ノウハウという意味では、この「サイトの構造システム」での見通しを早い段階で獲得できるか、がもっともロジカルな概念設計技術だと思います。(SEなど)システム開発に長けた人は、この全体を見通したシステムアーキテクチャ設計が最優先するために、シンプルな設計でいかにも使いやすそうなユーザインタフェースが設計できたと、勘違いされる場合が多いと思います。アーキテクチャー設計は、システムエンジニアリングの高級な技術ですし、ユーザインタフェースでも同じ事が言えるからです。しかしこの構造システムがいくらシステムとしてシンプルで、全体機能を包含していたとしても、上記の思考モデルやデザインの象徴性が欠けていれば、広くユーザに受け入れられるユーザインタフェースとはなりません。


4.UI設計の統合モデリング:ユーザの頭の中に形成される空間や時間の概念と合致しているか、表現されたデザインが象徴的なイメージとしてユーザに伝わるか、そして同じロジックでメインの複数の機能を束ねることができるか、をサイクリックに考察し続ける力、これがUI設計における統合モデリング力といえるものです。難解であればあるほど、要求が複雑なほど、パズルを解く喜びは大きいものです。そこにクリエイティブの魅力があります。と同時に破綻の落とし穴も待ち受けていますので、速やかな撤収再チャレンジの繰り返しが大事です。がしかし、ここ一番のコンセントレーションが、新たなブリッジに繋がることも申し添えておきたいと思います。


コンセプトからUIデザインへの流れを文章で紹介すると、なーんだそんなことか〜と簡単そうに思われるでしょうが、実際は言葉化できる範囲をはるかにしのぐ思考の厚みが要求されるものだということをお伝えしておきます。


f:id:OVALPLAN:20100404103149j:image


次回は、JR東海新幹線予約サイトのその他のコンセプトメイキングについて、ご紹介してみたいと思います。

2010-04-0310年品質のユーザインタフェース−その2

[][][][][][]JR東海新幹線予約サイトのUI設計プロセス JR東海新幹線予約サイトのUI設計プロセス - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - JR東海新幹線予約サイトのUI設計プロセス - 思考地図:OVALPLAN

f:id:OVALPLAN:20100403114941j:image:right

JR東海新幹線予約サイトの思考地図(別コラム参照)をベースにした設計プロセスが右の図です。思考地図で構成される4つの象限にそって、中心から外に向かって4段階のステップが示されています。現実の設計プロセスは紆余曲折や後戻りは沢山ありますが、どこのUI設計現場でもおおむねこんな4つ程度のステップで設計されていると思います。


1.ニーズ調査:新幹線予約はそれまでは電話での予約が中心でしたが、その予約をインターネットでセルフでできると言うことは、ユーザにとっては大変有り難いことで、我々設計者自身新幹線のヘビーユーザでしたので様々な意見、要望が収集できました。ところがこうした意見というのは、どこまで収集すればよいのか際限が無く困ることが多くあります。が、思考地図をベースに収集すると、収集している領域感が俯瞰できるので、アバウトなところで次のステップの整理するステップへ進むことができます。


2.ニーズ分析:沢山の意見を分類整理するには、一般的にはポストイットカードに書いてKJ法で分類,と言った方法が行われます。ところがカードが数百とかになりますと,ダブりやモレが多く、また分類自体が個人の指向性が強くなる、といった懸念もあります。

そこで、思考地図の左右上下のフレーム,例えば認知と操作、個人と社会といった縦横2軸を配して、その軸を背景に先ほどのニーズのカードを配置していきますと、グループのコンセプトが生まれ、容易にグルーピングできていきます。


(概念モデルの解説なのに、設計プロセスの話し?と思われるでしょうが、概念モデルだけを解説すると、なんだそんな事か、と思われてしまうので、そんな事という概念モデルが、どのような背景として浮かび上がるのかをお伝えすることが大事かと思いますので、今しばらくのお付き合いを)


3.コンセプトの読み取り:4つの象限に分類したニーズをグループ内の共通する意味や機能、関係性を考察するとそのグループに内在している暗黙知が浮かび上がってきます。あるときは上下左右の軸との意味関係、左右又は上下の隣グループとの違いと共通性、斜め対角線のグループとの対比、そして4つの象限グループの意味の相対性、などから基本的なニーズのフレームというものが発見されていきます。発見と言う感覚と創造という感覚とが同時にやってくるときは、かなり独自性豊かなコンセプトです、、、と思っていても、人に話すと大変地味で、そんな事は前から分かっていたことだ、という反応しか得られないことが有りますが、実は個性的なコンセプトは拒否される場合が多く、むしろ、こんな考えは誰でもするよな〜と思うけどまだどこにもない!と言うコンセプトの場合は、普遍性の高いコンセプトの発見と言えるときが多いと思います。少なくとも私の多くの経験ではそうでしたし、少なくともニーズの調査から出発してコンセプトを求めるときには、収集したニーズの中にコンセプトが暗黙知的に埋まっているのですから、それほどユニークな考えがそこで生み出されるという確率は低いでしょう。勿論競合が多く存在する分野のコンセプト開発では、最初からユニークなニーズ発掘が先に命題となりますから、その限りではありませんが。例えばシーズオリエンテッドなコンセプトメイキングの場合などです。(別の機会にシーズオリエンテッドコンセプト開発の説明もしたいと思います)


4.コンセプトのUI化:え?!コンセプトをUI化する?実はUI概念モデルというとすぐにデザインされた図像なり操作なりを想起される方が多いかも知れませんが、UI概念モデルというのは、デザインする以前に想起されるコンセプトモデルのことと具体的なUIデザインモデルの二つのことを指します。禅問答のように思われるかも知れませんが、両方ともコンセプトという表現では同じですが、テキストによって表現できるコンセプトと、図像を伴うコンセプトは異なります。(う〜ん・・・テキストと図像の両面=世界イメージを一気に示すスマートで美しいコンセプトというものもあるので一概には言えません、が、これもまた別の機会にお話しさせて下さい)

例えばこのJR東海新幹線予約サイトのコンセプトに「誰にも優しいステップバイステップ」というのがありますが、ステップバイステップというコンセプトは、予約の仕方を順序立てて始めから終わりまでをナビゲーションするステップが良いです、ということで、それに対してUI化は、縦に上から下へ進行するタブ型のナビゲーションUIデザインにした、ということです。ですので、ステップバイステップというコンセプトに対してUI化を検討する際に、もっと違ったナビゲーションも考えられると言うことです。例えば、ナビゲーション型のUIは、ECサイトの決済プロセスなどにあるような左右にボタンを並べるナビゲーションが一般的です。

では何故に縦型のタブにしたのか。そこがコンセプトをUIデザインに落とし込むところの重要なノウハウで、次回にその詳細を書いてみたいと思います。


こうして生まれたニーズコンセプトはユーザインタフェースデザインのコンセプトを導き、具体的なユーザインタフェースデザインが設計されました。

そして誕生したユーザインタフェースは、インターネット世界では類例のない10年の長寿サイトとなりました。

この結果から、この新幹線予約サイトのユーザインタフェースは「普遍的概念モデル」の設計だった、といえると思います。

2010-04-0210年品質のユーザインタフェース−その1

[][][][][]JR東海新幹線予約サイト JR東海新幹線予約サイト - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク - JR東海新幹線予約サイト - 思考地図:OVALPLAN


JR東海新幹線を利用されている方は多いので、この新幹線予約サイトを見慣れた方も多いかと思いますが、実はこの新幹線予約サイトはOVALPLANが開発して10年経ちます。デザインイメージ的にはちょっと古くさく見えますが、ユーザビリティ、ユニバーサリティ、ユティリティの3つのインタフェース基本性能は、10年経っても全く遜色なく、むしろ最近のWebデザインスタイルよりもシンプルで明快なデザインの良さが伝わってきます。

f:id:OVALPLAN:20100402223552p:image:right

ユーザビリティ、ユニバーサリティ、ユティリティの3拍子が揃ったUIだから10年の歳月を経てもいまだに現役でいられる訳ですが、ではその三拍子はどうすれば得られるのでしょうか。その秘密はOVALPLANの設計ノウハウの中にあるのですが、これがそのノウハウです、といって容易に示すことができません。特にそのノウハウの中の最上流としてOVALPLANでもっとも重要視しているのが、概念モデルの設計です。

ではその概念モデルとはどのようなものなのか、JR東海以外のロングライフの事例を交えながら紹介してまいります。

2006-11-14もっと大勢に参加してもらうには・DSギター

[][] Jakob NielsenのAlertbox  Jakob NielsenのAlertbox - 思考地図:OVALPLAN を含むブックマーク はてなブックマーク -  Jakob NielsenのAlertbox - 思考地図:OVALPLAN


参加の仕方は一様ではない:もっと大勢のユーザに書き込んでもらうには


Jakob Nielsen氏の記事です。


パレートの法則ロングテールといった現象は、UGC / CGMにも見いだすことができるということ、それが引き起こす問題と、その対策が掲げられています。


少々極端な書き方ですし、特に目新しい内容でもありませんが、最後の対策はUGCを志向するサービスにとって最低限のチェックリストとなりそうです。


ただ、具体的にユーザ個人にフォーカスして考える場合、この記事に書かれているようなユーザビリティの考え方は大変有効ですが、「UGC / CGM」においては、もっと大きく抽象的に「群」を捉えることが重要でしょう。


その際、ゲーム理論など、経済学の知見が役立ちそうに思えます。

特に、二番目「副作用を伴うようにする」、四番目「参加者に謝礼を。ただし、やりすぎないこと。」において、具体的な手だてをデザインするために。

大草大草2006/11/15 02:49
>最後の対策はUGCを志向するサービスにとって最低限のチェックリストとなりそうです

同感です。
二番目の「副作用を伴うようにする」については、多分訳し方が悪くて、「副作用として参加できるようにする」の方がいいかなと思います。
・アマゾンの推薦本:
  購入する→副作用として別の本をリコメンド
・アクセスカウンター:
  訪れる→副作用としてリードオンリーでも参加者にカウント
・ミクシイの「足あと」:
  訪れる→副作用として読者の存在を感じさせたり「足あと返し」を誘発
・はてなの「はてブ」「公開はてブ」・RSS登録:
  ブックマークする→副作用として人気記事ランキングに投票
・「公開はてブ」「共有ブックマーク」
  ブックマークを公開する→副作用としてユーザープロファイルとセットでサイトやページをリコメンド

もう一点、「結果や実行行為だけではなくて過程や保留行為も拾う」というのも追加してみたいです。(1.簡単に 2.副作用として ともかなりかぶりますが)
・アマゾンで「カートに入れたけど、今は買わない」:
  購入検討中リストに挙げておく→副作用としてユーザープロファイルをより正確に表明
 (意見表明して参加するところまでは踏み出さないが、
  自分用メモだけしておくと言う意味ではブックマークと同じ扱い?)
・DietTelevisionでの比較(実際には機能実装されていませんが…):
  微妙な比較行為を行う→副作用として主にどんな項目を比較しているか等のニーズを詳細に表明

川上川上2006/11/15 20:56>二番目の「副作用を伴うようにする」については、多分訳し方が悪く

確かによくないですね。
それでは「複作用」なんてのはいかがですか?
ちょっと複雑系を意識して。
「原理は単純を、構造は複雑を極め、人は最も人らしく」
座右の銘です。マンガですけれども。

>・アマゾンで「カートに入れたけど、今は買わない」
ウィッシュリストが近いですね。
他のユーザーに公開できるので、参加性は強そうです。

>微妙な比較行為を行う
機械的に実行するための切り分けが凄く難しいんですよね。
その観点でDietTelevisionに関して言うと、ユーザがパラメータの設定をいくつもクリップできれば、割と有用な「比較行為情報」を採れそうに思いました。
クリップという行動を目印にするわけで、シームレスさに欠けますけれども。