情報大工のひとりごと

「Webサイト構築」記事の一覧

Webコンテンツ作成支援、はじめます

2014年10月 3日(この記事のみ表示

業界を問わず、志を同じくする方々と議論などしていると必ず出るネタの1つに、「TCを主戦場とする人間がWebサイトの「コンテンツ」に進出するべき」という話があります。似たような話はここでも何度も出しているので、長年のお客様にはお馴染みの話でしょうか。

「わかりやすく正確に」「ユーザーの立場で」情報を処理することが第一とされるTCを専門領域とする人間からすると、現状のWebコンテンツには以下のような問題があるように思えます。

キャンペーンサイトや販促情報以外のコンテンツ品質
ライティングからコストを掛けているかどうか、またはいわゆる先方支給または既存リソース(マニュアルやカタログ、社内資料など)からの流用で済ませているかどうかが大きな理由なのでしょうが、後者の品質に問題を抱えていることが多いと感じています。ここで問題視しているのは流用すること自体ではなく、流用される情報の品質が低い、またはコンテンツの文脈にあっていないという点です。
なお、前者がユーザーにとって質の高いコンテンツになっているとは限らないことも大きな問題でしょう(後述)。
正確でわかりやすい情報開示による長期的信頼構築、という視点の欠落
事業者側の目的には合致しているのでしょうが、ユーザーの目的を満たすコンテンツとして成立しているのか?に疑問があるコンテンツが、相変わらず多いように思えます。例えば、コストを掛けて作成されたキャンペーンサイトや販促情報であっても、「事業者に不利な情報をごまかしがち」という文化は、紙媒体カタログの頃から変わっていないのではないでしょうか。
UXが一般用として認知される程度まで普及してきたものの、正確でわかりやすい情報が(長期的UXを成立させる土台となるべき)事業者とユーザーの信頼関係を担保するという観点が話題になることはほとんどありません。Webサイトというメディアはユーザー主導のプラットフォームであるという認識が一般化した現在になってもなお、です。
購入後/契約後のコミュニケーション設計がユーザーの利用状況を踏まえておらず、独善的
釣った魚には餌をやらない」と揶揄されるような情報提供スタンスは以前から変わっていないようです(この辺りの問題意識は、懐かしきWebSite Design Vol.8で書いた記事からほとんど変わっていません)。ここ数年では、さらに「一度毟った相手からは何度でも毟り取る」的な、事業者の本音があからさまなコミュニケーション(と称するもの)が増えてきていると感じます。
また、購入後/契約後のコミュニケーションを意識している場合でも、事業者の期待する行動を喚起することにばかり重点が置かれ、ユーザーが抱えている問題を解決する意識が低いようです。FAQやトラブルシューティングをはじめとした各種サポートコンテンツの品質もそうですし、サポートコンテンツへの動線設計自体も大きな問題として捉えるべきです。

で、この辺の問題をそろそろ何とかしたいのです。そして何とかできるのは、TC系の素養のある人間なればこそ、と思うのです。

なんとなく問題意識を持ってはいるものの「うまく問題点を言語化できない」「改善のための端緒としてどこから手を着ければよいのか悩んでいる」といった事業者さんやWeb屋さんがいらっしゃれば積極的に話を聞かせていただきたいですし、少しでも力になれるのであれば協働してお役に立ちたい。また、アプリの一般化に対して、ネットワーク上に展開する機能説明や操作説明、サポートコンテンツ(例:FAQやヘルプ)の整備が質的にも量的にも追いついていないのが実状と思われますが、この部分の悩みについても十分お役に立てるはずです。

ということで、決意表明とともに有限会社文書情報設計のサービスメニューに「Webコンテンツ作成支援」を追加いたしました。興味をお持ちになる方がいらっしゃいましたら、まずはお気軽にご連絡いただければ幸いです。「仕事としてはともかくとして、とりあえずこの辺の問題を肴に飲みたい」お誘いももちろん大歓迎です(笑)

ドキュメントなお話

2013年3月15日(この記事のみ表示

例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れてくるUIの外部仕様を知ることではなく、機能全体を理解すること、そして機能訴求ポイントや訴求方針を押さえることです。そういった面を全部想像してライティングするよりも、当該設計/実装に至った経緯を記した検討資料や各種仕様書(いわゆる「ドキュメント」)を入手して、エンドユーザー向けにコンテクスト変換した上でブラッシュアップ、必要に合わせて不足情報の追加というフローで作業した方が、正確で重要なポイントを押さえた成果物につながるわけです。それも効率良く。

なのですが、どうもこのドキュメントを要求する行為を甘えと取る人がそれなりにいるようで、なんだかなあという感じです。資料開示すればすぐに問題が解決するにも関わらず、どうして開示を嫌がって原稿作成工程に無用の負荷を掛けたがるのか、理由がまったく謎です。新規テキストをスクラッチでイチから起こすことと、エンドユーザーの利益(ひいては製品やサービスの提供側の利益)と、重要なのはどちらでしょうか。いろいろ見聞きしている範囲ではありますが、何を優先するべきか?の判断基準がズレてきてるなあ...と感じることが増えた今日この頃です。

この種の問題のありがちな原因として、開示できるレベルのドキュメントを残していない(から開示できない)というのであれば、それはそれで大問題ですよね。開発&コアグループだけで検討や情報共有が完結するならば、整理されたドキュメントなしでも(当座は)良いのでしょうが、デザインにせよテキストにせよ、あとから外部発注作業を入れることが前提であるならば、絶対に何らかのドキュメントを残す必要があります。それに運用フェーズや人事異動でメンバー変動が発生することを考慮に入れれば、「開発&コアグループだけだからドキュメントは不要」という弁解が通るはずがないのは自明だと思うのですがね。

ところで、エンドユーザー向け外部説明(各種ガイドやヘルプ、FAQ)の構成検討は、製品・サービス仕様検討と並行して進めるべきというのは、一体いつになったら一般化するんでしょう。仕様検討の段階で「これは仕様で対応、これはUI上のテキストラベル他で対応、これはヘルプなど外部説明で対応」のようにしっかり考えておかないと、最後になって「マニュアル(ヘルプ)に書いておけばいいや」のお約束が発動することになります。エンドユーザー向けのFAQを検討するなかで、仕様検討から漏れている観点も拾うことができるという効用も、いまいち理解されていないようです。ただコストダウン圧力の余波で最近はお疲れ気味とはいえ、メーカー系はなんだかんだでまだしっかりしてる印象です。Web屋さんはHCDとか言うのであればもっと頑(ry

ということで、「ドキュメント出して」「ドキュメント作って」「ドキュメント観点も大事」というまとまりがないようなあるような怪しい三本立て(何)でお送りしました。

情報大工的CMS導入のポイント

2009年9月14日(この記事のみ表示

前から書こうと思ってストックしていたネタだったのですが、多忙にかまけて失念していたことをDITA騒ぎの最中に思い出したという(汗)

えーと、CMSの導入が当然のような流れに世の中ではなっているようなのですが、遅まきながら気になることを書き連ねておきたいと思います。なんか実体験の反省が入っているとかいないとか...。ああ、胸の奥が痛い

  • 構築するのは部品DB?それとも最終表現系コンテンツDB?
    任意に組み合わせて出力することを前提とした(DITA的な意味での)正規化された部品情報のデータベースなのか、媒体にあわせて表現を最適化した最終表現系のコンテンツデータのデータベースなのか、CMSの導入目的を検討段階で明確にしておく必要があります。この点が曖昧なままだと、あとでいろいろと揉める原因になります。揉めるだけなら良いのですが、そもそもの導入目的と合致しない仕様のCMSが完成してしまっては、目も当てられません。
  • 事前分析は時間をかけて念入りに
    特に部品DBとして構築する場合ですが、部品粒度を決定するための既存コンテンツに対する事前分析が質・量ともに不足すると、後工程での大幅な手戻りにつながります。表現に揺らぎがある場合に、どこまでを共通部品として扱うのかを決定するような場合にも、事前分析の質・量が結果的にモノを言う場面が多いです。同様に、ある程度の量の実データを投入して構造モデルの妥当性を検証しながら精度を上げていかないと、やはり後工程での手戻りにつながります。目先の手間を惜しむと後で痛い目にあう、という典型例でしょうか。
  • 現物(既存コンテンツ)の性格を把握する
    CMSで管理する以上、情報の標準化・正規化が伴うのは必然ではありますが、最終的には既存データを修正する必要が出てくる場合も考えられます。ここで問題となるのは、様々な理由で現物の構造や表現を(コンテンツ制作部門の一存では)変更できないような場合で、この種の条件が最初から自明であるならば、構造設計の時点で回避策を検討することが必要です。また、複雑な運用ルールが要求されることが多くなることも予想されるため、運用ルールを検討しながらシステムの設計を行う必要が出てきます。
  • 導入後の運用ルール構築はしっかりと
    CMSの運用ルールとは、CMS操作マニュアルや狭義の入力マニュアルだけではありません。記載内容の品質を維持し、表現のブレを防止するための入力ガイドラインや文例集ワークフローを踏まえた業務手順書も当然必要です。また、「適切な入力」を支援するUI面での工夫(例:初期状態で入力フィールドに入力ガイドラインを表示)も重要です。で、システム設計および情報構造の事前分析段階から、この辺の運用ルールをエンドユーザーを巻き込んで整備しておくことが軽視されていないでしょうか?箱(システム)だけ作っても、運用できなければ意味がありません。長期間継続してコンテンツの品質を維持できないようでは、CMSの意味がないのです。

まあ、CMS屋さん的には当然のこととして行われている、当たり前の話ばかりですよね。ですよね???というのは、「"DITA"と"CMS"- DESIGN IT! Forum 2009 参加レポート」を読んで、何とも言えない不安感に襲われたからなんですけど(汗)

やはり上記のポイントのうち、最後の項目については忘れられていることが多いようですね。そもそも部品粒度を下げること(=情報の枠組を詳細に作り込むこと)の効果は、部品(情報)単位での抜け・漏れおよび部品内の記載内容のブレの防止、による品質向上にあると思うんですよね。で、その辺をサポートできる存在という意味で、CMS屋さんはドキュメント屋さんと組むといろいろと良いことがありそうなものなんですが、いかがでしょう(笑)

携帯電話はWebコンテンツのあり方を変えるか?

2007年2月27日(この記事のみ表示

iPhoneの発表を契機として、携帯電話のUI改善をテーマとした話はいろいろと出てきましたが、携帯電話がWebコンテンツに与える影響という観点の話はほとんどなかったように思います。この問題について昨年から考えていたことを少し整理して、皆様のご意見を伺ってみたいと思います。というわけで3年10ヶ月ぶり(笑)の新規研究発表「携帯電話はWebコンテンツのあり方を変えるか?」を公開します。

といっても、多分それほど目新しい話はなく、おそらく車輪の再発明ばかりでしょうけれども...。まあ当たるも八卦、当たらぬも八卦(笑)

ご意見などありましたら、ぜひコメントなど頂ければ幸いです。

Web 2.0でも取り残される?サポート情報

2006年11月29日(この記事のみ表示

Web 2.0では「ユーザー体験の品質向上」ということが良く言われるんですが、サポート情報は蚊帳の外という感があります。

まず、Webの世界におけるマニュアルやヘルプそのものの質が上がっていないと感じます。コンテクストを意識したAJAXによるユーザビリティ改善という発想があるなら、ヘルプに関してもコンテクストを踏まえて欲しいものです。商用アプリケーションでは(画面単位レベルが多いですが)コンテクストを意識したヘルプトピック呼び出しは常識ですが、Webサイトではこの辺イマイチですね。いまだにヘルプのトップページへのリンクのみというのは、ちょっと。商用アプリケーションとWebサイトでは、開発者のコミュニティが分断されているのが原因なんでしょうか。ユーザビリティテストでも、サポートドキュメントに対するチェックはやってなさそうですしね...。

製品情報を扱うWebサイトにおける、サポート情報の扱いも酷いものです。個別の製品情報を表示しているページで、サポート情報へのリンクがグローバルナビゲーションにのみ存在する(つまりサポート情報のトップページへのリンクしか存在しない)というのはどういうことでしょうか。個別製品のページを閲覧しているのであれば、当該製品のサポート情報をそのまま閲覧できる経路を用意するのが当然だと思うんですが...。サポート情報を閲覧してから購入するかどうか判断する商品もあるでしょうし、制作者側がもっとユーザーの心理を考えるべきです。

ここで無理矢理Web 2.0的な方向に話を持っていくならば(笑)、まずは製品ごとのサポート情報URLを固定することが必要でしょう。で、サポート情報は継続的にRSS配信するようにして、購入した機種に関連するサポート情報をユーザーが簡単にいつでもチェックできるようにする、と。ただRSSの購読登録などは一般ユーザーにはまだまだ厳しいでしょうから、その辺の仕組みはうまく隠蔽する必要があります。例えば、製品ごとにユニークなIDを割り当てておいて、WebサイトでそのIDとメールアドレスを入力すれば詳細登録方法の案内メールが届くのでも十分ですし、携帯ユーザー向けには、マニュアルの表紙に登録用URLのQRコードを用意するといった手もアリです。そもそも、更新情報ならメール通知だけでも十分かもしれませんし。

この辺の仕組みや挙動については、できれば家電メーカーで統一するというか共通の枠組みを用意して、Web 2.0的に(笑)利用できるようにすれば良さそうに思えます(これなら海外メーカーから非関税障壁だと文句も言われないでしょうし)。リコールまではいかない不具合通知とか、単に各社がそれぞれWebサイトの「お知らせ」コーナーに掲載するだけの今の方法よりも、よっぽど効果がありそうです。特に白物家電を始めとする各種生活家電など、情報家電以外の長寿命製品には効果的でしょう。(最近の製品トラブル続出に伴う)購入ユーザーへの情報伝達の難しさを見ても、サポート情報の伝達方法を再考する良い機会ではないかと思います。

いままでユーザー登録というと、顧客囲い込みの一環という発想しかなかったように思われます。しかし、新製品のお知らせなど、メーカー側の商魂丸出しの情報を送ってもらうために、ユーザーはユーザー登録をする訳じゃないんです。それよりも、部品保有期限が切れそうな時期に「そろそろ修理用の部品がなくなるので、調子が悪い個所があれば早めに修理依頼を」というお知らせを出してくれるとか、そういう気配りこそユーザーがユーザー登録という仕組みに求めるもののはずです。情報の取捨選択の主導権がユーザー側に移行している以上、ユーザー保護の観点を重視しつつ、あえて囲い込まないアプローチも模索する価値があると考えますが、いかがでしょうか。

ちぐはぐマーケティング

2006年4月10日(この記事のみ表示

極端な多忙という訳ではないのですが、なぜかバタバタしており更新が停滞気味で申し訳ありません。更新が停滞していると「お忙しいんですね」と言われて困ってしまいますが、そういう訳でもなかったりしますので、お気になさらぬよう(謎)

さて、Webサイトやインターネットを利用したサービスにおけるユーザー体験ということは良く言われたりするんですが、普通に生活を送っていると「ユーザー体験的にこれってどうなのよ」と思うことは多々ありますよね。

  • 住宅ローンの借り換え審査を放置しておく一方で、目的型ローンのDMを平気で送ってくる三井住友銀行とか。住宅ローンの借り換え申し込みを却下したその日のうちに外貨預金やらの金融商品を勧めるDMを送ってくるソニー銀行とか。ええ、ちょっと私怨入ってます(笑)
  • こっちは零細企業だというのに週に何回もセール商品案内のFAXやメール送ってくるDELLとか。零細企業がそんなにモノ買える訳ないだろうに。もう少し常識というか節度を持って欲しいところです。よく言われているように、一度買ったら馬鹿みたいにセール案内を送り付けてくる楽天の店舗も同様です。

ユーザー体験を通して形作られる企業に対するイメージというものは、(言うまでもないことですが)Webサイトそのものだけではありません。実店舗のサービスの質もそうですし、ユーザーに対するすべてのコミュニケーションのチャンネルが関わってくるものです。その意味でハードウェア製品そのもののデザインや使い勝手だけでなく、付属する各種マニュアル/ヘルプも立派なコミュニケーションチャンネルの1つです。

従って、マニュアルの表紙が本体デザインを意識したデザインになっていて、「さすがau design project製品だ、購入した甲斐があった」と思ったら中身のデザインがボロボロで「上っ面だけのデザイン統一かよ」とがっかりしたneonのような事例では困る訳です。もちろんこれも私怨です(笑) その点、Appleはさすがにこの辺徹底していますよね。

上記のような問題が頻発していることを踏まえると、どうもこのすべてのチャンネルを統括してコミュニケーション戦略やユーザー体験を設計する機能(組織/人)が不在のまま、放置されているように思えます。単に放置されているだけならまだマシで、この種の機能の重要性が未だに認識されていないのではないかという気すらします。ブランドマネジメント担当部門が存在する以上、この種の部門もあるべきだと思うんですけどね。

Web 2.0の議論で散見されますが、個別の技術論とか実装論なども確かに重要です。とは言え、やはり専門化された個別チャンネルが高度に統合される時代にあっては、(全体を俯瞰しつつ)個々のユーザーにどのような体験を提供したいのか?ということこそ最重要視すべきです(もちろんボトムアップを単純に否定する訳ではありません)。顧客満足の観点から個別チャンネルが有機的に連係していくようなサービス設計を行わないと、違和感や不快感の残るユーザー体験はいつまで経っても減らないことでしょう。

データ中心という面からのWeb 2.0

2006年2月22日(この記事のみ表示

昨年から自分なりにいろいろ考えていたことがあるので、(車輪の再発明的な話ばかりで申し訳ありませんが)とりあえずまとめてみました。各種オフ会などで友人には話したことがあるのですが、そういうものは完成度度外視でとっとと公開しろ(Web 2.0精神...)と随分言われましたので。

まずWeb 2.0でデータ中心という話が出てくる前提ですが、

  1. データの内容だけでは機械的に処理できない
  2. メタデータを付けよう(提供者側からはRSS提供など、ユーザー側からはソーシャルブックマーク=SBMによるタギングなど)
  3. メタデータを付けやすいデータにしよう(ただし、特にblogエントリのカテゴリや個々のエントリ中の内容のバラつきなど、実際に利用価値があるデータになっているかどうかは別の話)

という流れがあったかと思います。もちろん知的財産の共有という大目的あればこそ、ですが。

ただ、大元のデータに関しては、やはりblogとか写真だけだといまいちつまらない(笑)訳です。商業ベースで制作・流通されているコンテンツ(映画とか音楽とかに限らず、広義のコンテンツ)を利用したいというのが、ユーザーの偽らない心境でしょう。

そうなると、

  • コンテンツを借り物状態のまま利用する(SBMなど、ユーザーがメタデータを付けて無理矢理利用する)
  • 公開されているコンテンツやAPIを利用する(amazon.comや楽天のアフィリエイトなど)
  • 「コンテンツ抱え込みは良くない、シンジケーションしやすいように公開しろ、公開した方がメリットがある」とユーザーがある意味居直る(CGMに貢献した方がビジネスメリットが大きいという意見)

ということになります。Web 2.0のポイントはデータの利用価値にあるというのも、このコンテクストで考えるべきです。

ここで問題となるのは、「公開した方がメリットがある」という主張が妥当かどうかです。確かにamazon.comのように、最終的にコンテンツ(=データ)が物販の入り口に直結しているような場合は妥当でしょう。公開することによって自らのビジネスの機会が明示的に増大するからです。しかし地図コンテンツ(特に道路や建物がベクター化されているような手の込んだもの)が良い例ですが、コンテンツベンダ自身(地図データであれば地図作成会社)が無償で公開する動機付けに欠けるケースも多いのではないでしょうか。

ここで地図データを例にして考えてみましょう。この分野でのWeb 2.0的なサービスとしてはGoogleローカルがあり、Googleローカルはゼンリンにお金を払ってベクター形式の地図データの提供を受けているようです(衛星写真モードの話は置いときます)。この投資をどのように回収するかですが、ローカル検索上で地図とPOI(Point of Interest)を組み合わせて、地図コンテンツに投資した費用をGoogleがクライアントの広告費用という形で間接的に回収するという形になると思われます。

この場合、最終的なコンテンツ提供者(ゼンリン)のビジネスというよりはむしろ、それを組み合わせて売りにできるシステム提供者(Google)のビジネスになっているわけです。Web2.0絡みでよく言われているリミックスやマッシュアップというのはこういうことで、Web 2.0的なビジネスをしようと思うのであれば、「公開した方がメリットがある」というスキームをシステム提供者が設計できるかどうか(Web 2.0的なコンテンツ公開をコンテンツ提供者とユーザーに納得させられる絵を描けるかどうか)が一番重要なポイントになります。

逆に言えば、コンテンツ提供者側がこの絵を描けないようだと、たとえシステム提供者のサービスがコンテンツに依存するものであっても、サービスのイニシアチブを自ら取ることは永遠にできないということになってしまいます。地図データなしにサービスが成立しないにも関わらず、ビジネスの主体はGoogleになっているGoogleローカルの存在がその代表例です。コンテンツ生成にコストがかかる上に、公開という手段がビジネスに直結しにくいニュース記事や地図などのコンテンツの場合、この辺が悩みどころでしょう。個人的には、ビジネスになりにくい種類のコンテンツが軽視される世界は好ましくないと思っていますので、現場の方の発想に期待したいところです。

まあそんなこんなで、Web 2.0時代ではデータがモノを言うのは確かなんですが、そのデータでビジネスができるかどうかこそ問題だという点にももっと注目が集まって欲しいところです。また、単にデータでビジネスをするだけならGoogleやYahoo、MSN(Microsoft)などのすでに巨大なデータベースを持つシステム提供者の総取りビジネス強者必勝の世界になってしまうでしょうから、その流れにアイディアでどう対抗していくのか?が今後の見所ではないかと考えています。

購入「後」にも経験デザインを

2004年8月23日(この記事のみ表示

業務多忙で更新が停滞してしまい、申し訳ありません。停滞している間にも多くの方にご訪問して頂いているようで、さすがに無理やりにでも再開する必要があると思い直しました。という訳で、停滞気味の間に考えたことを少しずつ発掘して、リハビリを始めたいと思います。

伊勢丹メンズ館でスーツを購入して、接客に驚きました。店員さんの接客態度云々ではなく、購入後(サイズ調整後)の引き取りに行ったときに驚いたんですけど。これまでの経験では、サイズ調整後の引き渡しカウンターというものは余剰人員置き場(失礼)感が漂っているスペースだったのですが、伊勢丹メンズ館では全然そのような感じではなかったのです。洗練された物腰の中年の店員さんが気持ち良く対応してくださって、伊勢丹に対する良いイメージが非常に強く残りました。

最近利用したオンラインショップでも、同じような経験をしました。購入受付メールやその後のフォローを含め、購入プロセス自体もさることながら「その後」に対する気遣いを感じたのです。「買って送って終了ではなく、買って送ってからが関係の始まり」とでも言うべきでしょうか。この辺は楽天やamazonの定型メールとはえらい違いですね(まあ、これはこれで必要十分という面もあるかと思います、購入者的にも)。

ユーザーエクスペリエンスが重視される中で、購入プロセスの経験デザインは進んできたと思うのですが、購入「後」プロセスについてはどうでしょうか。確かに、購入「後」プロセスは現実世界(包装/梱包や流通、その他)との関わりが強く、一概に(特にWebサイト関連だけで)どうこうすることは難しい面があることも否定できません。ですが、商品購入の経験デザインというのものは、購入「後」のデザインなしには完結しないと思うのです。

その意味で、経験デザインというものは、多くの部署や人々を巻き込んでいかなければ成立しないんだなあ、と改めて痛感した次第です。

Webサイトにおけるテキスト情報の重要性

2004年6月24日(この記事のみ表示

「商品購入意思決定に企業ホームページの掲載情報が大きく関与」(ネットレイティングスのリリースINTERNET Watch記事)というニュースが出てきたのですが、「だから言わんこっちゃない」というのが正直な感想です。

以前「Webサイトの製品情報について考える」でまとめたように、こんなことは前から明らかだったのですが...。先日JAGATのセミナーでお話させた頂いたように、生活者としての自らの経験がWebサイト構築に全然反映されていないということが、問題の一端にあるのではないかと思います。「忙し過ぎて生活者としての日常生活など送れない!」説もありそうですが、その辺の文句は経営者の方に廻して頂くということで(笑)

さて少し視点を変えて考えてみると、このような問題が出てくる背景には、Webサイト制作においてテキスト情報が軽視されがちなことにも原因がありそうな気がします。Web制作会社を見ていると、ビジュアルデザインやシステム、コーディングといった分野には人材を集めているものの、テキストの専門家を集めているという話はあまり聞きません。「テキストなら誰でも書ける、日本語だし」という意識であるならば、「マニュアルなんて余剰人員に書かせればいいじゃないか、日本語だし」というどこかで聞いたような話とレベルは同じでしょう。もちろん最下層の話ですけど

単にテキスト情報といっても、カタログで使用されるようなものと、何かを説明するためのものでは大きく異なります。作成に特殊な能力が必要とされる訳ではないとは思いますが、それでも何らかの訓練は必要です。また、アクセシビリティの実現という観点からも、今後はテキストの扱いがより重要になってくると思うのです。内容を伴ったアクセシビリティを実現するためは、媒体や表現手法にあわせたテキストのコントロールが必要になりますが、テキスト情報の扱いに精通した人材がいなければ、このようなコントロールは期待すべくもありません。

いくら情報の視覚化が一般化したところで、「情報を伝える」ことを目的とするならば、情報伝達の基盤となるテキスト情報を軽視することは自殺行為です。魅力的な商品訴求というコピーライティング中心の思惑から離れて、もっと基本的な部分でのテキスト情報の重要性を再認識すべきでしょう。その意味では、(前記事とは異なる意味で)テクニカルコミュニケーション分野の人材との相互交流という試みも面白いと思うのですが、いかがでしょう > Web制作会社の経営層の方々

RIA上での操作情報デザインを考える

2004年6月17日(この記事のみ表示

先日のJAGATのセミナー午後の部を聴講して、RIA(Rich Internet Application)の現状について勉強させて頂きました。情報の密度も高く、高額な費用も十分納得できる素晴らしいものだったと思います。

で、その際に各種デモを見て、何となく思ったことを。

一般的なRIAは通常のアプリケーションソフトウェア(以下、アプリケーションと略)と異なり、達成すべきタスクが明確で限定されている(例:航空券を予約する)ことが多いかと思います。そのため、アプリケーション全体の情報を提供する、独立した外部情報(既存のchm形式のヘルプや独立した操作解説ページなど)は不要となり、操作情報は操作に応じた状況依存で提供することが基本方針になります。

ただし、それでは操作前/操作中に操作全体の流れを把握できなくなり、ユーザーの不安感につながる可能性があります。従って、必要に応じてその種の情報を参照できるようにするか、または全体の流れの情報をUI側で提供する必要が出てきます。外部情報を参照させずに操作に集中してもらいたいというRIAの狙いからすると、操作情報をUIへ統合するという後者の方法が望ましいでしょう。操作情報のUIへの統合というネタは以前から主張してきたのですが、ようやく一般化するところまで来た、という感じです。

しかしこのような外部情報を軽視すると、操作にあたっての前提理解や制約条件といった情報をどのように提供するか、という視点が抜け落ちてしまう可能性があります。この種の情報は操作する前に提供されるべきものですが、実際にUI上でこの種の情報を提供しようとしても、文字情報だけを並べても読んでもらえることは期待薄でしょう。かといって、理解してもらわないことには、操作の終盤段階で「それではタスク実行できません」というユーザー体験としては最低のケースにつながりかねません。

そのような事態を防ぐためにも、ユーザーシナリオや操作手順、情報伝達システムを入念に設計することが必要で、先日のセミナーでもこれらの設計プロセスの重要性が強調されていました。ですが、通常のアプリケーションでもこの辺の設計はヘロヘロなのに、RIAになった瞬間に問題が解消される、というのは幻想に過ぎないでしょう。結局のところ、WebサイトやアプリケーションのUI設計や情報設計に携わる方でも、操作情報のデザイン経験が乏しいということにも原因があるのではないでしょうか。その意味で、テクニカルコミュニケーション分野の人達の関与が、もっと必要ではないかと思います。

まあそんなこんなで、RIA上での操作情報の提供手法については、今後も見守っていきたいと考えています。

検索エンジン最適化と情報設計の狭間で

2004年6月 3日(この記事のみ表示

検索エンジンを自社のマーケティングに活用することを目的とした、SEO(検索エンジン最適化)と呼ばれるWebサイトの再構築が流行ってるようですが、以前からちょっと気になっていることがあります。

SEOのプロセスを詳細まで熟知している訳ではないので外している可能性もありますが、検索に使用されるキーワードを意識して情報を構成するという考えかたそのものに、漠然とした不信感があるのです。例えば、Googleでは見出しやリンク部分に含まれる文字列が検索結果に大きく影響する、つまりキーワードの配置場所として効果が高いと言われていますので、その辺を中心に文字情報をコントロールすることがまず重視されることになります。

ですが、そのような文字情報のコントロールによって、Webサイト内を回遊するユーザーへのわかりやすさが損なわれる可能性があります。つまり、キーワードが一般名詞として完全に認知されていない場合は、Webサイト内の情報カテゴリ名やナビゲーションのタイトルにキーワードを使用すると、使い勝手の面で問題が発生する可能性がある、ということです。これは何故かというと、キーワードのような特殊な名称よりも、一般的な言い回しの方が表現としてわかりやすいためです。

また、キーワード重視の姿勢がWebサイト全体の情報設計に影響を及ぼす可能性も出てきます。極端な例ですが、キーワードを元にした情報分類が強制されることで、ユーザーの動機を中心とした情報設計に影響が出る(ユーザーの利益と相反する)ことも考えられます。これらの問題を引き起こさないためにも、「SES(サーチエンジンスペシャリスト)に求められる素質」でも触れられているように、

WebページをSEO施策で改善する際にも、SEO施策後のページが、 ユーザーが見て違和感を感じないページなのか、ユーザビリティの観点からはどうかなど配慮し、SEOのためのSEOにならないようにしなければならない。

japan.internet.com | SES(サーチエンジンスペシャリスト)に求められる素質

ことが非常に重要となってくる訳です。

検索エンジン経由のユーザーが多いというのは、確かにその通りです。ですが、検索エンジンへの最適化が(訪問後の)Webサイト内回遊への足かせになってしまうようでは、目先の訪問者数が増えたところで、総合的に見て得策とは言えないでしょう。そこまで承知の上で検索エンジンへの最適化を優先するのであれば良いのですが、果たしてどこまで理解されているのかは疑問です。現状の検索エンジンからの訪問者を増やすためには仕方がないとはいえ、本末転倒は避けて欲しいところです。

Yahooがページ検索をGoogleから独自エンジンYST(Yahoo Search Technology)に切り替えたことがニュースになりましたが、検索技術の仕組みはほとんど変わっていないようです。これはつまり、本末転倒の最適化が存在する余地がまだまだあるということです。このような問題を解消するためにも、Webサイトの情報設計がユーザーに最適化された状態でも、必要な情報を過不足なくスムーズに入手できる(=表面的な言葉の設定で検索結果が左右されない)検索技術が、一刻も早く登場して欲しいものです。

Webページの文章を読みやすくするために

2004年3月 1日(この記事のみ表示

エディトリアル・デザインはウェブ・デザインの夢をみるか」(wellinton's blog)に基本的に同感(行長&字数制御の必要性は特に!)で、読みにくいWebページはまだかなり多いと思います。人文系の長文だけでなく、技術系の翻訳モノにも読みにくいWebページが多い印象がありますね。InDesignの師匠(笑)に組んで頂いたフォーマットで紙媒体データを制作する仕事が最近続いているのですが、しっかりした版面設計を見慣れたあとにWebサイトを見ると、正直いろいろと辛いものがあります。

ユニバーサルデザイン志向という理念だけでなく、閲覧環境(Webブラウザ&表示デバイス)の多様性に対応しきれないという現実からも、この問題に対する決定的な解決策は見つかっていません。ですが、それを言い訳にして、読みやすさの実現を最初から放棄しているような印象も受けます。ある程度の決め打ちを含めて、一般的(これが困難...)な環境での読みやすさは、もっと追求されてしかるべきだと思います(アクセシビリティに関しては、プレゼンテーションとデータの分離によって保持すべきというのが持論です)。

読みやすさを改善するためには、「CSSにおける国際的レイアウト」のように、読みやすいデザインを実現するための仕様/技術を拡張することがまだまだ必要だと思います。またそれだけでなく、いわゆるエディトリアルデザインを専門にするデザイナーが、Webの世界にもっと出てくるべきでしょう。もちろん紙媒体からの転身であるか、電子媒体育ちであるかは問わず、です。

その一方で、デザインだけで読みやすさを改善するのはやはり限界があります。その意味で、読みやすいWebページを実現するためには、テキスト側にも電子媒体にあわせた工夫が必要となります。紙媒体でのライティング習慣を電子媒体にそのまま持ち込んでも、読みやすさにはつながらないのです。「簡潔に!(ウェブの文章作法)」(Alertbox)のようなWebページ用ライティングの必要性は以前から訴えられていますが、具体例を元にしたWebページ用のライティングガイドラインがそろそろ必要なのかもしれません。

ちなみにこのサイトでは、以下のポイントを意識するようにしています。このくらいがテンポ的にも良さそうという判断なんですが、いかがでしょう?

  • 読点(、)の数は、1文あたり最大で3個までにする(複雑な依存関係の文章は分割して、接続句で対応する)。
  • 1段落(パラグラフ)は4〜5文で構成し、CSSを利用して段落間に適度な空きを確保する。
  • 文章の数が少ない場合でも(標準想定閲覧環境での)行数が多くなってしまった場合は、できるだけ段落を改める(7〜8行がリミット)。
  • 4〜5段落ごとに、見出しを付ける(または何らかの休みを入れる)。
  • 情報の構成にあわせて、ul(並列)やol(順列)などのリスト要素を適宜活用する。

つまり、「段落の持つ意味合いを紙媒体と電子媒体で分ける」ことこそ、Webページ上で読みやすいテキストを実現するための最重要ポイントではないか?ということです。段落の役割として(厳密な)意味のまとまりを伝えるよりも、読むためのまとまりやテンポを与える機能を重視することで、Webページの読みやすさは大きく改善されるのではないでしょうか。

小田急ロマンスカー特急券:りたーんず

2004年1月22日(この記事のみ表示

以前「誰もが固まる特急券券売機」として取り上げた小田急電鉄の特急券券売機ですが、同じような不満を持っていた人は結構いらっしゃったようです。問題の特急券に代わる新しい券売機も昨年あたりから導入され始めましたが、使い勝手に関しては改善された面もあるものの、利用客を「うっ」と固まらせてしまう面も残しているところは流石です(設計メーカーどこだろう...)。

この新券売機の話はまたそのうちネタにするということで、今回取り上げるのは特急券に関連する別のシステムの話です。

二、三年ほど前から、ロマンスカーの特急券は携帯電話から予約購入がきるようになりました(ITmedia過去記事)。駅に行かずに特急券を購入できること、用事や仕事がいきなり延びてしまって購入した特急券が無駄にならないようにとりあえず予約だけできることなど、利用者にとってメリットの大きなものになっています(利用したことがないので、システムの使い勝手についてはノーコメント)。こうした特徴もあり、この予約システムの利用者は確実に増えている実感があります。何よりも、乗車してきて携帯の画面を見ながら座席を探す人が多くなっていることが、その証といえるでしょう。

これでは良いことずくめのようですが、そうは問屋が卸しません(笑)

実はこのシステムの利用者が増えるに伴って、駅で特急券を買えないことが増えています。特にラッシュ時間に新宿を発車する特急に顕著なのですが、満席になるのが異常に早いのです。例えば、打ち合わせで移動している間など、午後の早い時間に新宿駅に立ち寄って帰りの特急券を確保しようとしても、すでに満席。それにも関わらず、発車時間の1時間前あたりからそこそこの空席が発生することも稀ではありません。

これは予約システムで特急券の「予約のみ」が可能になったため、早い時間にとりあえず予約という形で特急券を押さえるだけ押さえておき、乗れそうだったら購入、駄目そうであればキャンセルという行動が増えていることが原因と思われます。しかし「駅で特急券を購入しようとする利用客=実際に購入する」であるにも関わらず、「予約のみの利用客=実際に購入するかどうかは不定」が優先されてしまうというのは、どうも腑に落ちません。

確かに携帯電話を利用した予約システムそれ自体に問題はありません。ですが、特急券を利用客に販売するというビジネス全体から見ると、どうもビジネスの全体設計を間違っているように思えます。利用客の姿の一面しか捉えずに、予約システムの設計を行ってしまったのではないでしょうか。新しいシステムを導入することに目が行くあまりに、当該システム利用者以外を含めた利用者全体の姿や行動を把握するという視点が欠落しているように感じます(小田急ってそういう話が多いような感じが...)。

この問題の解決方法としては、「予約のみ」利用客の意思決定(予約→購入)の締め切りタイミングを速めることも考えられますが、 これは既存のメリットを大きく損なうため、適切ではないでしょう。ですので、全座席数の30%程度はあらかじめ駅の券売機購入用として割り振っておき、予約システムからはアクセスできないようにするというのが妥当な線かと思います。で、発車1時間前程度になっても券売機割り当て分に残席がある場合は、予約システム側にも開放すれば最終的に残席が出ることもないと思いますが、いかがでしょう? > 小田急電鉄さま。

(それにしても新宿発18:30のロマンスカー、競争激しすぎ)

Webユーザビリティ評価ツール by 日立製作所

2003年9月 1日(この記事のみ表示

日立製作所から「Webユーザビリティを評価するツールを開発 」というプレスリリースが出ています。基本的には、ユーザーテスト実施スキルを持つ専任担当者がいない組織でも、ユーザーテストを内部で気軽に実行できることを狙った支援ツール、という位置づけになりそうです。テスト後にユーザー行動ログを起こすのはかなりの重労働ですので、専任担当者がいる場合でも、テスト業務全体の工数削減に寄与することが期待されます。

ところでユーザーテストを実施するにあたっては、実施担当者のスキル獲得と、テストユーザー集めが難関と思われている節があります。その意味でこの種の支援ツールにはそれなりの需要がありそうですが、本当のユーザーテストの難しさは、実は以下の3点にあるのではないでしょうか。

  1. 適切なタスクを設定すること
  2. 得られた生データを正しく解析して、問題の所在を明確にすること
  3. 問題を解決する改善案を導き出すこと

つまりテストそのものの実施よりも、タスク設定や結果解析→改善案構築という始めと終わりの部分にこそ難しさがあるのでは?ということです。

したがって、この種の支援ツールを導入しただけでは、組織の内部リソースのみでWebサイトの評価・改善案を策定するという目的を達成できない可能性が高いのではないかと考えられます。ツール導入の際には、ツールを必要とする業務の全体像と、その中でツールが担当できる部分/できない部分を事前に明確にする必要があるでしょう。

「そんなこと当たり前だろ」と思われる方も多いでしょうが、わかっているようで実はわかってないケースの方が多かったりするとかしないとか。

直接操作時代のWebデザイン?

2002年9月17日(この記事のみ表示

(前回Tablet PCを取り上げたついでに)現在のWebサイトは、マウスやカーソルキーなどといった間接操作デバイスによって操作されることを前提にし過ぎているように思えるのです。これだけでは意味が分からない方がほとんどだと思いますので、ヒントを1つ。直接操作しか存在しない銀行ATMと多くのWebサイトの違いは、一体どこにあるのでしょうか?

その違いは、クリック対象オブジェクト間の間隔、つまり誤操作を防止するための考えかたにあります。Webサイトでは誤ったオブジェクトをクリックしても、復帰が比較的容易であることに加えて、現在選択しているオブジェクトをロールオーバーで明示していることが多いため、(不適切なラベリングによる誤認を除いて)誤った箇所をクリックするという操作をしにくいのです。つまり、「選択(ポイント)→決定(クリック)」という間接操作の利点が出ている訳です。

これに対して「選択=決定」という直接操作を前提とするATMには、「選択されているオブジェクトのロールオーバー」などという観念は存在しませんから、押し間違えのないようにオブジェクトの配置間隔にはかなり神経を使います。ATMでは操作デバイスが指(笑)なので、間隔を広めに確保しておかないと誤操作を誘発するという事情もありますが、実は他にも原因があります。

直接操作を行うデバイスの表示エリアにはタッチ検出用のシート(PC Watchの記事によるとTablet PCでは背面配置のようですが)に加えてガラスなどでデバイス表面を保護するのが常ですから、どうしてもユーザーが視線で把握するオブジェクトの位置と、実際にデバイスに触れる位置(デバイス側で認識される位置)にズレが生じることになります。直接操作系の機器ではこのような視差による誤操作対策が非常に重要であり、そのためにもオブジェクトの配置間隔に十分注意を払う必要があるのです。

ここで話を元に戻すと、現在のWebサイトのデザインは、間接操作系のデザインに振れ過ぎているように思えます。特にFlashに多用しているサイトに顕著ですが、ロールオーバーなしでは成立しないナビゲーションがあまりに多すぎませんか? もちろんロールオーバーを捨てろとは言いませんが、TabletPCをはじめとする直接操作系のデバイスが今後増加するならば、この辺の問題に真剣に対処せざるを得なくなるでしょう。(直接操作を主体とする)組み込み機器のフロントエンド標準UIの地位をFlashMXが狙っていることも考えると、特にFlash使いの方々にこの辺の事情を頭に入れておいて頂きたいところです。

このコーナーにしては異常に長くなってしまいましたが、直接操作系UIデザインの感覚がWebデザインにも活かされるべきでは?というお話でした。

カスタマイズを言い訳にしない情報提供

2002年5月14日(この記事のみ表示

保険会社のWebサイト、わかりにくいと思われたことはありませんか?

保険初心者にとっては、自社商品名だけ並べられても、具体的にどれを選べば良いのかさっぱりわかりません。CMや各種パンフでアピールした商品名を頼りに探すユーザーがいることは否定しませんが、「死亡時給付」、「掛け捨て」、「入院給付」など、ユーザーが保険に対して想起するキーワードから適当な保険商品をピックアップする機能がない場合がほとんどです。それにも増して不安になるのは、どれくらいの費用がかかるのかが全く見えてこない点です。

一人一人の条件に合わせたカスタマイズが基本のため、画一的な情報提供には意味がないという判断をしているのかもしれませんが、押しの強いセールス担当をいきなり相手にするよりも、できればWeb上で事前に各社の保険商品を調べておきたいというユーザーは多いのではないでしょうか。一般消費者を対象とするビジネスにおいて、カスタマイズにかこつけて費用情報をオープンにしないという体質には問題があると言わざるを得ないでしょう。この点では、住宅メーカーも同じような傾向が強いように見受けられます。

ユーザーに合わせたカスタマイズを前提とした製品やサービスでは、下手に金額をオープンにするとかえって誤解を招くことにつながるという側面があることは十分理解できます。しかし、大まかな目安となるようなラインすら見えないということになると、ユーザーとしては事前選定の手がかりすら得られず、不安になるばかりです。それにユーザーはすべての企業の営業担当と打ち合わせをするほど、時間に余裕があるわけではないのです。Webサイトは商品の概要説明と長所訴求に特化して、実際の受注獲得は営業担当に依存するという仕組みが一朝一夕に変わることはないでしょうが、この方法は最近のビジネスの流れから取り残されていることを自覚すべきです。Webサイトの持つ信用創造という機能を過小評価してはなりません。

これらの企業のWebサイトには、簡易シミュレーションなど、ユーザーにおおまかな費用情報を伝達する仕組みを用意するべきでしょう。自社商品の長所だけでなく、費用のアウトラインや制約条件をわかりやすく提示することで、ユーザーの信頼を勝ち得る方向に情報提供のスタンスが移って欲しいものです。当研究所も費用情報はオープンにしていないので他人事ではないという話もありますが、BtoB分野ですのでご容赦を(もちろんお問い合わせ頂ければ、想定コストと要求仕様の間で適切と思われる情報をまず提示させて頂いております)。

安易なユーザー属性による分類は失敗のもと

2002年4月 8日(この記事のみ表示

ターゲットユーザーごとに情報を分類したいという場合に、安易に性別や年齢階層、職業などといった、いわゆるデモグラフィック特性による分類に頼ることが多くありませんか? しかし実のところ、教職員・学生向けに限定して販売されるソフトウェアのアカデミックパック製品のようなものを例外とすると、実はこの種の分類が有効に機能する場面は少ないのではないでしょうか。

こうした分類は、本来「〜したい」というユーザーのニーズや欲求をベースとして行われるべきです。確かに、それらの層を代表するようなステレオタイプのデモグラフィック特性(30歳の男性会社員など)を提示することで、人に対して説明しやすくなる場合もあるでしょう。しかし、分類された情報を不特定多数のユーザーが選ぶという場面を想像するならば、やはりデモグラフィック特性による分類には無理があるのです。

例えば、Aという製品または情報が欲しいというユーザーに、たまたまBという属性の人が比較的多いとしましょう。この理由だけを持って、Webサイト上でAに対するリンクを「Bの方へ」というタイトルで誘導しようとしてしまうと、それが代表的なステレオタイプを提示する意図であったとしても、B以外のユーザーを暗黙のうちに排除してしまうことにつながりかねません。「特定のデモグラフィック特性が、想定される欲求やニーズを持つユーザー層とほとんど完全に一致する」というよほどの自信(笑)でもない限り、Aに対する欲求を持つユーザー全体に対して訴求できる情報分類のタイトル(=ラベル)を用意するべきでしょう。

そういう意味で、Webサイトのトップページに「〜の方は」という、ニーズや欲求をベースとしないデモグラフィック分類をそのまま提示しているところ(例:SOHO事業者の方はこちら)を見ると、何だかなあと思ってしまいます。この辺りの基準選定については、現場レベルで理解が進んでいても、実際の決定権を持っているレベルではなかなか理解してもらえないケースが多いのではないかと想像していますが、早く状況が好転することを期待したいものです。

ところで朝日新聞の新土曜版の記事、「マニュアル不要」をうたってWebブラウザの「お気に入り」整理方法を載せていますが、その記事自体がマニュアルであるという自家撞着はいかにして解決なさるおつもりか。マニュアル批判は毎度のことではありますが、それにしても呆れて物も言えませんがな。

目に見えない価値が評価される前提とは

2001年10月22日(この記事のみ表示

当研究所が力を入れているのは、わかりやすさや使いやすさといった価値なのですが、皆様もご存じのように、これらの価値は直接目に見えるものではありません。EC系のWebサイトであれば、ユーザビリティ設計がそのまま購買実績に直結することも多いでしょうから、売り上げという目に見える価値として機能しているといえます。ですが、他の分野ではなかなかそうは行かないというのが実情でしょう。ユーザビリティ設計が劣悪なWebサイトであっても、扱っている商材の商品力でカバーしてしまうような力技が通用してしまう面もあるので、難しいところです。

そうすると、目に見えない価値をお客さまにどう理解していただくのかが大変になります。この場合のお客様は最終的なエンドユーザーではなく、マニュアルやWebサイトの制作を依頼してくるお客様ですね(最終的にはエンドユーザーにもその価値を訴求する訳ですから、結果的には同じことなのですが)。ありがちな路線として、サポートコストの低減やユーザー体験の品質強化によるリピート率の向上ブランドロイヤリティへの寄与ということを中心に訴求することになるのですが、問い合わせ数の減少によるサポートコストの低減はともかく、後者のような目的は数値目標的に測定すること自体が困難であったり、実際の数値において変数としてどれだけ寄与しているのかを独立して取り出すことが困難であったり、なかなか難しいところがあります。お客様としても、感覚的に理解できても、上層部から承認を得るためには数値目標的に達成基準が客観的に測定できる必要があるため、定性的な訴求だけではなかなか認められることはありません。

本来、デザインや機能といった目に見える部分の商品力にそれほど差がないのであれば、目に見えない部分の価値が商品力として重要な価値を持ち得るはずです。そういう意味で、同じ商品を扱うことが多いEC系のWebサイトで、ユーザビリティ設計やユーザー体験の強化に力が入れられていることは当然といえます。問題は、目に見える部分の商品力が多少劣っても、目に見えない部分の商品力が他を圧倒している場合です。こうした場合でも、たいていは目に見える価値の方が優先されてしまうことが多いのです。これではいつまで経っても、目に見えない価値は商品力に寄与しないことになってしまいます。

目に見えない価値を理解してもらうには、目に見えない価値を目に見えるような形で訴求するしかありません。それはわかってはいるのですが、どうやって目に見えない価値を目に見えるように実装していくのか、そして目に見えない価値を定量的に評価するスキームを作り上げるのか、なかなか難しいところです。ですが、ここを乗り越えないと、マニュアル制作やユーザビリティコンサルといった業界が「おたくの○○○はデキが悪い。デキを良くしないと祟りが〜」というような恐喝産業(苦笑)として認定されてしまうことでしょう。最近ユーザビリティ関連で派手な動きも散見されますが、目に見えない重要な価値を、それなりの対価が必要とされるものと理解してもらえるようになるためには、まだまだ地道な取り組みが必要とされているのではないでしょうか。

コンテクストを考慮しない評価に意味はなし

2001年8月 6日(この記事のみ表示

マニュアルの比較評価やWebサイトのユーザビリティ評価などの結果を目にする機会がありますが、納得させられるものに出会うことは少ないようです。研究発表でも何回か取り上げた通り、基本的な評価の方法や評価軸といったものは存在するはずなのですが、なぜ納得させられるものが少ないのでしょうか。

その最大の原因は、それぞれの個別性、つまり市場におけるメーカーや製品のポジショニングであるとか、想定された目的であるとかを、きちんと織り込んで評価がなされていないことにあります。Webサイトの評価などはまだ良い方で、マニュアルの評価にあたっては評価者が実機に触れることがないどころか、評価対象となる製品カテゴリーに対する根本的な理解を欠いていることすら珍しくありません。「そのような立場の人間が評価した方が、初心者ユーザーにはフレンドリーなものになる」という意見はよく聞きますが、(言葉は悪いのですが)はじめからド初心者をある程度切り捨てる方針でマニュアルが制作されることは、決して珍しいことではありません。情報提供にかけるコストと対象ユーザーの割合を考慮して、現実的にそうした判断がなされることがほとんどなのです(もちろん大きな声では誰も言いませんよ)。

Webサイトの場合では、ターゲットユーザーの絞り込みを行っているサイトの評価に同じような問題がつきまといます。自サイトで取り扱う題材に興味があるユーザーを前提として、情報のカテゴリー分類基準やタイトル付けを決定しているようなところは、評価者を選ぶのです。評価やテスト担当者が運営側の想定ターゲットをはずれていると、思いっきりマイナスの方向にバイアスのかかったデータが出てきてしまいがちです。

マニュアルにしろWebサイトにしろ、それらがデザインされ、完成物として存在するまでのコンテクストを切り捨てた評価やランキングに、どれほどの意味があるでしょうか。もちろん、それ以前の一般レベルでの問題が多いマニュアルやWebサイトが多いことも確かです。ですが、結果を真剣に検討するに値するだけのアウトプットを出せないようでは、評価という業務にどれほど必然性があるのか疑問です。そろそろこうした面を真剣に考えないと、遅かれ早かれ評価する側が信頼を失うことになるのではないでしょうか。

コンピュータ関連書籍売り場に異変あり

2001年5月20日(この記事のみ表示

昨年頃かと思いますが、新宿のヨドバシカメラ マルチメディア館のコンピュータ書籍売り場に異変がありました。いきなりデッサン技法書などのデザイン専門書がコンピュータ書籍売り場に並び始めたのです。(おそらく)今年になってからかと思いますが、秋葉原のLAOXザ・コンピュータ館の書籍売り場も同じような状態になっています。

コンピュータを利用したグラフィックやWebデザインが一般化するにつれ、デザインの専門教育を受けた訳ではない人達もこの分野に興味を持つようになりました。しかしコンピュータ関連書籍は上っ面のテクニック技法書ばかりで、本質的なデザインの入門書はほとんどありません。できればテクニック集だけでなく基本書も購入して参考にしたいという、こうした消費者のニーズをおそらく読みとったからこそ、前述のような売り場の変化が現れたわけです。実際にビジネスとして売り上げ貢献に直結しているかどうかは不明ですが、特定ジャンルの書籍購入に関してはワンストップ・ショッピングが可能になった訳で、それなりの販売機会の増加にはつながっているであろうことが推測できます。

さて、こういった考えかたはECの世界にこそ有効だと思うのです。例えば、タブレットを購入するユーザーは、デザインの専門書を購入する確率が高いのではないでしょうか? コンピュータとソフトウェア、周辺機器だけでなく、ユーザーが実際に特定の場面で必要になる製品は、もっと多いと思うのです。実際の店舗では階毎に売り場が分かれていたり店舗が分かれていたりする訳で、ユーザーは途中で購入した商品を抱えてあっちこっちへ移動する羽目になります。しかし、実際の使用場面ごとにつながりのある商品で売り場が構成されているならば、こんな苦労はなくなります。消費者のライフスタイルを意識して、ブランドや商品ジャンルにとらわれずに売り場を構成するということが小売業で注目されているようですが、これも同じような流れにある現象といえるでしょう。

しかし実際には、一つの店舗でこうした品揃えを実現することは困難であったり、さまざまな(笑)しがらみで理想的に話が進まないことが多いようです。ですが、ネットを利用した個別商店の集合体であるショッピングモールには、本来そうした制限がないはずなのです。何故こうした個別商品カテゴリー群を越えて、ユーザーの実際の使用場面に即したカテゴリー横断的な販売システムを構築できないのでしょうか?(まあ個々の店舗ごとのエゴその他であることは十分予想できるのですが、ね。)

販売不振に悩むショッピングモール系のECサイトが多いようですが、基本的なユーザビリティの見直しだけでなく、ユーザーニーズを直接とらえた形態での販売を可能にしていくようなシステム刷新も重要なのではないでしょうか。

The 1140px CSS Grid System · Fluid down to mobile