へたれwebディレクターの覚え書き

“タイムライン疲れ”してますか？

タイムライン形式のいわゆる「ミニブログ」「リアルタイムウェブ」と呼ばれるサービスが増えています。Twitter、Facebook、アメーバなう、Mixiボイスなどがそれにあたります。

使い始めた最初のうちはフォローの数が増えてくるとうれしいですし、タイムライン（以下『TL』と表記）を追うのが楽しいですが、追うべき情報は日々増える一方。いつしか、TLを追うことが義務っぽくなってきます。Twitter疲れというやつです。

（ここではTwitterに限らないので『タイムライン疲れ』と呼ぶことにします）

そんなタイムライン疲れな方にぜひ一度使っていただきたい『Threadsy』というサービスをご紹介します。

threadsyとは

Threadsyとは複数サービスのTLをひとまとめに表示する『フィードアグリゲータ』と呼ばれるサービスで、以下のような特徴を持っています。

• Twitter、Facebook、Gmailなど、複数サービスの情報を一つのTLにまとめることができる
• マルチポスト（複数サービスに動じ投稿）可能
• 「自分宛の情報のみのTL」「全情報がマージされたTL」の2ペイン方式（これがかなり便利）
• 「自分宛の情報のみのTL」は既読・未読処理対応
• 強力な検索機能
• いいね！もリツイートも、Threadsy上で行える
• もちろんプレビューも豊富。Flickr、Youtube、Twitpicなどなど複数サービスに対応。
• Meebo、Facebook、AIMチャットのクライアントにもなる
• 日本語でレスするとたまに文字化けする（汗）

なぜThreadsyがいいのか？ ほかのフィードアグリゲータの問題点

フィードアグリゲータサービスはほかにいくつか存在します。いくつか使って見ましたが、以下のような理由で使い続けるにいたりませんでした。

情報過多問題が解決していない

タイムライン疲れの理由の一つ「単純に情報が多すぎる」は、ただ情報を一つにまとめたところで解決しません。見やすくはなっても情報の量は変わっていないからです。

情報過多問題を対策するために、Twitterだけ、Facebookだけといったように表示するサービスを絞り込む機能を提供している場合もありますが、それはただ振り出しに戻っただけです。せっかく複数サービスの情報をまとめたのに、問題を解決する方法が「サービスごとに再びわける」というのではあまりに脳がありません。

価値の異なる情報を同列に扱っている

TLに表示される情報は、自分にとってすべて同じ価値ではありません。自分のつぶやきにつけられたレスやじっくり書かれた友だちの日記が、「朝だ、起きた」というつぶやきと同じ価値なはずがありません。

それでも情報が少ないうちは目で追いながら価値を選別できましたが、情報が多くなってくるとそれもかないません。

そこでThreadsy

Threadsyでは、「自分に宛てられた情報」と「すべての情報」をペイン分けして表示します。
右ペインには、すべての情報が単純に時系列で並べられます。
左ペイン（下の画面で枠囲い部分）には、Facebookでの発言に対してのコメント、自分のTwitterでのつぶやきへのリツイート、自分宛のメール、自分のFrickrの写真につけられたコメントなど、「自分に対しての誰かからのアクション（と思われるもの）」だけが抽出されます。


私は、自分宛の情報は常にチェックして、そうではない情報は寝る前になんとなく流し読む（ぜんぶ読まなくてもいい）という使い方をしています。

自分の読むべき情報が絞られるのでタイムライン疲れになりませんし、右ペインがあるおかげで「なんとなく情報が流れる」Twitter本来の楽しさを失うこともありません。

まとめ

Webから受け取る情報はこれからもどんどん増えていくでしょう。
情報をどのように整理するのか、がサービスの差別化要因になっていくと思います。
「ファインダビリティ」「情報アーキテクチャ」といった分野は重要になっていくでしょう。

Threadsyがその完成系なわけではありませんが、現時点では優れた例の一つといえます。ぜひお試しください。

関連リンク

http://www.threadsy.com/

マーケティングのフレームワークに「AIDAモデル」「AIDMAモデル」というのがあります。
おおざっぱに言うと、商品に気づいてから購入にいたるまでのプロセスを、

1. Attention（注目）
2. Interest（関心）
3. Desire（欲求）
4. Memory（記憶）, Motive（動機）
5. Action（行動）

に分けた消費行動の法則で、AIDAやAISASなども使われることもあります。（詳しくはWikipediaなどをご確認ください）


このAIDA・AIDAMAモデルがUI検討にも使えるのではないか？と思い立ち、そのやり方を考えてみます。


例として、以下のような状況に置かれたときの改善案をAIDAモデルで検討する、というのをやってみます。

エントリーを読んだ人が他の記事を読むための条件をAIDAモデルで考える

クリックして欲しいリンクがある。このような状況のとき、
「リンクをもっと目立たせればいいのでは」
といった短絡的な判断になりがちです。

これをAIDAモデルを使うとどのようになるのか、こういうふうに検討していくというのはどうだろうか、というのをステップごとに記してみます。

ステップ1・AIDAに、訪問者が満たされるべき欲求を当てはめる

まずは、あるエントリーを見た訪問者が、ほかのエントリーへのリンクをクリックするために満たされなければならない欲求を、AIDAに当てはめてみました。

• Attention：このブログにほかのエントリーが存在することに気づいてもらう
• Interest： ほかのエントリーも、訪問者が興味のあるファッション関連のものだと思ってもらう
• Desire：これまで条件にプラス、このブログのほかのエントリーが、ユーザーが期待してるレベルに達していると思ってもらう
• Action：このブログのほかのエントリーへたどるためのボタン（リンク）をクリックできる状態にある

ステップ2・欲求を満たすための条件を洗い出す

欲求を当てはめることにより、欲求を満たすための条件が見えてきました。


たとえば、InterestとDesireを満たすためには、訪問者に「ほかのエントリーも読む価値がありそうだ」と思ってもらわなければならない、ということがわかります（図の条件①）。

さらに、「面白そうだ」と思ってもらっているときに、そのリンクを提供してあげる必要もありそうです（条件②）。


特に条件①は重要です。ほかのエントリーも面白そうだと思ってもらうには、「いま読んだエントリーは自分が読みたいジャンルと一致」していてかつ「いま読んだエントリーが面白いと思った」という条件が満たされていなければなりません。

しかしすべての訪問者が、この条件を満たしているとは限りません。ここで、「条件を満たしていない訪問者のことも考える必要がある」ことに気づけました。

では条件を満たしていない訪問者とはどのような状態にあり、それに対してどのような施策を打たなければならないでしょうか。

ステップ3・訪問者の状態ごとに条件を再度洗い出す

訪問者の状態のパターンを洗い出してみます。
ここでは簡略的に、「ファッションに興味があるかどうか」「いま読んだエントリーに満足したかどうか」で分けてみました。

実際のサービス検討では、「どこからこのページにたどり着いたか」「目的があって探しているのかどうか」などなどなど、もっと細分化するべきかと思います。


状態ごとに改めて欲求を満たす方法を検討することことで、さらに新たな条件が見えてきました。

一つは「状態２・ファッションに興味はあるがエントリーに不満足」の訪問者に対してDesire欲求を満たすためには、なんらかの工夫が必要であること（条件③）。


この時点で、訪問者の状態によって表示するリンク（機能）は違っていてもいいのでは、と思えてきました。単純なほかのエントリーへのリンクは、いま読んだエントリーに満足した訪問者にしかクリックする気になってくれないことがわかったからです。

訪問者の状態に適したリンクを出し分けるのが効果的であるとするなら訪問者ごとに有効なリンクを表示させるために、
「エントリーを読んだことによる訪問者満足度をなんらかの方法で把握する必要がある」
という条件を加える必要もありそうに思います。(条件④）。


（条件５は今回はパス）

ステップ4・それぞれの条件を検討

ここまでで、ほかのエントリーへのリンクをクリックしてもらうために必要な条件がいくつ洗い出せました。

ではその条件を満たすための案を検討
サンプル代わりにベタな検討案を書いておきます。

• 条件１の対応
• 「前の記事」のようなリンクではなく、エントリータイトルを表示させることにより、リンク先の記事も同じジャンルである（もしくは違うジャンルであること）をクリックする前にわからせる
• 記事カテゴリごとになるべく同じカテゴリーの記事を紹介する
• いま読んだ記事と似ている記事を表示する
• 条件２の対応
• 適切な位置にリンクを表示させる
• 条件３の対応
• 単純な送りリンクに加え、目立つ場所に人気の記事一覧を掲載する。
• その際、ブックマーク登録数を表示することで、公平な評価であるというイメージも伝える。
• 条件４の対応
• エントリー本文を（一定以上の長さなら）分割して表示する。
• 1ページ目には、ほかのエントリーを読んでもらうことをあきらめてて、別のリンク（機能）を提供する
• たとえば、このエントリーにたどり着いたのが検索からなら、改めて検索結果をこのブログ内に表示させ、そこに広告を表示して稼ぐ、など
• 2ページ目以降が表示されたなら、「いまこの訪問者はこのエントリーを面白いと思って読んでいる状態（面白いと思わなければ1ページ目で離脱しようとするはず）」と仮定し、それ用のリンクを表示させる

AIDAモデルによってたどり着いた検討結果

「訪問者の離脱率を下げる」という目的のために、「エントリーを複数ページに分割して表示する」という、一見なんの関連もなさそうな、もしかしたら逆効果と思われるようなUI案にたどり着きました。

今回は個人で試しにやってみただけなので、たどり着いた結果が正しいかどうかはわかりません。
しかしあとで大手ブログのケータイ版などを見たところ、しっかりと一つのエントリーでも分割されたページごとにリンクの出し分けがされているものがありました。
あながち荒唐無稽な策ではないようです。

まとめ：認知的ウォークスルーにも似てますね

ここまで書いていて、このやり方って「認知的ウォークスルー」に似ているな、と思いました。

違いは、認知的ウォークスルーがアクション需要に対しての供給視点で、AIDA・AIDAMAモデルはアクションへの需要視点である、と言えるかもしれません。

私自身がまだ認知的ウォークスルーもAIDA・AIDAMAモデル方式も完全に理解実践できてるわけではありませんので、今後、双方を比較しながら何度かやってみて、それぞれに合った場面を見つけたいと思っています。

せっかくサービスを作ったら閲覧だけでなく、あたりまえですが投稿などもしてもらいたいものです。

サービス上でユーザーにアクションをしてもらうために、「このアクションをしてください、するとこんな素敵な出来事が！」とメリットを伝えるのはよくあるやり方だと思います。

たとえばCGM系サービスを運営していて、「ユーザーにコメント投稿してほしいな」と思ったなら、
「あなたがコメントを投稿すると、そのコメントがほかの人に読まれ、そこからコミュニケーションが広がっていきます」
などでしょうか。


しかしユーザーは、自分がアクションするかどうを、メリットだけをみて決めているわけではないと思います。

コメントをしようと思ったときにメリットとは逆の、
「このコメントをすると、誰かに迷惑かけないだろうか？」
「自分に対してよくないことが起きないだろうか？」
ということも考えているのではないでしょうか。

アクションしてもらうために必要な「許しのデザイン」

アクションしてもらうためには、これらの不安を払拭する必要があります。そのための機能やデザインのことを僕は「許しのデザイン」と呼んでいます。

「許しのデザイン」の例として、たいして意味のないコメントを投稿しても大丈夫だよね、と思わせる工夫されているサービスを挙げてみます。

Twitterの場合

Twitterでは、投稿された発言（つぶやき）がたとえfollowの発言であっても見落として平気、という世界観がうまく構築されています。その世界観が、「邪魔なら無視されるだけだから、だからガンガン発言して大丈夫」と思うために役立っています。

Facebookの場合

たくさん発言しても迷惑にならないよう表示方法が工夫されています。
連続して発言すると、発言のうちのいくつかが、クリックしないと表示されないようになります。

また、最近追加された「ニュースフィード」では重要そうな発言を上位にピックアップして表示するようになっているようです。（まだまだ不完全ですが）

ソーシャル系サービスほど許しのデザインは重要

少し前まで、サービスは自分ひとりで使うものでした。ですからアクションに対する不安は自分に対してだけであり、最悪「まぁなにかあっても自分が困るだけだし」で解決、ということもありました。

しかしいま主流のソーシャル系サービスは人との繋がりが前提です。「他人に迷惑かけちゃうのでは」という心配が新たに発生します。

一人のアクションが多人数に影響するソーシャル系サービス全盛の時代。許しのデザインの重要性は増してきている気がします。

仕事でユーザーテストをすることがあるのですが、やりながら
「僕は本当にユーザーの行動のポイントに気づけているのだろうか？」
という疑問を持ち続けています。

今日は『Yahoo!アクセス解析』というツールをこのサイトに導入する作業をしていたのですが、導入までのフローを「一人ユーザーテストしてみたらどうだろう？」と思いたち、やってみました。

ユーザーテストの趣旨や目的には反していますが、「とは言え、なにかに気づけるんじゃないだろうか？」と思ったのです。

まずはテストした結果メモを公開します。
『Yahoo!アクセス解析』セルフユーザーテスト議事録』（PDF・342KB）

考察については次回以降に行います（身内が救急車で運ばれたりしたので最近あまりネットやれてないのです…）。

続きます。

読書メモの続きです。

創造性とデザインの方法

創造性とデザインの方法

• ダニエル・ピンクによる『6つの感性』
• 機能だけでなく「デザイン」
• 議論よりは「物語」
• 個別よりも「全体の調和」
• 論理ではなく「共感」
• まじめだけでなく「遊び心」
• モノよりも「生きがい」

すべて「動詞で考える」につながる。
生活における経験価値なく、生活全体の視点から見る力→「生活における経験価値」

クリエイティビティは「ひらめき」や「アイデア」と同等か？

ブルーノ・ムナーリによる「ひらめき」や「アイデア」の分類

1. ファンタジア
• これまでなかった新しいことを考え出せる能力。実現可能か機能面はどうかなどは考えなくて良い。
2. 発明
• 認識している事柄同士が持つ関係を利用してこれまでなかったものを考え出す。
• 最終的にこの関係を実用性に向かわせる。美的問題は含まない。
3. 創造力
• ファンタジアのイメージ面と、発明の機能面の両方を多角的な方法で利用するもの。企画設計する手段あるデザインの分野で活用され、一つの問題のあらゆる側面（心理的、社会的、経済的、人間的そう工面など）を内包する手段。
4. 想像力
• ファンタジア、発明、創造力によって考え出されたことを目に見えるようにする手段。

創造力（創造性）が特別な「生まれつきの才能」ではないことがわかる。

創造性とコミュニケーション

• 心理学でいう「心の理論」
• 心的状態を推測
• 人は相手の表情など、無意識の動作にてよっても心理状態を想像している
• インタビュー法より行動観察が有効
• 人は普段、それほど意識的に他人の行動を見ていない
• 意識と行動は、その本人の中ですら一致していない
• →ユーザーテスト法でも行動と発話の両方からユーザーの行動分析を行う
• 調査のあとにユーザーの行動を物語風のシナリオとして書き出すと、観察できていたかどうかハッキリする

ユーザー調査はユーザーに何かを教えてもらうためのものではない。それではどこにも創造性が関与しない。

まとめ

いまちょうど会社でユーザーテストを行っています。

ユーザーの動作を注意深く観察して、わずかな行動に気づき、あとからその行動の理由を尋ねながらシナリオのようなものを作っていくのは、確かに効果がありそうです。

ただ現時点では、どこまで正しくユーザーの行動を終えているのかわかっていません。

とりあえず今は、

観察するということに慣れてくると、それまで見えていなかったものが不意に見えるようになる瞬間があります。意識化できなかったものが突然意識でき、目の前で行われていたユーザーの行動を改めて発見するのです。

これを期待して、この学習とユーザーテストを繰り返し続けることにしようと思っています。

『ペルソナ作って、それからどうするの？』の学習時メモを公開します。

第1章・デザインの問題を特定する

• デザインとは「どんな世界を実現したいのか」という哲学
• これがないとデザインする課程で必ず発生するトレードオフに対して明確な選択ができない
• ニーズを調査で集めても「今のユーザーのニーズ」だけではデザインを決められない
  • ユーザーのニーズは何かの拍子に変わってしまうので
  • ならば「何かの拍子」を最初からデザインそのものに負わせるほうが良い

「デザイン」とは？（言葉の定義）

• 作ろうとするものの形態
• 行おうとすることの形態
• 行為の導線
• 行為の軌跡
• 計画・目的・意図＝グランドデザイン
• 「建築家の仕事におけるデザインに近い」かもしれない。
• 美的な意味合いでの「構想力」
  
  • 「企画としてのデザイン」「そのやり方を知ってれば簡単」
  • 日常生活の動作は、デザインにとって最も重要
    
    • 「動きの中にしかデザインはない」
    • 「たとえば茶道では、あたかも無意識にやったかのように意図的に非常に無駄のない線をたどっていくことを極めている」
  • デザインの仕事について。
    
    • 「デザインは製品にかたちを与えることだと思われているが、それだけではなく
      それがかたちを成すための要因をしっかり見せることもデザインの仕事。」
  • 「名詞ではなく動詞で考える」
    
    • 改良の余地のないようなものでも、それが「使われている状態」で見れば改善点が発見できることがある

ウェブの制作とデザイン

1. デザインはスタイリングではない
2. デザインの成果は人間の目的に適応した人工物
• ユーザーが必要な情報に迷わずたどり着けるようにするナビゲーション・システムの設計や、 ユーザーとどのようなコミュニケーションを行うことで、どのようにしてウェブサイトのビジネス成果（商品やサービスへの資料請求やECでの販売など）を上げるのかを設計しているという点ではウェブサイトをシステムとしてとらえていると言える
3. デザインには誰もが習得できる方法がある
• ウェブサイト制作の現場で行われているかどうか怪しい
• 現場メンバーの属人性に頼る部分を少しでも減らす
• 「問題を解くためのデザインの方法」をデザインする
4. 日常生活の観察がデザイン問題の解決につながる
• ウェブサイト制作の現場で行われているかどうか怪しい
• そもそもあまり認識されていない
• ユーザーテストを実施していても正しいタスクで実施されていないため、ユーザーの日常生活とはなんの関係もない行動の観察になってしまうケースがある
• テストが目標に対して正しく対応していなければ、目標は達成されることがない。
5. デザインはディレクション、プロデュースと同義

我々の事業は何か、ミッションは何か？

• 事業は何か
• 何であるべきか
• どんな問題も、内部の視点だけで解くことはできない
• 社会の人々の、現在よりも将来の生活や暮らしを見据えた外部の視点から、問題そのものを発見しそれを解いていく必要がある

まとめ

• デザインとは
  ある問題に対する解決策を具体的な形や振る舞いとして実現するための一連の作業過程、およびその成果物のこと
• ビジュアル・デザイン（orスタイリング）とは
  「具体的な解決咲くとしてのものの形や視覚的な表現、スタイル」のこと

前回のエントリー、『インターフェースとマーケティングとの関係』について、『DESIGN IT! w/LOVE』さんから厳しめのご指摘をいただきました。


ご指摘内容についてはすべて「おっしゃるとおりですスイマセン」と思わされるものでした。


前回のエントリーでわたしが書きたかったのは
「なにを達成すればゴールなのか」をまずは深く掘り下げることをし、その上で「そのゴールを達成するためにはなにをするべきか？」を検討する。それを詰めていく課程が「サービス企画」なのでは
というものでした。

が、わたしの理解度や知識があまりにも浅く、それが内容のおかしさや用語の混乱になっていたかと思います。


自分のダメっぷりをインターネットで大公開した、というのは良い機会だと思われます。
これ以上の痛い目を見る前に、いまこのタイミングでキチンと学んでおくべきだと思いました。


ということで、以下を行うことにします。

• 「実現したいことの明確化→サービス企画」のフローを、業務で使えるレベルまでに高めることを目的に、学習を行う
• まずは『ペルソナ作って、それからどうするの？』を基本的に本の章立て通りに読み進める
• 問題ない範囲で読書メモをブログで公開する
• 途中で「実際に手を動かしてみるべきだ」と判断したら、それを行う

一緒にこの本で学んでいこうという方が近くにいたら、読書会っぽくするかもしれません（ただわたしは読書会というもに参加したことがないので、進め方もよく分かってないです）


上記フローについては途中で読み進めていくうちに変更するかもしれません。（要はわたしのスキルが上がればいいわけで、読書メモの公開が目的なわけではないのです）


最後になりますが、『DESIGN IT! w/LOVE』さん、いろいろご指摘いただきありがとうございました。

『DESIGN IT! w/LOVE』さんのエントリー、『製品中心から人間中心のデザインへ』と『マーケティングとユーザビリティに対するデザイナーの失望』はとても興味深い内容でした。
私のブログのテーマである「インターフェースとマーケティングとの関係」について触れられており、また私が曖昧にしていた部分（理解できていない部分）をわかりやすく明文化されていて、職場で読んでいてかなりテンションが上がりました。
（同時に自分のダメさ加減にショックを受けました）


いい機会なのであらためて、「サービス検討段階でマーケティングはどのようにかかわればいいのか？」をテーマに

• ユーザーのNeedsを正確に把握し、サービスとインターフェースに落とし込むプロセス
• その課程でマーケティングはどのようにかかわればいいのか

について考えてみます。

もう少し整理してからエントリーしたかったのですが、なんとなく機を逃してしまうような気がしたので、触発されたままのイキオイでアップしてしまいます。
あとで修正するかもしれません。

ユーザーの「達成したいこと」（Needs）から、「本当の目的」（Wants）を導き出すプロセス

サービスとは目的達成に近づくための手段であることを再確認しよう

製品やサービスは本来、なにかの目的を達成するため（もしくは目的達成に近づくため）の手段です。
言い換えると、手段であるサービスを検討するためには、目的を正確に把握することが重要になってきます。

ただ前提として、「一般の人は自分の本当に欲しい物を分かっていない」ということを理解しておきたいです。
ユーザーのニーズを得るのは比較的簡単です。しかしNeedsを満たしても、Needsはユーザーの本当の目的ではなくたくさんある手段のうちの一つであることが多いため、ユーザーの本当の目的を達成していないということがほとんどなのです。

家計簿サービスを例に考えてみる

例として家計簿を挙げてみます。

家計簿は、「つけれるものならつけたほうがいいよね」の筆頭かと思います。三日坊主で終わった人も多いでしょう。

家計簿のNeedsは、家計簿をつけている人（またはつけようとして断念した人）にアンケートを採れば簡単です。

• 入力をもっと簡単に
• ケータイからも入力できるように

という意見がほとんどです。
つまり「簡単に楽しく家計簿をつけたい」のですね。


しかしこれらを解決すれば、ユーザーの本当の目的は達成できるのでしょうか。
いやそもそも、本当の目的ってなんでしょうか？

NeedsからWantsへさかのぼる

本当の目的を把握するためには、NeedsからWantsにさかのぼる作業をします。
これは、マインドマップをさかのぼる作業に似ています。


NeedsからWantsへは、さかのぼればさかのぼるほど、ユーザーの本当の目的に近づいていきます。
ただし、逆に内容はアバウトになっていきます。
「お金の出納を把握する」ではまだまだ具体的ですが、「なりたい自分になる」あたりではいかにもアバウトで、企画が曖昧になってしまいそうです。

どこまでさかのぼればいいのか？といのは僕にはまだ良くわかっていません。
ただし少なくとも企画段階では、家系図でいう5親等くらいの広がりは検討した方がいいような気がします。
これを『Wants5親等の法則』と呼びます（いま考えた）。

NeedsとWantsの階層を上下するには、リサーチ資料が必要なのではないか

さて、Needsをさかのぼりつつ「なりたい自分になる」というWantsにたどり着くには、
「20代後半から30代前半の人は、理想とする自分の将来像を持っており、自分が理想に近づくための金銭的・時間的投資を惜しまない傾向にある」というリサーチ結果を把握している必要があります。

また、このリサーチ結果を検討材料に含めるかどうかは、サービスの対象に「20代後半から30代前半の人」が含めるのかどうかにもよります。

この時点である程度のマーケティング的判断が必要になってくるのではないでしょうか。

サービスとインターフェースに落とし込むプロセス

NeedsとWantsを把握できたとして、次にそれをサービスとインターフェースに落とし込むプロセスについて考えてみます。

これには主に

1. ペルソナ・シナリオ
2. 利用可能な技術
3. 数々のアイデア

の3つの要素があると思います。

1・ペルソナ・シナリオ

UIをペルソナに合わせる、というのはよくあることだと思いますが、私は機能すらもペルソナに左右されるべきだと思っています。

「なりたい自分になる」家計簿サービスという視点で考えてみます。

20代のペルソナを用意した場合、20代というのはいまあるお金の投資方法によって自分の成長具合に変化があるわけですから、目的に達するためには、ただ収支を管理するだけでなく、「なににお金を使うべきか」「あなたが使ったお金はどれだけ将来の自分に対する投資となっているか」をなんらかの方法で把握できる機能が必要かもしれません。
逆に60代の人が使うサービスなら、「成長のための投資」機能は（20代と比較して）要求度は低いです。生涯に使える予算がすでにある程度分かっているなかで、リスクを避ける運用方法や、単純に「今月はあといくらお金を使えます」機能が重要視されるかもしれません。

ペルソナによって

• どんなoutputが求められているのか
• どんなinput量、input方法なら負担に感じないか

などは大きく異なるわけですから、機能も、目的とペルソナによって左右されるべきではないでしょうか。

2・利用可能な技術

ペルソナとも関係あるかもしれません。

技術には制作者が利用できる技術とユーザーが利用できる技術、二つの視点が必要です。
「今現在」利用可能な技術だけでなく、1年後にはどのような機能がユーザーに使われているか？それは今回の企画でユーザーインターフェース改善に使えるか？を考える必要があるかと思います。

たとえば、対象とするペルソナが「ケータイの機能をいつでもフルに使いこなしている新しい物好き」であるならば、

• ケータイで撮影した画像は自動的に共有フォルダにアップロード
• GPS使い放題

を前提に機能やUIを検討してもいいかもしれません。

3・数々のアイデア

アイデアの出し方と反映方法については本稿とは別テーマなので割愛しますが、このアイデアの数（と有用性）が、サービスの独自性につながるのだと思います。

検討した結果

検討した結果、考案されたサービスから得られるoutputがWants（なりたい自分になる）に近いかを吟味し、不十分だと思われたら、繰り返し繰り返し再検討する必要があると思います。

「インターフェースとマーケティングとの関係」:おわりに

私の考える「サービス検討段階でマーケティングはどのようにかかわればいいのか？」は以上です。

このエントリーを書いているうち、『マーケティングとユーザビリティに対するデザイナーの失望』で触れられている

ほとんどのマーケティングリサーチがデザイナーにとっては意味をなさない結果しかもたらすことができないのではないかと僕もずっと感じています。つまりマーケティングリサーチの結果を知ったからといって、デザインをするうえで役立つ情報はまったく得られないと思っているわけです。

という一文は、機能とUIを検討するプロセスが別にあるためにおこる問題なのでは？と思えてきました。

具体的な解決方法は『製品中心から人間中心のデザインへ』で書かれている

製品ありきではなく、今回のように、あくまで人びとの行う行動ありきで、そこにどんな物があればよりその行動が円滑になるか、目的をよりよく達成できるようになるかを考えるという場合のほうが、より本来のUCDの良さを発揮できるんだなと、実際に作業を進めていて感じます。

ですでに見えているのでは、と思ったのですがどうなのでしょう？

サイトを利用していると、たまに「あぁ、ここ使いづらいなぁ」と思うことがあります。

そのうちもったいないことに、「きっと、ある問題を解決しようとして頑張ったら、別の問題を引き起こしちゃったんだろうな」というものがあります。今回はそれについて3つほど例を挙げてみました。

1. fon-familyの指定
2. 多段型ドロップダウンナビゲーションメニュー
3. 入力フォームの説明文

font-familyの指定

いろいろなサイトを訪問していると、CSSのfont-famikyにヒラギノ角ゴを指定しているサイトが多いことに気づきます。

わたしはWindowsユーザーなのですが、ヒラギノが指定されているサイトを見ると、アンチエイリアスがうまくいかないようで、フォントがほころんだように表示され、読みづらくなります。


またWindowsでヒラギノフォントを表示させると、MS Pゴシックなどと比べてサイズが大きくなるようで、たとえばYahoo!ログールでは文字が重なってしまっています。

おそらくwindowsユーザーがヒラギノをインストールしているという状況を予測できていないために起きる現象だと思われます。ヒラギノフォントはMacOS Xの標準フォントで、ふつうのWindowsPCにはインストールされていません。

しかしWindowsユーザーでも、デザイナーならヒラギノフォントをインストールしている人は多いのではないでしょうか。また、初めてMacOS Ⅹに触れたときにその美しい文字に見とれてしまい、「ヒラギノをインストールすれば僕のwinマシンでもMacのようにきれいな文字になるんだ！」と勘違いして4万円はたいてフォントを購入してしまったわたしのような不幸な人もいるかもしれません。


ということで、「font-familyはわざわざ指定する必要があるのか？」というのを考えてみます。

font-familyを厳格に指定する必要性を考える

なぜわざわざfont-familyを指定するのでしょうか？
font-familyを指定する理由は、以下でしょうか。（ほかにあったらご指摘ください）

1. Mac用のIEだと、2バイトフォントを指定してあげないとinputフォームの内容が文字化けすることがある
2. IEでUTF-8だと、日本語文字と英数字で違うフォントが使われるので、それの対策
3. 一部のブラウザーの標準のフォントが明朝なのでそれをゴシックにしたい
4. 少しでも表示をかっこよく

１. Mac用のIEだと、2バイトフォントを指定してあげないとinputフォームの内容が文字化けすることがある

らしいです。Macを持ってないので動作確認できませんでしたが。


古いブラウザーに必死で対応しなくてはいけない理由がよくわかりません。

古いブラウザーはセキュリティー面でも不安がありますし、そもそもブラウザーを作ったメーカーがサポートをやめてしまっており、かつ代替となる最新のブラウザーが無償で提供されているわけですから、無理してサイト制作者が頑張らなくてもいいような気がします。

実際、GoogleやYahoo!が提供するサービスでは、古いブラウザーは推奨外とされています。


少数を切っていいと言っているわけではありませんが、頑張ってMacIEに対応するよりも、そのリソースを使ってサービス自体の質を向上させたほうがいいと思います。もし「少数を絶対に切らない！」というポリシーであるのなら、Mac用IEより利用者数の多いOperaやモバイルブラウザー、iPhoneへの対応を優先したほうが喜ぶ人も多いのではないでしょうか。

２. IEでUTF-8だと、日本語文字と英数字で違うフォントが使われるので、その対策

IEで文字コードがUTF-8のページをfont-familyを指定しないで表示すると、日本語はMSPゴシック体、英数字はセリフ体（日本語文字でいう明朝体に該当、たぶんTimes New Roman）で表示され、かつ英数字だけアンチエイリアスがかかるようです。これはちょっと違和感あるような気もします。


Googleでは「arial,sans-serif」を指定し、とりあえず日本語も英数字もゴシックで表示されるようにしています。「英数字だけアンチエイリアスがかかる」という問題は気にしていないようです（多分ですが、CSSがUSのものと共通なのでしょう）。
実際に表示してみると、個人的にはあまり表示の違和感を感じませんし、「英数字だけなめらかに表示されるからGoogleが見づらいよ！」という話を聞いたことがありません。
フォント名を厳格に指定することなく、フォントの違い対応しています。これでいいような気がします。


逆にYahoo!のトップページのように、MS Pゴシックが指定されているのはちょっとやり過ぎな気がします。

３. 一部のブラウザーの標準のフォントが明朝なのでそれをゴシックにしたい

２の「IEだと、日本語文字と英数字で違うフォントが使われる。それの対策」と同じですね。sans-serifを指定しておけば解決されると思います。

４. 少しでも表示をかっこよく

デザイナーのサイトなら、どのフォントを使うか自体が重要なコンテンツですが、そうでもないかぎり、フォントをがっつりと指定する必要性をあまり感じません。


ヤスヒサさんは『Webサイトはまったく同じ見た目である必要はない』というエントリーの中で、以下のように語っています。

レイアウトが崩れていても良いという意味ではないですが、若干の見た目の違いは『仕方ない』ではなく『当然のこと』だと思います。異なる環境が構築されているパソコン上で異なるブラウザを使っているわけですし、OSもしくはブラウザにカスタマイズがされていればさらにバリエーションも増えるでしょう。ディフォルトだといってもパソコンメーカーごとに何かしらのカスタマイズがされている可能性があるので、純粋にディフォルト環境というものはないかもしれません。利用者側もコントロールが出来るわけですから、Webらしいといえば Webらしいわけですね。

「いま作っているサイトは、本当にフォントを厳格に指定する必要があるの？」というのを再度考えてもいいような気がします。

font-familyのまとめ

もしfont-familyを指定している理由が上記のようなものであるのなら、Googleのように最低限のfont-family指定にしておけばいいのではないでしょうか。（もちろん、個人サイトやデザイナーのサイトのような、サイトの見た目が大事な場合は別です）

どうしてもフォント指定したいのなら、せめてWindowsでもきれいに表示され、かつMacには存在しないメイリオを最初に指定するなどの工夫があってもいいと思います。
少なくとも、文字が重なったりはしないようにはしたいです。


余談ですが、知人のMac使いなデザイナーさんにこの話をしたところ、「メイリオでもMS Pゴシックでもなんでも、とりあえずWindowsで見やすいようにしておけばいいんじゃない？ Macならどのフォントが指定されようが、どうせきれいに表示されるんだから気にならない」だそうです。Macうらやましいなぁ。

多段型ドロップダウンナビゲーションメニュー

ナビゲーションメニューで、深い階層を指定できるようになっているサイトを見かけます。リンク先にあるようなナビゲーションですね。このナビゲーションが、使いづらいなぁと思うことがあります。

上の画像を見ていただきたいのですが、このFolder 2.1からFolder3.1.1にカーソルを移動しようとするときに、メニューの外にカーソルが通ります。そのときに、今まで開いていたメニューが閉じられてしまうのです。

このような多段型ドロップダウンナビゲーションメニューを用意するときは、カーソルがメニューから離れても、メニューが消え始めるまでにタイムラグを用意したいところです。Windowsのスタートボタンが良い例ですね。


なお個人的な感想ですが、ドロップダウンナビゲーションメニューが3階層以上のサイトを、使い勝手がいいなぁと思ったことがありません。
一般的には使い勝手が良い、とされているのでしょうか。気になります。

入力フォームの説明文

検索フォームなどに、薄い文字で入力例が表示されているサイトがあります。


しょっちゅう利用しているサイトでは、ページが完全に表示される前に検索キーワードを入力し始めたりするのですが、そのときにこの入力例が消えてくれないことがあります。


ctrl+A、Delete、キーワードの入力し直し
の3アクションをすれば済むことなのですが、この3アクションは本来ならする必要ないものであり、この必要のないアクションは体感的にかなり高コストに感じます。


Mixiなど、ページが表示中に検索キーワードを入力し始めたら入力例は表示しない、としているサイトもあります。可能な対策はしておくべきでしょう。

まとめ

どれもわたしが個人的に気になったというだけであり、同じような不満を持つ人はごく少数だと思います。自分で書いておいてなんですが、正直、言いがかりレベルの話です。

が、インターフェースデザインの担当なら、こういう細かいところにまでとことんこだわれる人でないといけないような気がします。

サイトの不満点に対して対策案を考えるにはまず、あらゆる不満点に気づくことが必要だと思うのです。

2008年も質、量ともにありえないくらい仕事でミスしましたが、一番悔しかったのが、ユーザーが間違ったアクションをしたときに「ただエラーメッセージを表示するだけ」という仕様を書き、それを第三者から指摘されて気づいたことです。

ユーザーがサイト上でアクションをしてくれる、というのは、サイト運営者にとってとても貴重なことです。
それを大事にしない仕様を書いてしまいました。なにが大事か、というのを理解していなかった証拠です。

『へたれwebディレクターの覚え書き』は、「分かっているつもりになっていることを文章化することで、本当に理解しているかどうかを確認する」という目的でやっています。
『思っている』を、ブログに書くことで『考えている』に昇華できたらいいなぁ、と思っています。

というわけでアクセス数の少ないこのサイトですが、今年も地味に更新していこうと思います。
本年もよろしくお願いいたします。

自分がさっきハマったのでエントリー。

マイクソロフトのサイトでIE8をダウンロードしようとしたのですが、画面上でダウンロード実行ボタンを見失ってしまい、ました。

「推定ダウンロード時間」というプルダウンがあったのでそれを選択したら、そのあとでダウンロードボタンがなかなか見つからなかったのです。

見つからなかった理由は、「submitボタンはすべての選択肢を選び終わった、フォームの最下部にあるもの」という思いこみがあったので、フォーム上部にあった「ダウンロード」ボタンに気づかなかったからです。

このページのUIの問題点は、

• 実は選択必須ではない「推定ダウンロード時間（自分の回線がなんなのかを選ぶプルダウン）」を必ず選択しなければいけない、と勘違いしてしまう（実際は、選んだところで推定ダウンロード時間の表示が変わるだけです）
• 推定ダウンロード時間、言語の変更プルダウンがあったので、ダウンロード実行ボタンはそれより下にあると思い見つけづらい

点だと思います。

おそらく、「選択が必須でないフォームは、必要な人だけの目に止まればいい、だからダウンロードボタンの下に配置しよう」ということなのだと思います。

しかし選択必須でないフォームでも、やはりsubmitボタンの上にレイアウトしたほうがわかりやすいと思います。「実行ボタンはフォーム群の最後にある」というのは、すでにユーザーの常識になっていると思われるからです。

また、そもそも、必要のないボタンなら入力させない、ということを考えるべきです。
実際、FirefoxやOperaはダウンロードするときになにも選択する必要はありません。ダウンロードボタンをクリックするだけです。

最近のUIは「必要でない選択肢はなるべく表示させない」という考えが主流のようになっている気がします。
選択させるなら、その労力に見合ったバックがあるときだけにするべきですし、そのときでもレイアウトは慎重に検討するべきだと思います。

mixiでミクコレ（背景のデザイン）を選んでいたのですが、やっぱり初期設定のデザインに戻したくなりました。

が、戻し方がさっぱりわかりません。初期設定に戻すためのリンクがなかなか見つからないのです。

そこでヘルプページに飛んだのですが、ここでさらに困りました。ヘルプのトップページから、該当するヘルプ項目がどこにあるのかすぐに見つからないのです。

そもそもなんでミクコレページで「ヘルプ」をクリックしたのに、遷移先がmixi全体のヘルプのトップページなのかもわかりません。

ということでちょっと腹が立った勢いで、モバイルサイトのヘルプページについて考えてみました。

モバイルサイトのヘルプページはどこも使いづらい

超個人的な印象ですが、mixiに限らずヤフーもGREEも、モバイル用のヘルプはPC用のそれと比べ、どこもハードの特性以上に使いづらい印象を受けます。

その理由から考えてみます。

モバイルのヘルプページが使いづらい理由を考える

PCの場合、ユーザーがサイト上のどのページにいても、サイト内の位置を把握できるのサイトが優れたナビゲーションのサイトだ、と言われています。


が、モバイルサイトの場合、サイト全体の階層を意識して利用しているユーザーはあまりいないような気がします。
ユーザーは階層を意識することなく、その場その場の判断でリンクをクリックしている印象です。


そうなると困るのがヘルプページです。

多くのモバイルサイトでは、ヘルプページは「ヘルプページのトップ」にまず遷移し、そこからユーザーに対して「該当のヘルプページを自分で探して遷移してね」という作りになっています。

が、モバイルサイトでは前述のようにユーザーはサイトの階層を意識していません。

そのため、ヘルプが階層通りに並んでいても、目的のヘルプにたどり着くのは大変なのではないでしょうか。


また、ヘルプのトップに遷移するというのは別の問題もあります。

目的のヘルプにたどり着くために、ヘルプページの階層をたどるという行為は、途中で見る必要もないページをブラウザ上で表示している、ということです。イコール、「いま作業したい本来のページ」からどんどん離れている、とも言えます
サイト構造が把握しづらいモバイルサイトでは、ユーザーは本来いたいと思っている場所から離れれば離れるほど不安になるものです。（どこまでブラウザの「戻る」機能が有効がわかりませんし）

ヘルプページは「読み終えたら元のページに戻りたい」というのが前提だと思います。
「戻る」機能が命綱（？）のケータイでは、なるべく間に余計なページ遷移を挟むべきではないと思います。

モバイルのヘルプページを使いやすくする案を考える

モバイルサイトのヘルプページを使いやすくする案を書いてみます。

しつこいようですが、「個人的にそう思っている」というだけで、正解なのかどうかはわかりません。

１．そもそもモバイルで「ヘルプを見ないと使えない機能」は、UIを改善するか、その機能自体を削るかを検討する

たぶんこれが絶対の正解だと思います。

しかしこれで終わってしまうのも寂しいので、もうちょっと考えてみましょう。

２．ヘルプに飛んだら「そのページに関するヘルプ」をまず表示させる

だれでも思いつく案ですが、そのページに関するヘルプをダイレクトで表示させてあげればいいのだと思います。

ミクコレのページでヘルプをクリックした人のほとんどは、ミクコレのヘルプを読みたいのだと予想できます。だったらそのヘルプをすぐに見せてあげましょう。

実現方法はいろいろ考えられますが、簡単な仕組みとしてはヘルプリンクを

のようなタグにしておき、クエリーを受け取るヘルプ側でどうにかしてあげる、などがあります。

３．ヘルプに検索機能をつける

仕組み的に2のようなことができないのであれば、せめてヘルプに検索機能をつけて欲しいです。

モバイル用サイトのUIを考えるとき、「なるべくユーザーに文字入力をさせてはいけない」という不文律があるような気がします。

しかし最近では、ケータイをメインで利用しているユーザーは、最短距離で目的が達成できるのであれば4文字くらいの検索キーワード入力に抵抗を感じていないのではないかと考えられます。（これを裏付けるリサーチ資料があったのですが見失ってしまった…）

ですので文字入力をあまり怖がらず、確実に調べたいヘルプがヒットするのであればヘルプに検索機能をつけてもいいのではないでしょうか。

「確実に調べたいヘルプがヒット」を実現するためにはたとえば、サイト中で使う単語はケータイの予測変換機能ですぐ出てくるものを選ぶようにしたり、ページとヘルプで使われている文言のズレをなくしたり、などが考えられると思います。

個人的に、今後モバイルサイトの文言を考える際は、ケータイの予測変換機能の存在を無視して考えてはいけないのではと思います。（モバイルサイトのSEOとかでは当然のように考慮されてるのでしょうね）

まとめ、「でもなんで」

上記２も３も、ヤフーやmixiのPC版では実現できていることです。ですのでモバイル版でやらない理由は、技術的な問題ではない、と考えられます。

おそらくUI的に、今のほうがいいと判断されているのだと思います。
その判断理由をご存じの方がいらっしゃいましたら、教えていただけるとうれしいです。

海外の優れたデザインまとめサイトでよく登場するのが『ComplementaryDuo』。

彼らのサイトでは、トップメニューはリストタグで記述されており、それをCSSで画像に変換して表示しています。
よくある手法です。

サイトのCSSを解除すると、トップメニューのいま選択されているところに
“You are here”
の文字が。

目を閉じた状態で音声ブラウザを利用してみると、「今ここにいるよ」の一文があるだけで、サイト全体の構成が把握しやすくなっていることがわかります。
すごく小さなことですが、目の不自由な方にとっては有用なのではないでしょうか。

こういう細かい部分でも手を抜かずに工夫ができるのって、素晴らしいと思います。

ルート検索サイトって便利ですね。
わたしは出かけるとき出発がギリギリの時間になってしまうことが多いので、しょっちゅう最短ルート検索機能を利用しています。
（余裕のある時間に出かければいいじゃないかという正当な意見は却下）

『NAVITIME』ではPCとケータイが連動しており、あらかじめ出発地や目的地、ルートをPCで設定してけば、あとから簡単にケータイで呼び出せるようになっています。

なっているはずなのですが、実際にケータイから使ってみると、

登録済みの地点やルートは、リンクをたどらないと呼び出せないようになっています。
これではあらかじめ地点やルートを登録したメリットがない…。

「ページ遷移が1回増えたぐらいで」と思われるかもしれませんが、わたしは自宅最寄り駅が地下にあるので、電車移動中のアクセスはタイミングが限られるのです。
そのため、ページ遷移が1回増えただけでも、使い勝手にかなり影響してくるのです。

実際NAVITIMEの場合、電車に乗ってからサイトにアクセスすると、登録済みルートにたどり着くまでに3駅ぐらい過ぎてしまいます。
「すぐに検索できること」がルート検索サイトの重要な要素であるはずなのに。

ケータイは容量や通信速度、画面の広さに制限があります。そのため、1ページあたりのコンテンツ量を（PCと比べて）絞る必要があります。

しかし一方で、それらの制限があるがゆえに、利用したい機能にたどり着くまでの距離が長くなるだけで、機能を利用する意味がなくなってしまうこともありえます。

ですから1ページにどの要素を含めるか、どこでページ分割するかは単純にページ容量だけで判断せず、その機能がどのようなシチュエーションで呼び出されるかを考慮の上で決めるべきだと思います。

そしてそうなるとUIを考える上でますます、リサーチやペルソナ、シナリオが重要になってくるような気がします。

このブログではサイズが大きめの画像を表示するのに『Lightbox JS』という仕組みを利用しています。

しかし、自分の書いたエントリーをあとから閲覧したり、ほかのLightboxを使っているブログを読むにつけ、
「ブログの画像にLightboxを使うのって、あまりよくないのではないか？」
と思うようになってきました。

なぜそう思ったのか、そしてそれをどう解決するのかを考えてみます。

Lightboxの特徴を再確認する

まず、Lightboxの特徴を再確認してみましょう。

Lightboxの優れいている点

限られたスペースで画像を表示することができる

もともとLightbox導入の目的がこれだったはずです。

なにかを説明するとき、やはり画像や図の力は絶大です。しかしwebの画面は幅が限られています。
以前はこれを別ウィンドウ表示で対応していたのですが、ユーザビリティー的によろしくなく、このサイトでもそれを解決するためにLightboxを採用しました。

Lightboxの良くない点

たいして情報がプラスされない

Lightboxはそもそも「画像を詳細に見せる」意外にほとんど情報がプラスされません。つまり「画像を見てもらうこと自体に意味がある」場面でないと真価を発揮しづらい仕組みです。

たとえば『アヴァロン・コード』というゲームのサイトはなどは悪い例で、Lightboxで表示した結果にまったく情報がプラスされていません。これでは何かに期待してわざわざ画像をクリックしてくれたユーザーをガッカリさせてしまうのではないでしょうか。

画像がパーマリンクでない

拡大した画像をあとから再度確認しようとしても、ブラウザーのhistoryに残っていません。ですので「進む」「戻る」でも表示できませんし、画像自体をブックマークできません。つまりユーザーが画像にアクセスする手段を限定してしまっています。

また、Lightbox画像表示中にブラウザーの「戻る」をクリックしてもメーン画面に戻らないため、初心者にとっては遷移が把握しづらくなります。

クリックする前にユーザーが動きを想定できない

Lightboxが表示される画像は見た目、画像にAタグを貼っているのと変わらないので、クリックしたらページ遷移するのかLightboxが開くのか判断できません。

UIを考える上での基本は、ユーザーになにかアクションさせるときに「これをクリックしたらこういう動作をするんだろうな」というユーザーの予測を絶対に裏切らないこと、そして予測させやすくすることだと思います。この意味で、当ブログでのLightboxのUIは良いとは言えません。

UIが分かりづらい

Lightboxが表示されたのはいいけれど、そのあとどこをクリックすればどうなるのかが分かりづらいようです。

本文とのつながりが失われやすい

Lightboxは表示時にメーン画面を暗くするので、画面を見ながら本文を見る、という使い方ができません。このような仕組みを『モーダルウィンドウ』『モーダルダイアログ』と呼びますが、これは「いまやってることはひとまず置いておいてここに注目！」というときに使うべき仕組みです。

ブログでなにかを説明しているときは、画像や図はその説明を補足するために使うわけであり、本文と画像のつながりが切れては意味をなさなくなると思われます。

Lightboxはモーダルダイアログである

ここでちょっと「モーダルダイアログ」について。

ダイアログとは一時的に現れるウィンドウのことを指します。アラートボックスなどもこれに当たります。
ソシオメディアによると

メインウィンドウでの利用フローを中断して一時的に現れるウィンドウ。モーダル（それを閉じるまで別の操作に移れない）とモードレス（それを閉じなくても別の操作に移れる）のものがある。
（『UIデザインパターン - ダイアログウィンドウ / ダイアログボックス』ソシオメディア）

とのことです。

Lightboxは一時的に今までの画面をブラックアウトさせて見えづらくさせるわけですから、モーダルダイアログである、と言えます。

先ほども書きましたが、モーダルダイアログは「いまやってることはひとまず置いておいてここに注目！」というときに真価を発揮する仕組みだと思います。

逆に言うと、「今やってることを覚えておいてね、そしてあとで100％思い出してね」というのは難しいようです。


前に興味本位で「初心者のためのパソコン講座」を見学させていただいたことがあります。そこで「質問フォームに文字を入力してみましょう」というのがありました。

入力モードをローマ字からかなに変更したいという受講生がいたので、その切り替え方法を説明していたときのことですが

IMEがローマ字設定なので仮名入力に切り替えたい→IMEの設定パネルを開いていもらう→設定する→設定パネルを閉じる→ん？パネルを開く前はなにをしようとしてたんだっけ？

となっていました。

「サイト利用中にダイアログを表示させてひとまずそこに注目、ダイアログが終了したら元の作業に戻る」というのはPCに慣れきっている我々にとっては一般的な仕組みですが、そうでない人にとっては理解するのが難しい仕様のようです。

で、このブログはどうしましょう？

ブログの画像にとって「本文とのつながりが失われやすい」のは致命的な気がします。

たとえば東京駅から六本木に行きたい外国の方に東京の地下鉄乗り継ぎを説明するブログがあったとします（我ながら例の極端さにどうかと思います）。

「From Tokyo Station, take the Marunouchi (RED) subway line to Kasumigaseki Station and transfer to the Hibiya (Grey) subway Line for Roppongi Station」という文章による説明と、東京の地下鉄路線図を同時にみせることでなんとか説明できそうですが、これが文章だけだったり、逆に地下鉄路線図だけだったらどうでしょうか。

Lightboxを使うと言うことは「文章と路線図を同時に見ちゃダメ」と言っているようなものです。

ということで、やはりこのブログにはLightboxは向いていないように思えます。

では代わりになる仕組みはなんでしょうか。

要件は以下のようになるかと思います。

• クリックする前に「ここをクリックすると画像を拡大するよ」というのを伝える
• 画像を拡大しても本文を確認できるようにする
• 拡大した画像はどこをクリックすれば閉じるのか分かるようなUIにする

「画像がパーマリンクでない」については、このブログの画像は単体で表示させても特に意味がなく、本文と同時に見られることではじめて意味をなすものであることから、必須要件ではないと判断して対応を見送っています（解決案が浮かばなかった、とも言います）。

そんなわけで、Highslide JSという仕組みを導入してみました。具体的に、以下のように動作が変わっています。

• 拡大、縮小（拡大を元に戻す）される画像にマウスカーソルが合うと虫眼鏡カーソルになるようにしました
• 拡大された画像はドラッグで移動できます

これで少しは良くなったかと思います。しばらくこれで様子を見てみることにしましょう。

「前次問題」ってなに？

まず、「前次問題」っていったいなんのことなのかをおさらいしてみます。

「前次問題」とは、ブログなど1画面で全コンテンツを表示しきれないサイトで、過去の情報にアクセスしたいときクリックするリンクのルールが統一されていない問題のことを指します。

この問題は、ブログや日記のエントリー表示順序はほとんどの場合時間軸で決められていることが前提でおきており、主に二つに分類されるようです。

文言の問題

「前の記事」「次の記事」という二つのリンクが表示されているとしたら、過去の記事を読むには「前の記事」「次の記事」どちらをクリックしたらいいでしょうか？
どうやらサイトによってバラバラのようです。

つまり過去の表記が『前』なのか『次』なのかわからないのです。


文言の問題については過去に書いた

日記なら「過去の日記へ」「新しい日記へ」のように、リンクテキスト自体に時間の概念を与えれば混乱することはないと思います。

というやり方である程度解決されると思われます。

左右の問題

いま画面に表示されているものより過去の記事を読みたいとします。画面下部には「≪　現在の記事　≫」というリンクがあるとしたら、過去の記事を読むには“≪”と“≫”、どちらをクリックしたらいいでしょうか？
これもサイトによってルールが異なっているようです。


つまり過去が左なのか右なのかわからないのです。

左右の問題について過去のエントリーで

結論ですが、日記は時系列で扱われるものですから、普段私たちが時系列を扱うときと同じルールを適用するべきだと思います。
時系列の代表であるカレンダーでは「左が過去、右が未来」です。縦のカレンダーなら「上が過去、下が未来」。日記の並びもそのようにするべきです。
（中略）
まとめると
左に進むほど古い日記、右に進むほど新しい日記
とする

と結論づけています。

が最近、これがどうも間違っていたのでは、と思うようになってきたのです。

そこで今回、あらためてもう少し『左右の問題』について再考してみることにします。

『左右の問題』の結論

いきなり結論を書いてしまいますが、現時点でわたしが思うのは以下のようになります。

1. そもそも時間軸でないもの（検索結果など）は右が次の情報
2. 日付（日時）が重要な情報でない場合は右が過去
3. 日付（日時）が重要な情報の場合は左が過去、でも右が過去でもいいかもしれない

以下に、そうと思う理由を述べます。

“左が過去記事”説と“右が過去記事”説、それぞれの根拠を再確認する

左右どちらかに統一できていないのは、それぞれに正当な根拠があるからだと思います。まずはそれを再確認してみます。

右が過去の記事にするべきである、という根拠

• テキストが横書きの場合、スタート地点は左で、そこから右に向かい、ページ遷移も「次ページが右」というのが紙メディアから続く一般的なレイアウトである
• スーパーマリオだってスタート地点から右に向かうじゃないですか

左が過去の記事にするべきである、という根拠

• カレンダーを代表とする、日付順で並ぶものは過去のほうが左である。ブログの記事は時間軸で並んでいるので、カレンダーのように過去のものが左、というルールに合わせるべきである

左過去と右過去、どちらを選択するべきか？とその理由

日付（日時）は重要な情報か？

ここまで書いていて、「時間軸を基準にしている」というのには二つの意味があることに気づきました。
すなわち

1. 書いた「順序」が大事なのか
2. 書いた「日時」が大事なのか

です。

ブログや日記の記事（エントリー）は時間軸、つまり日時順に並んでいるのが一般的ですが、この日時順には

1. 「順序」が大事なもの
2. 「日時」が大事なもの
   

の2種類があるように思います。

たとえば技術系ブログで10月１日に「デザインセミナーに参加します」という記事が公開されていたとします。
この10月1日の記事が、仮に公開された日が10月2日であろうと3日であろうと、多少の日付のズレならそのブログ記事の価値自体は大きく変わりません。このブログの日時はあくまで順序を決めるためのもの、つまり「時系列」が大事だと言えるでしょう。

逆に日記の場合、日時情報はとても重要です。たとえば小学生の夏休絵日記で「今日は家族で動物園に行く予定だったのに雷雨で取りやめになりました」と書かれていたとします。この日記の日付が一日でもずれてしまったら、その日記の情報が大きく変わることになります。夏休み明けに「オマエ、この日は快晴だったぞ？ あとからまとめて書いたんだろ？」と先生から疑われるかもしれません。


日付情報が、「単なるソート順」なのか、それとも「日付自体が重要な情報」なのか
言い換えるなら、その記事の日付（日時）が

1. あくまで情報を整理するための手段
2. 日時自体が情報

どちらか、の違いであると言えるような気がします。

そして日付情報が単なるソート順なのであれば、テキストが横書きの場合の基本どおり「スタート地点は左で、そこから右に向かう」とし、日付が重要ならば、より日付を意識するためにカレンダーと同じ動作に近づける、とするのがいいのではないでしょうか。

日付が大事だからといってすべて左過去にする必要もない

ただし日付情報が大事だからといって、必ずしも左過去にこだわる必要はないような気もします。
なぜなら、web上の日記を100％カレンダーを意識しながら使ってもらうのはとても難しいからです。

たとえばweb日記は（夏休みの宿題と違い）「毎日必ず、1日1件の記事」である必要がありません。
10月5日の日記を表示中、「前の日記」をクリックしたとき、遷移先は必ずしも10月4日にはならず、9月20日かもしれませんし、10月5日の別の記事かもしれません。そのためリンクをクリックした移動範囲が想像しづらく、このことが「日付」という感覚を薄めさせる要因になっています。

また、多くのブログシステムでは「カテゴリ」や「タグ」といった時間軸以外の概念が存在します。これがより時間軸を体感しづらい一因となっているかもしれません。

そもそも日記とブログの差もあいまいであり、よほど「このサイトは日記です！」というのが重要なコンセプトでないかぎりは、日記サイトであっても左過去にこだわらなくてもいいような気がします。

またもしこだわるのであるならば、もっとカレンダーを意識させるようなUIが必要なのではないかと思います。

カレンダーを意識させるために考えられること

日付にこだわるのであれば、UIに工夫が必要だと思います。
ここでは、それらの工夫は行われていると思われるサイトを紹介します。

日記であることをアピールする

mixiでは、カテゴリわけ機能を用意しないことで、より日記であることにフォーカスしているように思います。
文言も「日記」に統一されていますし、むしろ積極的に「日記」という単語を表示させているようにも思えます。

前にも書きましたが、mixiは自分たちのメーンコンテンツが日記である、というところからぶれていないのはすごいことだと思います。

複数の記事を日付でまとめて表示し、日付ごとにページングさせる

『はてなダイアリー』では、同じ日に書かれた日記を一つにまとめて表示する仕組みがあります。日付ごとにページングさせることで、日付をより意識させることができます。


『IT戦記』さんのある日の記事を例にすると、2006年3月31日には2つの記事が存在していますが、それを日付単位で一つにまとめて表示しています。

リンクも「前の日」「次の日」となっており、日付単位であることを強調しています。

日付ごとにページングさせ、かつ1日単位でしか移動できないようにする

「カレンダー」を頭にいれるのなら、「過去の情報を見るためにリンクを1回クリックした」というアクションにひも付く動作の単位が、1日であったり1ヶ月であったりがいいのかもしれません。

『美女暦』では、1日ずつ一人の女性が紹介されていますが、日曜祭日は欠番のようです。しかし前の日や次の日の女性を見るためのリンクをクリックすると。日を飛ばさずに「美女は本日お休みです」が表示されるようになっています。

そもそもカレンダーUIを用意してしまう

『Flickr』では一番上に表示される画像は「もっとも最近アップロードされた画像」ですが、これを日付順に並べることも可能です。
そして日付順で表示するためのページがカレンダーそのもののデザインになっています。

Flickrでは日付単位ならカレンダー、場所単位なら地図画面といったように、それぞれのUIを用意しています。編集画面も、目的にあった画面が複数用意されています。

このような「目的に合ったUIを別途用意してしまう」という方法も検討に値すると思います。

最後に

はてなブックマークとはてなダイアリーで過去を見る方向が異なっていますが、はてなダイアリーは日記である、ということを考えると理解できるように思えます（それが使いやすいかどうかは別ですが）。


また、長々と書きましたが、例によってこれが絶対に正解というわけではないと思います。実際、前回と違う結論になっていますし。

ご意見などあればいただけるとうれしいです。

関連リンク

• 「次」なのか「前」なのか（2006.02.22）
• デザインは、プログラムと比べてオープン化が遅れている（2006.05.23）
• 「前次問題」を再び考える（2007.07.26）

メニューの表示にタブデザインを採用するサイトが増えています。

が、個人的には、ただ見栄えがいいからとの理由でタブデザイン（タブインターフェース）を採用するのは反対です。

ちょっと前に『タブインターフェースと“世界観”』というタイトルで、タブインターフェースを使うのに適した条件を、自分なりに考えて書いてみました。
が今読んでみると、内容がアバウトで我ながら意味不明な点もあります。
そこで今回は、もう少し具体的に条件を考えてみます。

これが正解というわけではなく、あくまで自分のための覚書きです。ご意見などあればいただけるとうれしいです。

タブインターフェースを使うための条件

1. タブの中にある情報が一つ、もしくは複数なら並列関係である
2. ページの遷移が発生しない
3. 複数タブの情報を同時に見る必要がない
4. タブがデフォルトのままでもコンテンツの価値を失わない
5. コンテンツの内容をタブのタイトルだけで伝えることができる

以下、それぞれの説明です。

1・タブの中にある情報が一つであること、または複数なら並列関係であること

1-1・タブの中にある情報が一つ

タブは、一つのデータを複数の条件で出し分ける目的に向いています。

例として、wikiのようなサービスが挙げられます。
Wikiでは、1ページ毎に、それぞれのページに対応した「閲覧」「wiki文法での編集」「リッチテキストでの編集」「ページ管理」といったメニューが存在します。それぞれのメニューに主従関係はありません。
このようなコンテンツの場合、タブインターフェースによる切り替えは理にかなっているといえます。

1-2・タブの中にある情報が複数の場合は、すべてが並列関係

タブは、上下関係のない同じ種類の情報が大量にあったとき、それをある一定のルールに基づいてグループ分けして表示する目的に向いています。

ニュースサイトは（通常）、1ページに1つの記事が掲載されています。それぞれに上下関係はありません。このような状態を「並列関係」と規定します。

Amazon.co.jpにはかなり大量の情報がありますが、商品情報は（基本的に）「1ページ＝1商品」です。このような場合に、タブによるグループ分け表示は適しています。

タブは並列関係にある同じ種類の情報を、あるルールにのっとって分割するから意味があります。情報に階層関係、主従関係があると、デフォルトのタブを開いている状態のときに他のタブをクリックしたらどのような結果になるかをユーザーが想像しづらくなってしまいます。

Amazonの場合、並列関係にある商品のみにタブが使われています。もし同じ種類に属さない、商品以外の「欲しい物リスト」や「カートを見る」がタブに含まれたら、とたんに難しいインターフェースになってしまうでしょう。

2・ページの遷移が発生しないこと

タブインターフェースを採用するなら、タブをクリックしたときにページ遷移をさせないほうがいいと思います。
ユーザーが、「タブをクリックしたらページ遷移が発生する」と想像しづらいからです。
ページ遷移が発生するかどうかわからないということは、タブを切り替えたときに「切り替えた前の状態が保存されているかどうか」の予想がユーザーにはつかない、ということです。

タブインターフェースを採用しつつページ遷移が発生する例として、Yahoo!メールとYahoo!カレンダーで起こる問題を考えてみます。

会議参加依頼のメールが届いて、その予定をYahoo!カレンダーに登録しようするときのフローを考えてみましょう。

1. 会議参加依頼のメールが届く。参加を決める。
2. 予定を登録しようと、タブ「カレンダー」をクリック。自分のカレンダーが表示される。
3. カレンダーに予定日時を入力。
4. 続いて場所も入力…しようと思ったときにメールに書かれていたはずの場所を確認していないことに気づく。
5. 場所を確認しようと、メールのタブをクリックして、該当メールに戻る…つもりがメールサービスのトップページへ遷移してしまった。
6. 慌ててカレンダーのタブをクリックしたら、カレンダーサービスのトップ画面が表示。カレンダーに入力途中だったデータは消えた。最初から入力しなければ。
7. 凹む。

ページの遷移が発生することをユーザーが想像しづらいタブインターフェースでは、情報のリセットが行われると想像するのが難しく、「元のタブに戻れば以前の状態が保存されている」ように錯覚しがちです。

これがもしタブインターフェースでなかったらどうでしょう。
もしボタンメニューだったなら、ユーザーは「メニューをクリックすると単にページ遷移が起きる、だから入力途中のデータはなくなる」と想像がついたはずです。

3・複数タブの情報を同時に見る必要がないこと

上記「ページの遷移が発生しない」の例でもわかるとおり、カレンダーとメールは同時に表示しつつ利用することがあります。このような場合は、タブインターフェースを採用するべきではありません。

タブは小さなスペースで多くの情報を表示するのに適していますが、それらの情報を比較しながら閲覧することに向いていません（というか同時に表示されないので比較すらできません）。

4・タブがデフォルトのままでもサービスが価値を失わないもの

タブは、クリック率の低いインターフェースです。

ですから、「タブをクリックしてくれないとユーザーに楽しさが伝わらない」「クリックしなければサービスの目的が満たせない」ような場面で採用するべきではありません。

ヤフーのトップページにあるニュースコンテンツは優れた例だと思います。

「トピックス」という名前で注目の記事が表示されています。一般のユーザーは、トピックスの記事を目にすれば十分です。
もし他の記事を見たくなったり、他の記事を見る必要が生じた場合には、きっとタブをクリックしてくれるでしょう。
もともとニュースを見ることが目的なら、きっと「一覧」をクリックしてくれるはずです。

仮にユーザーがタブをクリックしてくれなくても、トップページの価値が下がることはありません。

5・コンテンツの内容をタブのタイトルだけで伝えることができる

ユーザーは「そのタブをクリックすることが自分にメリットがある」と感じなければクリックしてくれません。
ユーザーにそう感じてもらうにはまず、デフォルトのタグタイトルとタブ内に表示された情報を見て「自分は他のタグをクリックするべきか？」を判断してもらう必要があります。

上述のニュースの場合、ニューストピックスが表示されている状態で、「エンタメ」とのタブタイトルが目に入りました。そのときユーザーは、「エンタメ」をクリックするとどのようなコンテンツが表示されるのか容易に想像することができます。

逆にいうと、クリックして画面遷移しないと中身が想像できないコンテンツにはタブインターフェースは向いていません。

Amebaもタブメニューを採用しています。この「トップ」画面で、「ルーム」というタブ名からそこになにがあるか想像できるでしょうか？

タブ名「ブログネタ」も中身が想像できません。きっとブログを書くためネタがあるのかなと思いクリックすると、いきなり謎の生物が表示されます。

しかもamebaではタブを階層化させてしまっています。階層化された奥に「クチコミ番付」というコンテンツが存在するとは想像もできません。
「各コンテンツが並列関係にない」「各コンテンツが同じ種類の情報で構成されていない」ため、タブの中身を想像しづらくさせてしまっています。もし「ルーム」や「クチコミ番付」がキラーコンテンツだったらどうするのでしょう。（幸い、キラーではありませんが…）

余談ですがAmabaのトップページ、初めて「リクエスチョン」をクリックするといきなりタブメニューが消えてしまうのもインターフェースをさらに難しくしています。

最後に：ではいったい、タブメニューとボタンメニューではなにが違うの？

前述したYahoo!メールとYahoo!カレンダーは、見かけはタブメニューですがajaxを使っているわけではありません。実際の動きはボタンメニューのそれです。
しかしたとえ仕組みは同じでも、ビジュアルがタブかそうでないかで、ユーザーがうける印象は大きく異なるのではないでしょうか。タブメニューとボタンメニューの違いは、仕組みの違いだけで判断されるべきではないと思います。

ビジュアルの違いでユーザーが受ける印象はどう変わるのか？の例として、「なぜチェックボックスとラジオボタンは別のグラフィカルデザインが用意されているのか」を考えて見ます。

チェックボックスは複数項目が選択可能です。一方、ラジオボタンは一つだけ選択させるときに使います。

ではチェックボックスのプロパティになにかフラグが増えて、それがONなら複数選択できない、という仕組みがブラウザに用意されたらどうでしょう？
ラジオボタンは無用になるでしょうか？

しかしそれではユーザーが、「今、自分は複数の項目を選んでいいの？ それとも一つだけ選べるの？」というのを、画面を見ただけでは判断できなくなってしまいます。
ユーザーは、自分にどのような行動が許されているのかを、画面からの情報で判断するからです。


タブでメニューの表現はもちろんできます。しかし状況を考えずに使ってしまうとタブメニューであるからこそユーザーが感じることのできる「ここにある情報は並列で、同じ種類のものだ」という意味づけを失ってしまいます。

ユーザーの理解を助ける役割を果たしている「暗黙のルール」を、安易にweb製作者が破壊するべきではないと思うのです。

追記

今回のエントリーを書くにあたり、以下のページを参考にさせていただきました。

• Jakob Nielsen博士のAlertbox『タブの正しい使い方』
• ソシオメディア　UIデザインパターン『タブの並列切替』
• Apple Human Interface Guidelines　『View Controls』

タブインターフェースを採用することが決まったら、次に検討するのは「見やすく」や「高速に」などかと思います。それらについては参考ページに詳しいのでそちらをお読みいただくのがいいかと思います。

『Yahoo!地域情報』と『Googleマップ』の検索フォームには、それぞれ検索例が掲載されており、初めて利用するユーザーが使い方に迷わないようになっているようです。

しかし実際に利用してみると、かなり差があるように思われます。

後学のため、どこに差があるのか、を文章化してみます。



『Yahoo!地域情報』は画面右上に検索フォームがあります。
最近のサービスによくあるように、「まず例に挙げられているキーワードを入力して試してみてね」と例文がフォーム内に表示されています。一見、親切そうなUIです。
（画像はクリックすると拡大します）



初めて使うので、まずは例文のとおりに「東京ミッドタウン、渋谷駅」と入力しました。そして二つ目のフォームにカーソルを移動。
すると、なぜか一つ目のフォームが、フォームでなくなりました。もうキーワードを修正できなくなってしまったのでしょうか。

実は入力不可になったと思われた一つ目のフォームは、キーワード上でクリックするとフォームが復活します。だからといってわざわざフォームを消す理由が分かりません。
仮に理由があったとしても、ユーザーに「入力できなくなった」と勘違いさせる以上の理由があるとは思えません。

混乱しつつ二つ目のフォームにも、例に挙げられているとおり「ホテル、郵便局」と入力して検索ボタンをクリック。

すると、見事に1件もヒットしません。

実は例にあった「東京ミッドタウン、渋谷駅」というのは、「東京ミッドタウンか渋谷駅の、どちらかを入力してね」という意味だったのです。わかりづらいです。


一方、同種のサービスである『Googleマップ』をあげてみますが、キーワードごとにかぎカッコでくくられており、どのように入力すればいいのか一目瞭然です。

例文が常時表示されているので、「一つ目のフォームに入力するのは場所？キーワード？時間？そのほか？」と悩むこともありません。

そもそもYahoo!地域情報の場合、フォームにカーソルをあてると例文が読めなくなる、という仕様も使いづらい一因です。
例文は初めてサービスを使ってみる人にこそ必要なものですが、そのようなユーザーがじっくりと例文を読んでから入力という行動を始めるとは思えないからです。


親切のつもりでつけた機能が、実は逆に使い勝手を悪くするというのはよくあるパターンです。
サイトを設計するときは、どのような熟練度のユーザーがどのように利用するかをイメージしながらUI構築をしないといけないのだと思いました。

htmlにはページ遷移とユーザーからのフォーム入力内容受け取りの機能があり、それぞれ

• テキストリンクはページ遷移
• submitボタンはフォーム入力内容の反映

と役割を担っています。

しかし最近ではajaxの一般化もあり、このルールにあてはまらないUIのサービスが増えてきました。

一度、ルールを整理してみようと思います。

テキストリンクとsubmitボタン、どちらを選ぶべきか

テキストリンクとsubmitボタンでどちらを選ぶべきか？を表にしました。


以下、それぞれの内容です。

1・「遷移」か「実行」か

Flickrの画像プロパティ編集画面です。ここでは画像が撮影された時刻を編集しています。

編集完了ボタンを見ていただきたいのですが、編集して保存する場合は【SAVE】というsubmitボタン。これは一般的なUIです。
しかしキャンセルがsubmitボタンではなく“click here if you are not sure of the date.”とのテキストリンクになっています。

考えてみるとこのUIは理にかなっています。
Flickrのこの場面の場合のキャンセルとは、「編集を反映しないで編集画面を終える」のではなく厳密には「編集を反映しないで画像表示画面（前ページ）へ遷移する」です。
ページ遷移ですから、テキストリンクでいいのです。

ちなみに画像表示画面で直接タイトルを編集する場合は、キャンセルはsubmitボタンです。キャンセルしてもページ遷移が発生しないからこのようにしているのだと思います。

2・選択された内容は一時的反映か、記憶されるか

サービスの動作を設定し反映する場合、その設定に2種類あります。
「その設定が一時的なもの」か「その反映が記憶される」かです。

Yahoo! Japanの検索条件の設定は、検索条件を「動画」にしても、次にこのページに訪れるときはデフォルトの「ウェブ」に設定が戻ります。

本来、「設定の反映」はsubmitボタンのほうがいいと思われがちですが、このように設定が保存されないものは、テキストリンクのほうが一時的であることが伝わりやいと思います。

3・SVOCの“O（動作の対象）”はthisか

Flickrの一覧にある「削除」は
「この画像を削除」
を表しています。この場合、テキストリンクでも違和感がありません。

逆に検索ボタンなどは対象語がない、という状況は考えられません。
このような場合は、submitボタンを選択しましょう。

それをクリックしたら、まわりの内容も反映されるか

submitボタンは本来、フォーム入力に利用されるものです。
フォームでのsubmitボタンは、それ単独で利用されることはほとんどありません。ユーザーは「submitボタンを押すと、そのまわりにある入力フォームの内容が反映されるんだな」とのイメージをすでに持っています。

一方テキストリンクは、ページ遷移で使われます。ページが遷移するだけですから、そのページないでなにか入力されていても関係なく「ただページが移動するんだな」と理解します。

ですので、ページ内の入力項目が反映されるボタンにテキストリンクを使うべきではありません。

まとめ

長々と書きましたが、これが絶対に正解というわけではないと思います。
ご意見などあればいただけるとうれしいです。

ユーザーからの入力を求めるときのインターフェースはいくつかありますが、中でもプルダウンメニュー（ボタンダウンメニューとも呼ばれる）は使い勝手がよく、

• 限られたスペースでも設置できる
• こちらが想定した内容に限定した入力をさせることができる

というメリットが魅力的で、ついつい多用しがちです。

ここではあらためて、プルダウンメニューはどのような条件で使われるべきなのかを考えてみます。

プルダウンを使うのに適した条件とは　

次の条件に当てはまる場合、プルダウンが適していると思われます。

• 必ずしも入力必須でないもの(選択肢を選ばなくてもなんとかなる)
• もし入力必須なら、どの選択肢を選べばいいのかすぐにわかるもの
• 選択肢から複数を選ぶ必要がないもの
• 直接入力するより選んだほうが早く入力できるもの

選択肢を選ばなくても動作可能なもの

たとえば「さらに詳細に絞り込む」ときなどがこれにあたります。
amazon.co.jpの場合、プルダウンが条件絞り込みに使われています。が、プルダウンがデフォルトのままでも、目的のページにたどり着くことができます。


googleの検索オプションはさらに徹底しています。複数のプルダウンがありますが、すべてデフォルト設定のままで問題なく検索機能を利用できます。


Yahoo!ブログの検索機能は、検索条件に「ブログ」「記事」「画像」を選べます。「絞り込み」というよりは「選択」であり、一見、プルダウンに適していないように思えます。
しかし検索結果を複合表示する「全体」を用意することで、デフォルトのままでも問題ないようにしています。

（選択が必須の場合は特に）どの選択肢を選べばいいのかすぐにわかるもの

プルダウンは、選択肢をじっくり読むことに適していません。
「設問を見た時点でユーザーは答えを思いついており、あとは選ぶだけ」という状況で使われるべきです。
選択肢の文をじっくり読まないと選べないんのなら、別のインターフェースを検討するべきです。

自分が選択するべき項目以外は確認しなくてもいいもの

「あなたの住んでいる国は？」という設問が合った場合、答えはすぐに「日本」と浮かびます。
ユーザーがするべきことは「日本」を探すだけです。日本以外にどんな選択肢があるのかを読んで確認する必要はありません。シーランド公国があってもなくてもユーザーには関係のないことです。

プルダウンは、すべての選択肢を読まなければ選べないような設問に使うべきではありません。「すべての選択肢を」「よく読まないと」判断できないのなら、別のやり方を検討するべきです。

選択肢は少ないほうがいい

たとえ簡単な質問でも、選択肢が多いとどれを選べばいいのか混乱することがあります。

複数選択したくならない

ホテルの予約をしたいとき、「ツインだとうれしいけど、ないのならダブルでもいいや」という状況はあり得ます。画面のようなフォームだと、そのニーズに応えることができません。


プルダウンメニューを使うときは、ユーザーが複数選択したくなるかどうかを前もって検討するべきです。

直接入力するより早い

たとえば「生まれた年を選択してください」とプルダウンから選ばせるなら、もしかしたら直接入力してもらったほうがユーザーにとっても楽かもしれません。
本当にプルダウンが便利なのかは、設問ごとに検討されるべきです。

アクションコマンドとしてのプルダウンを考える

プルダウンから選択すると、直後になにか動作が起きるUIのページを見かけます。
ユーザビリティー系の本には、動的なプルダウンは推奨しないと書かれていることが多いです。
本当にそうなのか、そうならばどのような理由からなのか、を考えてみます。

ページ遷移

プルダウンを選択したとたんにページが遷移するインターフェースを見かけることがあります。リンクショートカットに使われていることが多いようです。

しかしショートカットを用意したくなるような「頻繁に使われるリンク」「重要なリンク」なら、もっと別なやりかたでフィーチャーするべきです。

また、プルダウンのボタンをクリックするまでどんなリンク先があるかわからないわけですから、あまりいいUIとは言えません。

明確な理由やメリットがないのに、一般に定着しているUIルールから逸脱するのは避けるべきだと思います。

ただ、check*padのような例外もあります。


ここで表示されているページは、すべてユーザーが入力したモノです。つまりユーザーはプルダウンボタンをクリックする前からどんな選択肢があるのかを知っています。

このサービスは「とことんシンプル」がサービスの大きな魅力になっています。クリック数を少なくすることは、このサービスを選んでいるユーザーの希望に適います。

しかしcheck*padはあくまで特殊な例であり、普通のサービスでは、このようなUIは選ぶべきではないでしょう。

選択された項目がすぐに反映

webサービスでは特殊ですが、オフィスソフトなどでは当たり前の用に使われているインターフェースです。
ワープロソフトなどでは、フォントを選択した直後にそれが画面上で反映されます。


クリック数を減らす以外にも、プルダウンで表示されている内容と、実際に表示されているものとの不一致を避けるという意味で、実は優れたインターフェースかと思われます。

fashionwalker.comでは、ソート条件にプルダウンが使われており、条件を変更した直後に画面上で反映されます。プルダウンで表示されている条件と実際の表示とがずれることを避けています。


しかし条件と表示件数を続けざまに変更すると、画面の表示内容がついてこれないようです。
動的なプルダウンを使うのなら、正常に動作することは必須条件だと思われます。そうでないと、ユーザーを混乱させることになります。

また、Yahoo!ショッピングのように、ソート条件を並べて表示しても問題ないわけですから、本当にプルダウンにしなければならないのか？をよく検討したほうがいいでしょう。

プルダウンを動的な絞り込みに使う

Yahoo!グルメでは、まず都道府県を選ぶとさらに詳細なエリアの選択プルダウンが動作する仕組みになっています。


OPTGROUPを使って項目を階層化し一つのプルダウンにまとめるやりかたもありますが、リストが長くなるだけで使い勝手があまり改善されないからか、それほど一般的ではないようです。

Yahoo!グルメのプルダウンは絞り込み目的です。選択は必須ではないですし、都道府県だけで絞り込みをやめることもできます。
渋谷の店を検索したい場合、プルダウンで「東京」「渋谷」から階層を辿ることもできますし、検索窓に直接入力「渋谷」と入力することもできます。

また、どうしても「渋谷」で検索したい場合、そのユーザーは渋谷が「東京都」であることを知っているので、わき道にそれるということはありません。

「選択肢を選ばなくてもいい」「どの選択肢を選ぶべきかすぐにわかる」との条件を満たしていますし、階層化するよりもいいのなら、採用してもよさそうです。

一方でYahoo!ブログのカテゴリ選択に使われているプルダウンは悪い例です。
ディズニーランドに行った日記を書いてカテゴリを「テーマパーク」にしたいとき、「テーマパーク」がどの親カテゴリに存在するのかわからない可能性があります。直接「テーマパーク」を入力するフローは存在しません。


そもそも「テーマパーク」というカテゴリが存在するのかも前もってわからないので、「どの選択肢を選べばいいのかすぐにわかる」というルールにも反しています。

カテゴリを入力させたいのなら別のUIを検討するか、タグのような「アバウトなカテゴリ」にしたほうがいいかもしれません。

最後に

今回はプルダウンに限った話でしたが、フォームに違和感がある場合、他にも検討するべき要素はたくさんあります。

1年前のエントリー「会員登録フォーム3つのポイントと5W1H」は未だに有効だと思いますので、そちらもお読みいただけるとうれしいです。

ちょっと前に、「初心者にとって、友だちから教えてもらったケータイのアドレスを登録するまでの手段が難しすぎる」といった内容のエントリーを書きました（『データを登録してもらうための工夫』）。

「ケータイへのアドレス登録は、まだ使い方を把握しきれていないケータイ購入直後に行なうことが考えられのに、メーカーはユーザーレベルを想定せずに機能を設計しているのでは」という内容でした。

この件について、「最新の機種同士なら、ケータイ同士をくっつけるだけで自分のアドレスを相手に伝えることができる、IC転送という機能がある」と教えてもらいました。
これはすばらしい進化だと思います。


「作ったモノを楽しく使ってもらうには？」というのは、モノヅクリをする人なら絶対に考えなければいけないことだと思います。

ケータイでいえば、ビジネスツールであり、ガジェットであり、コミュニティツールでもあります。
そしてそれぞれの役割ごとに、利用してもらうための要件があります。

コミュニティツールとして楽しめるのは、コミュニケーションをとる相手あってのことです。ケータイでいうと

• 電話をする相手が存在する⇒相手に電話をするための手段を入手している
• メールをする相手が存在する⇒相手にメールするための手段を入手している

が絶対に必要です。
同じコミュニティツールであるmixiなどと、このあたりは変わりません。

つまりコミュニケーションツールとしてのケータイの楽しさを知るには、すでにケータイに複数の連絡先の情報が設定されていないといけないのです。
イコール、連絡先登録ができない人は楽しさに気づけない、ということになります。
（もちろん実際はほかにも楽しめる方法はあるのですが、今は措きます）


相手のメールアドレスを登録したくなったとき、これまでならどんな手段があったかというと、

• 相手からメールが来たら、それを登録（相手にメアドをどうにか伝える必要あり）
• 赤外線通信（赤外線受信モードのやり方がわからないと使えない）
• 手入力（それが簡単にできるのなら苦労しない）

です。どれもケータイ初心者にとって敷居が高すぎです。

しかしIC転送だと、受取る側はなにもしないくていいのです。
「メールアドレスを交換する二人ともが使い方を知っていないと苦労する」だったのが、「どちらかが使い方を知っていれば簡単にアドレス交換できる」になりました。これは大きな改善だと思います。



みんながみんなコミュニケーションツールとしてのケータイの楽しさを知る必要はないとは思うのですが、とはいえ私はプランナーですので、どんな場面でも「みんなに使ってもらうためにはなにが必要なんだろう？」というのは考えていたいな、と思います。

タブを使ったインターフェースを多く見かけるようになりました。

「タブ」と「（選択済みを表示する）メニュー方式」は、見かけが違うだけのように思えます。
が、できることなら区別して利用するべきだと思います。

たとえばYahoo!では、検索フォームにはメニューインターフェースを、ニューストピックスにはタブインターフェースを採用しています。


それでは「タブ」と「メニュー」とでは、見え方以外になにが違うのでしょうか？ どう使い分けるべきなのでしょうか？

私は、タブとメニューとは、ユーザーにどのような世界感を伝えたいか、どんな世界でユーザーにサイトを利用して欲しいか、で使い分けるべきだと思っています。

（アバウトな表現はあまり好きではないのですが）「世界感」は、ユーザーが「このサイトと、どんな風に付き合えばいいのか」「どんな立場で利用していいのか」「自分が、サイト内のどこにいるのか」を知るのに重要な要素です。

おなじみヤコブ･ニールセン博士は「タブメニュー13のガイドライン」の最初で以下のように記しています。

タブを使って、同じ文脈の中で表示内容を切り替えられるようにしている。（別のエリアへの遷移にタブを使うわけではない。Amazon.comを筆頭によく見られるようになった間違ったタブの使い方である。）
（『タブの正しい使い方』Jakob Nielsen博士のAlertbox）

ニールセン博士の言う「同じ文脈」とはどういうことなのでしょう？
webサイトをどの範囲でとらえればいいのか、という話になります。


例としてアメブロを挙げてみます。

アメブロでは、メニューがタブ形式になっています。自分のブログの編集も、タブの中で行ないます。


本来、ウォッチリストである「トップ」と、自分のブログを編集「ブログ」は、ニールセン博士のガイドラインを読むまでも無く別に扱われるべきものですが、アメブロではそれらをすべてタグ内に含めることで、ユーザーに

• サービスはアメブロのもの
• アメブロが用意した世界で、アメブロのルールに則って楽しんでね

とのイメージを与えています。

アメブロのような「サービス内に閉じた世界」がある一方で、はてなダイアリーやYahoo!ブログのように、日記編集機能をタブの中に納めないサービスもあります。ブログの更新は個人ブログに遷移して行うようになっています。こちらは「サービス外に開いた世界」と言えるかもしれません。


それぞれの世界にメリット・デメリットがあります。大事なのは、その世界感を決めるのは、どちらが使いやすいかの比較はもちろんのこと、サービスの戦略で決められるべきという点です。


世界感が固まると、ページのコンテンツも自然と固まってきます。
「個人ブログのページはその個人のものなので、勝手に広告コンテンツを載せないようにしよう」「日記編集機能はタブではなく個人ページ上で行なわせよう」などですね。

私たちが「上流工程」と呼んでいるフェーズから生み出されるものが「戦略」「世界感」だと思うのです。


UIを考えるときには、サービス単位で検討することはもちろんです。
しかしキャズムを超えるためには「戦略なくして世界観が成り立たない、すなわち優れたUIを構築できない」という考えが必要になってくるのだと思います。

“Plagger”というフィードアグリゲーターがあります。
この存在を僕は知人から教えてもらったのですが、彼はPlaggerの仕組みを、わかりやすい図を描いて説明してくれました。

しばらくして、USのYahoo!が“Yahoo!Pipes”というサービスをリリースしました。
できることはPlaggerと（ほぼ）同じなのですが、驚いたことにそのPipesのUIは、Plaggerのときに知人が描いてくれた説明図そのままでした。


Plaggerと比較してPipesが評価されたのはそのUIだと思います。そのときに思ったのが
UIを構築するアプローチとして、「機能を説明する図をそのままをUIに落とし込む」というのは有効
ということでした。


UIを考えるのって大変です。
そんなときは、それができることを説明する図を作ってみて（プレゼン資料のついで、でもいいかもしれません）、その図をUIに落とし込んでみるというのもいいのではないでしょうか。


以上、あまりにも当たり前なことかもしれないのですが、自分の覚書きとして。

ブログの記事ページの遷移に良く使われるのが「前へ」「次へ」といった文言です。

1. 過去の日記に移動するためのリンクは「次へ」にするべきなのか、それとも「前へ」なのか
2. そのリンクは画面の左側に置くべきか、それとも右側が適しているのか

ちょっと前のエントリーでも触れましたが、そのときは特に明確な答えは出せませんでした（『たつをの ChangeLog』でも調査されていましたね）。

ここ数日、仕事でこの「前次問題」について考える機会がありました。
それについて僕なりの答えを書いてみようと思います。


いきなり結論ですが、日記は時系列で扱われるものですから、普段私たちが時系列を扱うときと同じルールを適用するべきだと思います。

時系列の代表であるカレンダーでは「左が過去、右が未来」です。縦のカレンダーなら「上が過去、下が未来」。日記の並びもそのようにするべきです。

つまり、ある日記を画面に表示していて、それより古い（つまり過去に書き込まれた）日記に遷移するには（ページを横に並べたとして）左方向に進む動きをさせる。
具体的には、画面の左側に過去の日記を表示するリンクを設置したほうが直感的ではないでしょうか。


ではなぜ、世間には右側のリンクをクリックすると過去にさかのぼるサイトが多いのでしょうか。

グーグルの検索結果のような、ページ遷移が当たり前にあるサイトでは、最初に表示されるページは左端であるのが普通です。次のページへ移動するリンクは画面の右側に設置されています。
ページ右側に過去をさかのぼるためのリンクを付けているサイトが多いのは、おそらくはこの「スタートページは左端」ルールに従ったものと思われます。
このような暗黙のルールがありながら、日記サイトだけ逆にするのは混乱すると考えたのでしょう。

ただこれは、時系列サイトに「前へ」「次へ」という、どんなルールでソートされているかわからなくさせてしまうような文言を利用したがための混乱ではないでしょうか。
そもそもリンクの文言は、どのようなルールで遷移するものなのかをユーザーに伝えるものにするべきです。
日記なら「過去の日記へ」「新しい日記へ」のように、リンクテキスト自体に時間の概念を与えれば混乱することはないと思います。


まとめると、

• そのコンテンツが、どんなルールでソートされるべきかを考える（日記なら時間軸）
• 日記のページ遷移は、左に進むほど古い日記、右に進むほど新しい日記
• 上下なら（日記に付けられたコメントなど）、上が新しいもの、下が古いもの
• 文言は「過去の日記へ」「新しい日記へ」などのように、時間軸をあらわす文言にする

となります。


mahataさん（知人以上友人未満の関係）も同じことを発言されていました。


と書きつつ、このブログがそのルールになっていないことに気づきました。週末に対応します…。

Wiiブラウザ用のYahoo!検索がリリースされました。ハードに合わせてUIがカスタマイズされているそうです。

試してみたところ、ボタンクリックで操作できるUIになっていたり、そのボタンサイズが大きくなっていたりと、確かにWiiに特化したインターフェースであることがわかります。

Wiiユーザーのユースケースとは

PC以外のハード向けにwebサービスを提供するとき、どうしてもそのハードの特徴からインターフェースが決められがちです。
DSならタッチペン入力に対応させるとか、ケータイならなるべく容量を抑えてダイレクトにアクセスさせる、などです。

しかし（何度も同じことを書いていますが）、UIを構築する上で本当に大切なのは、ユースケースであると思います。


ボタンのサイズがどうとか、10feetの距離がどうとかも重要ですが、それはハードが異なれば対応するのが当然であり、「10feet UI」などは検討されて当たり前のレベルだと思います。

検討するべきはユースケース、それを確認するためのペルソナ、シナリオなのではないでしょうか。


たとえばWiiの検索であれば、web検索よりカテゴリ検索のほうが、Wiiユーザーには使われるかもしれません。
カテゴリ検索よりも、Yahoo!のサービスの中からWii向けなものを一覧で表示したほうが、Wiiユーザーにとっては需要があるようにも思えます。
（余談ですが、Wiiの所有者層にはYouTubeよりY!ビデオキャストのほうが扱いやすいのでは、と思います）

それにはもちろん、「Wiiの利用者にマッチする検索って、カテゴリ検索でいいんだっけ？」というのを何かしらの方法でリサーチする必要がありますし、そもそもそれを思いつくためにはマーケティング視点を持つ人物がスタッフにいないといけません。


はてながすごいと思うのは、そのあたりの視点を、技術者集団でありながら持っていることだと思います。

技術的には「はてなでないと作れない」というレベルではない（と思われる）Rimoですが、企画の段階で「Wiiを使う人ってどんな人たちだっけ？」という視点でサービスが構築されているのがわかります。

ハードが違えばUIだけでなく機能も違っていい

最近、母親に『らくらくホンⅢ』をプレゼントしたのですが、この機種もハード的な視点でUIが組まれているように思えます。
文字が大きくなっていたり、会話がゆっくり聞こえるようになっていたりと、機能としてはいいのですが、たとえばアドレスブックに知人のメールアドレスを登録するときに、ただ画面上の文字が大きくなっているだけで、登録フローに工夫がまったくされていないというのはどうかと思います。（一般的なほかのケータイと同じフロー）

ましてや、『らくらくホン』の『初めてマニュアル』に「赤外線通信を使ってみよう」との見出しは、いくらなんでも敷居が高すぎると思います。


まず「どんな人が使うのか/使わせたいのか」「その人は何を求めているのか」「その人が満足するのは何が達成されたらなのか」を把握した上で、「それを達成するための手段は？」という視点でwebサービスは構築されるべきだと思います。

そのときは、もしハードが異なるのであれば、UIや操作フロー、提供する機能自体が異なっていてもいいのではないでしょうか。
WiiやケータイのブラウザがPCと同性能になったとしても、決して同じシチュエーションで利用されることはないのですから。

webサービスを作るときはまずPC版を作り、その後でモバイル版を用意する、というパターンが多いと思います。。
その場合、モバイル版はどうしても「PC用の縮小版」になってしまいがちです。

しかしインターフェースを考える上においては、「ハードの性能差」よりも「利用する場面差」のほうが大きなポイントのはずです。そもそもPCとモバイルでは利用する場面が違うのですから、単なる機能縮小で済ませていいはずがありません。
（そうでなければ、ケータイの性能がアップすればすべて解決、となります。しかしそんな単純な話だとは思えないのです）


モバイル版のUIの特徴として入

• 力を極力少なく
• ダイレクトに遷移
• 1ページあたりの情報量を少なく

が挙げられると思います。

しかしvoxはちょっと違う考えで作られているようです。

たとえば。モバイルサイトのログインでよく使われる手法に「ケータイの固有情報を送信させる」というものがあります。
voxではこれに加えてさらに、数字4ケタのパスワードを毎回、入力させられます。
しかしこれが実際に使っていただければわかると思うのですが、特にめんどくささを感じないのです。

引き替えに、セキュリティー面での信頼性向上というメリットを得ています。（ケータイは落としたりして他人の手に渡る心配がありますからね）

ほかにも、PCと連携するべきところ、PCの仕様を無視するべきところの判断が絶妙で、モバイル版もとても使いやすくなっています。ページの遷移も極端に少ないなど、モバイルの得手不得手がよく研究されたUIだと思います。


webサービスを作るとき、もしPCとモバイルで担当者が違うのなら、モバイル版のスタッフにはPCのUIを一切見せずDBの仕様だけ渡して「これでサイトを作ってください」と依頼する、くらいでもいいのかもしれません。PC版のことは一切忘れて、モバイル独自のインターフェースを構築した方が、結果として使いやすいものになるのかもしれないのです。

いっそのこと、「同じDBにアクセスしてるけど違うサイト」ぐらいの考え方で作ってしまう、というのもありかもしれません。


よく「今後はモバイルが中心になる」という意見がありますが、それとも違う考え方、「PCとモバイルで全く別のアプローチをするべき」という流れになるのかもしれませんね。

Flickrは、画像ストレージツールとして考えると少々もの足りませんが、ソーシャル画像サービスという視点から考えると、公開設定の仕様やUI、IAも含めて深く考えて作られていることがわかります。（たまたまいい感じになっているだけなのかもしれませんが）

ツールとサービスの違いは、（webに限っていえば）そのサイト内で完結するものなのか、またはサイト外のどこかとつながりを円滑にするための手段なのか、にあるような気がします。


マーケティングにはAIDMAのような、段階を経て購買にまでつなげるメソッドがありますが、それはwebサービス内でも適用されます。
「まずは機能に気づかせて、次に素材を登録させて、その後にソーシャルであることのメリットを享受させて、さらにその後で外部サイトとの連携で…」などです。

webサービスのUIとは単純に「ボタンの位置が…」などで評価されるものではなく、フロー全体で見る必要があります。
そうなるともうプロジェクトの設計段階でマーケティング担当者に参加してもらった方が良さそうです。

逆にツールは、UIのわかる技術者が少人数で一気に作ってしまった方が、いいものができるのかもしれません。
livedoor readerなどは、その典型だと思います。

先日、制作中のサイトフローを確認するMTGをしていたときの話です。

とある機能のデフォルト設定をどうするか？でちょっとした議論になりました。

「デフォルト設定をどっちにしたら便利かって、人それぞれだよねぇ」というのが決まらない理由でした。

このようなときに役に立つのが『ペルソナ』です。


ペルソナとは、『コンピューターは難しすぎて使えない』の著者であるアラン・クーパー氏が提唱した手法で、対象とする仮想のユーザーデータのことを指します。


手法をものすごく簡単に説明すると、ペルソナが

• 何を体験したいのか
• 最終的になにを達成したいのか

を設定した「ユーザーゴール」と、ペルソナの行動パターンを定義した「シナリオ」とを作成し、サイト構築時になにか判断するときは、それらを使う、というものです。


サイト制作の課程では検討と決定とが繰り替えされるわけですが、そのとき「このペルソナにとっては、どちらが有効か？」と考えるわけですね。


このように開発プロセスにおいて、プロジェクトメンバーの方向性を統一できるのがペルソナの魅力です。

前から書きたかったテーマです。


AjaxやDHTMLの普及は、（適所で利用することで）ユーザビリティーの向上に貢献しました。

リッチインターフェースはユーザーに新たなエクスピリエンスをもたらしたわけですが、それだけではなく、製作現場にも変化を起こしています。
前々から何度か触れている、「UI構築作業が一気にプログラマーにシフトした」という点です。

しかしインターフェースのajax化は、期待されているほどCSの向上、ユーザー数の確保に結びついていないようです。
理由として、「UIとはなにか？」という定義に、PGとプランナーとに差があるからだと思います。

そこで「UIとは？」を、あらためて考えてみようと思います。

すでに蓄積されている情報を利用した、ファインダビリティ向上・CS（Customer Satisfaction = 顧客満足）向上の方法を検討してみます。


サイトを運営していると、いろいろデータが蓄積されてきます。次々と新作が発表される商品データであったり、ユーザーのログであったりです。
それらデータは、主に次の販売戦略を練るために利用すると思います。

そのデータ、販売戦略だけでなく、UIの使い勝手向上に利用することも可能なのではないでしょうか。

有名サイト『たつをの ChangeLog』にて、「『次』と『前』の意味と並び順」というエントリーがありました。以下、一部を引用します。

次の日、前の日、次のページ、前のページ、次の記事、前の記事。
「前」「次」はそれぞれどういう意味か。
またそれらはどういう順番で並んでいるか。
気になったので調査中。

疑問に思ったけどそこで終わりだった私（このエントリー）と、ちゃんと調べてしまうたつをさん。こういうところが積み重なって、私とwebの最先端を行く人との差になるのだと思います…。

サイトを公開する前のユーザビリティーテストはとても大事です。

ただ実際は、ある程度サイトが完成に近づいてからテストを行う、というところがほとんどだと思います。
現実問題として、サイトが動作していなければテストもできないわけで（実はそんなことないのですが）、そうなると人件費や納期の関係で、どうしてもテストが行われるのは完成ギリギリになってしまうようです。

最近のサイトは、テンプレートを使って構築するのがほとんどだと思います。
テンプレートを使うメリットは、デザインとロジックの分離だといわれていますが、それを使うことによって起きた変化は、今のところはあくまで制作者レベルのもので（それがとても大きなことなのは確かなのですが）、ユーザーが得た恩恵があまりないような気がします。

mixiをやっていたら見つけたサイト。

出会いと別れ　～　過去から現在までの彼氏彼女を振り返る恋愛診断

よくある恋愛診断サイトですが、フォームの細かい工夫に引かれました。

HOW（どうやって）

機械作業は機械にやらせるべき

紙ベースの登録フォームより、気をつけるべき要素を増やすことは絶対にいけないことだと思います。
特にPCが苦手な人にとっては、PCになにかを入力する、という時点ですでに敷居が高くなっています。これ以上の負担を要求するべきではありません。

1. 半角・全角はサイトで変換させる

郵便番号を入力すると、「郵便番号は半角で入力してください」とエラーメッセージが出ることがあります。
エラーメッセージを出しているということは、入力されたデータの半角・全角をプログラムで判断しているということです。だったら自動的に変換してくれ、と思うのは当然です。

WHO（だれが）

ユーザーに入力させる意味は？

1. その項目は自動収集できないか？

コミュニティーサイトで会員登録時に「興味のあるジャンルは？」と質問したとします。
ここで得た情報は、広告メール配信や今後の運営のために利用されると思うのですが、その目的なら、もっと信頼できるデータ収集方法があるのではないでしょうか。

これまでのを読み返したら、あまりに冗長な文章。反省。
なるべく簡潔に書くように注意します。

WHERE（どこで）

登録フローの最中にユーザーを不安にしてはいないか？

1. 今が登録フローのどのあたりなのかを教える

登録フォームはシンプルであればあるだけ、ユーザーに要求する作業量が減ることになります。
しかし、課金サイトなどでは、多めに項目を入力してもらう必要があり、そのためどうしても登録フォームページが複数枚になってしまうことが考えられます。

web制作者・プランナーには「自分が欲しいサイトを作る」という人がいます。もちろんそれ自体はとても正しい考えだと思います。
ただそのとき、「欲しい機能」と「それに適したユーザーインターフェース」は別であることに留意しなければいけないと思います。

「自分が欲しい機能が提供できている＝多くのユーザーが欲しがっている機能を提供できている」というのは、おそらく外れていないと思います。
しかし、機能とインターフェースは別であることを忘れると、「機能は提供できているけれど使いづらい、つまり提供できていないのと同じ」といった状況に陥りやすくなります。

WHEN（いつ）

最初に入力させる必要があるか

前回も書きましたが、ユーザーにとって、入力してもメリットにならない項目があるのは、会員登録の敷居を高くすることになります。
それが「評価のために試しに一度くらい使ってみよう」というときならなおさらです。あれやこれや根掘り葉掘り質問されたらうんざりしてしまうでしょう。

しかしサイト運営側としては、貴重なユーザーデータを収集するチャンスですから、なるべくなら答えて欲しいものです。

どのような工夫が考えられるでしょうか。

かなり前に会員登録について途中まで書いておきながら、そのまま時間がたっていました。今回はその続きです。


mixiの独走で勝負あり、と思っていたSNS界ですが、『ソーシャルネットワーキング.jp』さんなどをチェックしていると、「まだまだ勝負はこれからだ」とばかりに、いまだ毎日のように新しいサイトが生まれていることに驚かされますね。


SNSをはじめとしたコミュニティーサイトでは、当然ですが会員数を集めることがとても重要です。
そのためにはマーケティングや営業、もちろんサイト自体の内容も大事ですが、わけても囲い込みの具体的な手段である「会員登録フォーム」は重要です。

会員登録フォームを作る上で注意するべき点はいくつかあると思いますが、わたしが特に重要視しているのは

• 紙ベースよりも難しいのは論外
• 登録フォームはニーズ合致判断の場所でもあることを忘れない
• 入力し直しが不親切だと致命的

の3つです。

当たり前のことですが、サイトのトップページというのは重要です。

ユーザーがサイトを訪問する目的は実に多種多様です。特にポータルサイトともなると、文字通り「人の数だけ」状態でしょう。それなのに、スタート地点でもあるトップページがその目的をさばくことができないと、たとえサイトに掲載されている情報が優れたものであっても、その評価は低いものとなってしまいます。

ではトップページは、サイト訪問者の目的に対してどのような役割を果たすべきなのでしょうか。

一口に「デザイン」と言ってもいろいろあると思います。特に日本では、デザインと言うと「アート」を連想する人が多いのではないでしょうか。web制作会社のデザイン課に、イラストレーターさんが多いのもその延長だと思います。

僕はwebデザイン、特にwebアプリケーションのデザインとはアートというより、イスのような工業デザイン、もしくは住居や店舗のような空間デザインに近いんじゃないかと思っています。

共通するのは、長期間および繰り返し使用したときの使い勝手を重視する点です。

Googleを使っていて再検索をするとき。

画面下のフォームを選択しようと、クリック。



「あ、これ、Googleツールバーの広告じゃん！」

クリックしてから気づくけれど、すでに画面は遷移したあと。

紛らわしいですねぇ。ちょくちょくこのわなにはまります。

これをUIってカテゴリーにしていいかどうか悩むのですが。

ブログとか日記で、過去のを読むときにクリックするボタン。あれ、

「次の10件」
「前の10件」

日記をさかのぼるときにどっちをクリックすればいいのかわからん！

しかもあまり統一されていないし。

「次」「前」が、行動にかかるのか日付にかかるのか、なんですけど。

もう素直に「2/22以前のブログ」とかにしませんかねぇ？ ブログのボタン。

会員制サイトでその力を表すのは、言うまでもなく会員数だ。
サイトのイキオイを表す指標であるのはもちろん、サイト上に企業が高校を出すときの価格に直接影響する。

なので会員数は増やしたい。

僕がかかわっているサイトでは、会員登録フォーム殻の漏れ率が9割近い。これはちょっと問題だ

BeBitのセミナーに参加したときに遠藤社長が「漏れ率は工夫することにより65％までに押さえられる」とおっしゃられていた。

漏れ率が90→65％まで減少すると、月当たりの新規会員登録者数が、えーと…す、すごい。

もちろんこんな単純なわけではないだろうけれど。