Google Wave

• Wave Gadgets – The Complete Guide to Google Wave: How to Use Google Wave

iGoogle

• iGoogle Developer’s Guide – Home – Google Code
• iGoogle デベロッパー ガイド – Google Code

Google Desktop

• Welcome – Google Desktop APIs – Google Code
• ようこそ – Google Desktop API – Google Code

Windows Desktop

• Windows Desktop Gadgets
• Windows デスクトップ ガジェット

Windows Sidebar

• Windows Sidebar
• Windows サイドバー

Yahoo!

• Konfabulator 4.5 Reference Manual – Yahoo! Widgets
• Konfabulator Tools and Documentation – Yahoo! Widgets
• Yahoo!ウィジェット – 開発ツール

Apple (Dashbord)

• Mac Dev Center: Dashboard Programming Topics: Designing Widgets
• Dashboard Programming Topics – ウィジェットのデザイン

iPhone Human Interface Guidelines

• Designing the User Interface of Your iPhone Application
• iPhoneアプリケーションのユーザインターフェイスの設計

Android

• Widget Design Guidelines | Android Developers

Opera

• Opera Widgets Style Guide – Opera Developer Community

先日、カードソーティングのワークショップをしたこともあり、カードソーティングについて改めて興味を持ち始めています。基本的にはアイデア発想法に近いところがその理由かも知れません。

「カードソティング」という言葉より、品質管理でいう「新QC七つの道具」の「親和図法 (Affnity Diagram)」および「KJ法」という言葉のほうが、日本ではもしかしたら知っている人は多いのかも知れません。

とりあえず、メソッドの理解というより便利なツールをまとめておこうと思います。

カードソーティングと言えばDonna Spencerさんの名前がまず思い浮かぶこともあり、彼女のブログ「DonnaM」を見ていくだけでも非常に参考になります。また、Boxes and Arrowsのほうに詳しく書かれた記事があります。ちなみに今年のIAサミット2009でも実際に彼女にもお会いすることができました。

• DonnaM – IA – card sorting
• Card sorting tools – a short summary
• Card sorting: a definitive guide – Boxes and Arrows: The design behind the design

そのDonna Spencerさんが書かれた書籍「CARD SORTING」の「Manual vs Software」p. 55にツールについての紹介がされています。本を買わなくても、Rosenfeld Mediaサイトの「Card sorting software tools」からも見ることができます。

また、ナビゲーションについて詳しく書かれた書籍「デザイニング・ウェブナビゲーション」の「カードソーティング」p. 178でもツールがいくつか書かれていました。こちらは2007年にJames Kalbachさんが書かれたものを浅野さんやコンセントの長谷川さんが翻訳された本ですね。

Card Sorting Tools

1. OptimalSort
   OptimalSort – online and easy cardsorting
2. Websort
   Card Sorting with Results | WebSort.net
3. MindCanvas (Open Sort & TreeSort)
   MindCanvas | A research service from Uzanto
4. xSort
   xSort is a free card sorting application for Mac OS X
5. SynCaps
   Design for Usability – Card Sorting Introduction
6. Card sort analysis spreadsheet
   Rosenfeld Media – Card Sorting: Card sort analysis spreadsheet
7. CardZort
   Jorge A. Toro
8. CardSort
   CardSort – UCD Tool for Information Architecture ※<index.php> がエラー
9. CardSword
   CardSword
10. WebSort
    Card Sorting with Results | WebSort.net
11. 11. WebCAT
    WebCAT: Overview
12. 12. uzCardsort
    mozdev.org – uzilla: cardsort
13. 13. EZSort
    IBM Ease of Use – EZSort (beta release) ※サーバーエラーのためアーカイブを参照。
14. 14. Socratic Card Sort
    Socratic Technologies, Inc.
15. 15. StickySorter
    Microsoft Office Labs – StickySorter
16. 16. Classified
    URL不明

ということで、合計16のツールがカードソーティングのツールとしてまとめることができます。

実際に「card sorting」で検索してみると、たくさんの記事があることがわかります。実際、以下のようなサマリーサイトがたくさんありました。このエントリーを書く上でも参考になりました。

• Card sorting (A-Z of user experience design resources)

最後に、Slideshareでタグ「card-sorting」での検索結果は下記から見ることができます。

• Presentations and Documents tagged card sorting

その中でBenny Skogberg氏がまとめている「Card Sorting Tools」というスライドがあったのでご紹介します。

事前課題にあげた「サイトマップ」については、当日間近 (8/29) にあった第24回Websig24/7会議「100人で考える、理想的なサイトマップの形と標準書式」を参考にしてそこで得た知識をなるべく話そうとしました。

決して、「サイトマップ (ページ)」のことを指しているわけではありませんので、あえて「ページ」をつけています。

サイトマップとは
Webサイトに掲載する情報を組織化し、その論理的な構造をツリー図として表現した資
料。画面遷移のフローチャートとして使用できるように情報が付加されることもある。

このブログのエントリーでも書きましたが、Websig24/7会議の模様は下記エントリーを参照してください。

• 第一部発表で紹介したサイトマップ(一部)公開 (WebSig24/7)
• グループワークで作成したサイトマップ公開 (WebSig24/7)

ここでも提出させてもらったサンプルがあるのですが、等斜角を持ったアイソメ図からExcelで作成したツリー図・Visioで作成したダイヤグラムなど、さまざまなカタチがあります。これはもちろん異なるプロジェクトにおいての成果物サンプルなのですが、やはりそれぞれのプロジェクト体制やドキュメントの目的は異なります。

ビジュアルボキャボラリーを活用する

「サイトマップの書式」という言い方をする場合がありますが、ドキュメントの書式というのとドキュメントで扱う情報の表現 (凡例) とは異なります。ここでは後者について概念的な理解として「ビジュアルボキャブラリー」を紹介しました。

ジェシージェームスギャレット氏の「Visual Vocabulary for Information Architecture」をコンセントの長谷川さんが翻訳したサイト「jjg.net: a visual vocabulary（日本語版）」があります。

これは，インフォメーションアーキテクトあるいはインタラクションデザイナーが，
ウェブサイトにおけるストラクチャーあるいはユーザー経験のフロー，またはその両方
を抽象度の高いレベルで記述するためのものだ。

このビジュアルボキャブラリーをすべて覚えるのでもいいのですが、抽象的な情報の (サイトマップとしての) 表現方法を理解し、ふだん作成しているサイトマップ上での表現に活かしてほしいと思います。

gihyo.jpで連載していた「Web情報アーキテクチャ（IA）とツール」も参照のこと。

ふだん扱う情報の凡例としては次のようなものが考えられます。

• 単一ページ
• リンク
• グループ
• 別ウィンドウ
• 複数ページ
• 導線
• 関連性 (関係線)

Websigでもあったのですが、この「線」の扱いについて「導線」と「関連性 (関係線)」を同一と考えている傾向が多々あるようです。ホームページから全カテゴリートップページに矢印がついているサイトマップをよく見かけるのですが、これは不適切だといえます。

矢印はステップ (進み方) としても理解できるため、ホームページと全カテゴリートップページとを結ぶ線は必ずしもその順番で画面を遷移しないといけないわけではありません。したがって、表現する場合は矢印ではなくコネクタとして (ただの線で) 表現するほうが好ましいでしょう。

最低限必要なサイトの情報

また、サイトマップには最終的に物理的 (ページ) にするための情報も含まれるため、以下のような最低限必要なページ (情報) も含めておくといいでしょう。

サイト情報/Site Information

• サイトマップ
  
• サイトの利用規約
  
• プライバシーポリシー

機能/Function

• サイト内検索
  
• RSS配信
  
• 文字サイズ変更
  
• 印刷

Flickrのほうにあげていただいたサンプルについてもいくつかコメントさせていただきましたが、こちらは別途細かく見ていくとしていくつか注意点があげられます。

• 関係性を矢印で表現しない
  
• 階層はわかりやすく構造化する
  
• 画面エリアで整理しない (見た目で分類しない)
  
• 導線にあたる線は矢印にする

潜在意識にあるサイトマップを描いて共通認識を探る

ワークとして、「企業情報」配下のツリー図を描いてみることをしました。これは潜在的に自分の中にある (ある意味) 基本的な情報構造を表現したみた場合に、他人とは違う点、また、とらえ方にも個人差があり共通項を見つけることが難しい点を体感してほしかったことが理由です。

たとえば、「プレスリリース」と言ったときにはどうでしょうか。2009年の情報をプレスリリース (インデックス) ページに含めるのか含めないのかでも書き方は変わってきます。リダイレクトするなどの情報をどう表現すれば伝わりやすくなるのか考えてほしかったわけです。

事前改題の回答例

サイトマップは比較的抽象的で構いません。何度も言っていますが、事前課題の状況を踏まえた場合の詳細度でOKです。凡例としては大分類のグルーピングがされていればほかはとくに気にならないかと思います。

ポイントとしては、以下2点が表現されていることになるかと思います。

• 「サービス・ソリューション」「施工実績」配下に共通にある「分野」などの情報分類と相互リンク (関係性) の表現。
  
• 「お問い合わせ」および「サポート情報」への矢印 (つながりの) 表現。

さて、次は「ナビゲーションを考えてみよう」を振り返ってみます。

関連エントリー

• 企業サイトにおける4+1のメニュー分解 (CSS Nite LP7 Redux 02)
• 最適なメインメニューを考えてみよう (CSS Nite LP7 Redux 01)
• IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)
• CSS Nite LP7「IAスペシャル」

撮影: 飯田昌之

企業サイトの情報分類

ひとくちに「企業サイト」といっても昨今の企業サイトを見れば単純な会社情報だけを扱っていないことに気づきます。つまり「事業内容」が肥大化してサービス情報として大きく取り扱う傾向があります。

企業サイトと言われるほとんどが――

• その企業の情報を扱う「会社情報系」
• その企業の事業を象徴する「商品・サービス系」

とに大きく分類することができます。

例にならって課題サイトのメインメニューを「会社情報系」「商品・サービス系」に分類してみると、ほとんどの情報が収まることがわかります。

サイトマップページには「(実は) 提供側で見てほしい情報が隠されている場合がある」と書きましたが、やはりメインメニューにも提供側の意図が見え隠れしてきます。つまり、企業情報を主にしている場合には「会社情報系」を主軸に、サービス情報を主にしたければ「商品・サービス系」を主軸に分類していることがあります。

また、「企業情報サイト」「サービスサイト」というサイト単位で分けているケースもあります。ドメインから分ける場合や管轄部署を分ける場合など理由はさまざまありますが、その企業の事業範囲とサイトに掲載している情報の規模によりどこに主軸を置くかは検討が必要です。例として、ソフトバンクモバイル株式会社の企業情報サイトとサービスサイトがあります。

企業サイトにおける4+1のメニュー分解

経験則ですが、企業サイトで扱うサービス情報には相対する「サポート情報」が含まれます。それは、そのサービス情報には「これから利用する人」「すでに利用している人」が想定できるからです。

• 新規 (商品・サービス/Webサイト) 利用者向け
• 既存 (商品・サービス/Webサイト) 利用者向け

多くの企業サイトで「お問い合わせ」が目立つ位置にあるのはこの情報群を取り出しているせいです。もちろんコンバージョンを意識した「アクション」として位置づけているケースもありますが、ここでは情報の種類で説明しています。したがって、企業サイトで扱う情報のほとんどがさきほどの2つ (会社情報系・サービス系) をこの4つにさらに分解することができます。

1. サービス
2. サポート
3. 企業情報
4. ニュース
5. 独自

また、「独自」な情報群としてその企業の独自性 (アイデンティティ) を象徴するような情報があれば情報の粒 (粒度) が異なっても含めておくほうがいいでしょう。例では、「防災のトビシマ」を独自な情報群として説明しました。

この「企業サイトにおける4+1のメニュー分解」に課題サイトのメインメニューを当てはめたものが下記です。

他社サイトの把握と業界標準

業界ごとにWebサイトを見ていくと、その業界・業態によりデファクトスタンダードが存在していることに気づきます。例では建設業界 (清水建設・鹿島建設・大成建設・戸田建設) でしたが製薬業界や金融業界などやはり一定のメニューに集約されています。ここで取り上げた他社の企業サイトでも「会社情報系」と「商品・サービス系」とに分けてみると明確にその企業の意志が伝わってきます。

B2Bにける商品・サービス系には必ずと言っていいほど「事例」や「実績」が取り上げられます。例で取り上げた他社サイトも4サイトのうち2サイトが「実績」がメインメニューに含まれていました。

最適なメインメニューのまとめ

今回の課題では、以下の2点が考慮されていればメインメニューの最適化という課題に対しては妥当性のある回答と考えられます。

• 商品・サービス系として「ソリューション」をまとめること
• 「お問い合わせ」つまり「サポート情報」を加えること

いかがでしたでしょうか。スライドでは、以下の情報群でまとめました。

• 技術・ソリューション: 商品・サービス系 (※1) としてまとめる
• 施工実績: B2B特有の情報として※1から取り出す
• お客様サポート: 「お問い合わせ」を含む情報として加える
• 企業情報: 採用情報を含む会社情報系 (※2) の根幹
• 株主・投資家情報: 上場企業としての重要な情報配信を※2から取り出す
• ニュース: 広報としての情報配信として※2から取り出す

最適なメインメニューの最適化として、さいごにまとめたのが下記3点です。

• 情報の共通項を見つける: グルーピングから情報整理ははじまる
• 他社との共通項を見つける: 業界標準を意識する
• 重視する方向性を決める: 企業情報にはその企業の意図が含まれている

ということで、「最適なメインメニューを考えてみよう」だけで2エントリーになってしまったのですが、週1くらいで振り返っていこうと思います。

関連エントリー

• サイトマップを描いてみよう (CSS Nite LP7 Redux 03)
• 最適なメインメニューを考えてみよう (CSS Nite LP7 Redux 01)
• IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)
• CSS Nite LP7「IAスペシャル」

撮影: 飯田昌之

当日のスライドはSlideshareにもアップしています。「IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)」もご覧ください。

事前課題

事前課題を出したのは、当日までに気分を盛り上げる作用もありますが、どちらかというと参加者が期待されている「IA」をワークを入れて全体像をつかむには1時間内ではどうしても時間が足りなかったせいです。

これまで参加したことのあるワークショップでは、前提となる参加者の状況や役割により意見が分かれて論点がブレてしまう傾向があると感じたため、状況を決めてしまうところから考え始めました。

• 自分は30代のWebディレクターである
• 勤務先の制作会社では、内部にデザイナーやコーダーがいる
• 来週顧客に説明に持っていく資料
• その資料は、要点が書かれていればよい
• 上司 (営業) もいっしょに同行する

この状況ですと、「サイトマップ」と言ったときに想像するものは詳細なサイトマップである必要はありませんし、デザイナーではないのでデザイン的に作り込む必要もありません。時間的にもそれほどあるわけではありませんので、時間をかけて課題に取り組む必要もないことになります。

対象サイトの選定

「飛島建設」さんのウェブサイトを対象にしたのは以下3つの理由です。

• 今どき珍しいレガシーなつくりだった
• ざっと見た程度でも改善点が見つけやすかった
• 建設業界という大きな業界のため類似サイトが多く見つけやすかった

最適なメインメニューを考えてみよう

あえて「メニュー」という言葉を使ったのは「ナビゲーション」という言葉の持つ意味と分けて考えたかったからで決して言葉の定義が揺らいでいるわけではありません。また、「7つのナビゲーション」を出したのは、前のセッションの振り返りの意味があります。

まず、サイト全体を把握することからはじめると思いますが、その際には――

• メインメニュー (ナビゲーション類) を見る
• サイトマップページを見る
• 一定時間いろいろ触ってみる

をしていくことになると思います。ヒューリスティック分析やユーザビリティ調査をしたことのある方にとってみれば、もう少し細かい作業をするかも知れませんが。もちろん個別の情報を得るにはアクセス分析ツールを見ることや、プリフェッチャソフトなどでファイルを取得して物理的な情報を見るというのもあります。

さて、その中でサイトマップページには2つの側面があります。

1. そのサイトで扱う情報 (ページ) の大分類がわかる (反対に上位階層だけの場合がある)
2. (実は) 提供側で見てほしい情報が隠されている場合がある (階層で割り切れない場合がある)

とくに2は経験がある方も多いと思います。

課題サイトでは、メインメニューで扱っている分類とサイトマップページで扱っている大分類とでやはり違いが見つけられます。これが2にあたる部分だと推測できるのですが、この段階でメインメニューの分類とサイトマップページの分類に違いがある点を見つけられればOKです。

実体をもたない情報分類

課題サイトのサイトマップページ左上には「トップページ〜」という3つの分類があります。これも前述の2にあたる部分ではありますが、どうしても画面要素で分類しがちな点は必ずつきまといます。これら3つの分類は、実体をもたない集合体でいわゆるショートカットリンク集にあたります。つまり、実体はほかの分類として分けられているのに、画面要素での分類でも見せたいという意図 (前述の2) が理由としては考えられます。

当日は3つとも対象外として説明しましたが、実は3つめの「トップページ下部メニュー」というのは無視してはいけません。「サイトの利用規約」や「プライバシーポリシー」はサイトに必要な情報群としてまとめるケースがあります (例: サイト情報)。当日は論点をメインメニューにしたかったのでここの説明は省きました。

共通項目をまとめてグルーピングしてみよう

「KJ法」や「カードソーティング」という言葉で聞くように、情報に分類にはいろいろな方法があります。課題サイトで扱うメインメニューを考える際に、そのサイトで扱う情報構造の最上位を自分の視点でグルーピングしてみるところから考えてみました。

当日も話しましたが、事前課題で取り組まれた参加者のほとんどが画面要素に分解して考えていたこと (つまりワイヤーフレームで考えていたこと) には驚きました。あえて「メニュー」と表現したの真意は、まずは情報の分類を純粋なリストで考えてみてほしかったからです。

課題サイトを改めて見た場合、ホームページと下位階層ページのナビゲーションが違っていることに気づきます。ここで、下位階層ページのナビゲーションを、ある視点で分類 (グルーピング) したものがホームページでのナビゲーションになると思ってしまうとNGです。

例として線を引いたものがありますが、さきほどのサイトマップページの分類とホームページのメニューとで突き合わせた場合に、結局まとめきれずに「防災のトビシマ」と「Bespokeサービスソリューション」が余ってしまうことになります。したがって、この2つをグルーピングしなければ、サイトの情報分類の最上位を整理できたことにはなません。例では「サービス・ソリューション」という分類を追加しています。

少し長くなってしまったので、ここでいったん区切ります。

関連エントリー

• 企業サイトにおける4+1のメニュー分解 (CSS Nite LP7 Redux 02)
• IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)
• CSS Nite LP7「IAスペシャル」

先日 (9/12) 行われた「CSS Nite LP, DISK 7」は、300人を越す参加者となり予想以上に大人数かつ大きな部屋に大きなスクリーンで、これまでにはないシチュエーションでした。

前半のセッションではどちらかというと参加者が聴く姿勢になるので、わたしのセッションではできるだけ手や頭を動かせるワークショップ形式にさせていただきました。300人強でワークショップ (?!) というのははじめてで大きなチャレンジでしたのではじめはどうなることかと思っていたのですが、みなさんの協力あってカタチにすることができました。

当初、もう少し参加者と近い距離を想定していたため、その場で課題に対する質疑応答なども考えていたのですが、想定以上に部屋が大きかったこともあり (参加者が多いということもあり) かなり小刻みにタンタンと進めるような格好になりました。

撮影: 飯田昌之

結果としては、事前課題に取り組めた方と取り組めなかった方とで大きく反応が分かれましたが、伝えたかったこと (感じてほしかったこと) は、十分に伝えることができたと思っています。

ワークについては、課題の出し方・取り組み方がうまく伝え切れずに消化不良にさせてしまった点がありました。ただ、このテーマを考える上で重要な点は伝え切れたと思います。あの場で理解できなくてもあとあと「こういうことを言わんとしていたのか」と思う場面が必ず出てくると思うので、そういった場面で活かせられれば幸いです。

別途、課題についてのエントリーも書こうと思います。

ちなみに今回「IAスペシャル」だったのですが、「IA」を専門職の領域だとかある意味遠くて現実的ではないと思われてしまうことを嫌って、このセッションでは「IA」という言葉を一回も使わずに進行してみました。また、テーマに「LPO」とあるのですが、こちらもあえて「LPO」「ランディング」という言葉はいっさい使わずに、考え方や手を動かすことで中身を伝えるようにしました。

というのも、参加者が自分たちの関わっている業務に直接関係している範囲で考えてほしかったのと専門用語を使うことで「知っている」というふうに安直にとらえてほしくなかったことが理由です。手を動かすことで「知っている」のではなく「理解できている」ということを自身で感じてほしかったことが一番の理由です。

撮影: 飯田昌之

懇親会の場で安藤さんと建設業界におけるウェブでのソリューション訴求は実際にはあまり意味がないので、現実味が薄かったとご指摘もいただきました。建設会社さんを題材にした理由は、たまたま見つけたレガシーなつくりだったことと間違い探しをしていく上で説明がしやすかったのが理由で、それ以外にはありません。

反省点

アンケートのほうで皆さんからご指摘いただけことも、自戒を込めて今後の活動に活していくようしたいと思います。

• 事前課題を取り組んでもらうような促し方ができなかった。
• 課題の取り組み方とアウトプットイメージを伝えきれなかった。
• 所々早口になってしまった。
• スライドの文字が小さい部分があり遠くの方から見えにくかった。
• グループディスカッションに時間をあまり割けられなかった。
• 時間を延長してしまった。

今後の取り組み

最後にご紹介したデジタルスケープのワークショップは、下記からご覧いただけます。

• デジタルスケープ｜セミナー・トレーニング
• 坂本貴史氏に学ぶ、WebディレクターのためのIA入門｜ワークスコーポレーション

今回の反省点を活かして、さらにパワーアップしてお届けしていきます。

• CSS Nite LP, Disk 7「IAスペシャル」が終了しました | CSS Nite公式サイト

関連エントリー

• 最適なメインメニューを考えてみよう (CSS Nite LP7 Redux 01)
• CSS Nite LP7「IAスペシャル」

• 第24回WebSig会議「100人で考える、理想的なサイトマップの形と標準書式」　終了いたしました (WebSig24/7)

また、当日のスライドもSlideshareで公開されています。

第24回WebSig会議「100人で考える、理想的なサイトマップの形と標準書式」

この中での課題定義については、以前gihyo.jpで書いていたエントリー「サイトマップと情報の構造化」も参考にしていただけたようで、以下のように定義付けをされていました。

サイトマップとは
Webサイトに掲載する情報を組織化し、その論理的な構造をツリー図として表現した資料。画面遷移のフローチャートとして使用できるように情報が付加されることもある。

ワイヤーフレームとは
画面に表示する要素とその配置を簡潔にまとめた資料。ユーザーの操作に対するシステムの反応やインターフェースの振る舞いも定義する場合がある。

ファイルリストとは
Webサイトを構成するファイルの一覧。列記する項目としては最低限、画面名（または識別子）、ディレクトリパスとファイル名（物理的な構造）、URLを含む。

今回の課題は「サイトマップ」だったのですが、やはりウェブサイト構築をする上ではそれだけで完結するものでもなく、ファイルリストなども十分に関係してきます。ここでも「ワイヤーフレームコミュニケーション研究会」のエントリーでも書いたように「前提を揃える」ことが大切になってきます。そういう意味では前提としていくつか条件があったので取り組みやすかったと思います。

提出した課題

1. ボキャブラリーの標準が浸透していないため表記がバラバラ
   
2. 論理構造なのか物理構造なのかが混在してしまうケースがある
   
3. システムフローと同等の成果物と思われることがある
   
4. すべてを網羅しようとするとA3におさまらない
   
5. 運用上の更新はすべきか、誰がすべきか
   
6. 後工程でどう使うかがわからないとどこまで必要かがわからない
   
7. 結局お客さんはサイトマップを見てもわからない
   
8. 画面IDと連動するシステムがない (ソフトではあるものもあるが)
   
9. コンテンツ管理と連動しようとするとCMSが必要になる
   
10. アセット管理や素材管理と連動したくなる

参加したグループでは以下のようなことをまとめていたと思うので思い出しながら書いておきます。

課題1 (比較的静的なウェブサイト) について

必要な情報

主によく検討する情報としては以下のようなものが必要になるかと思います。

• 識別子 (枝番IDやラベリング)
  
• 単一ページ/複数ページ
  
• 物理的/概念的・論理的 (ファイルがあるのかないのか)
  
• 静的/動的 (HTMLかそれ以外か)
  
• 関係線/導線
  
• 同画面遷移/別画面遷移
  
• 本サイト/外部サイト

必要な表現

ビジュアルボキャブラリーを決めておく。

ビジュアルボキャブラリーについては、Jesse James Garrett氏の「A visual vocabulary
for describing information architecture and interaction design」をコンセントの長谷川敦士さんが翻訳された「情報アーキテクチャ、インタラクションデザイン記述のためのビジュアルボキャブラリー」を参照のこと。

印刷対応

全部を1枚に収めるのは不可能なので説明したい箇所だけを切り出す。

課題2 (RIAのウェブサイト) について

ファセットの表現

「どんな情報に整理でき、どんな情報を扱うのか」に着目しました。
画面上にある情報をフラットに並べて再整理をし、カテゴリの整理と出力されている情報の整理をしました。タグのようなものをサイトマップで示そうとすると (ドキュメントとして) 破綻してしまうので、説明する内容を制限し、わかりやすいものに仕上げました。

感想

ないものを作り出すための作業ではなく、すでにあるものからサイトマップを作成するため、どうしてもウェブサイトを見ての判断になり画面の要素に偏ってしまうことです。したがって、サイトマップを作成する作業にも関わらず画面仕様書に近いものを作成しているグループがあったように思います。

もちろん結論として (というか実際の現場だと) わかりやすいものであればなんでもいいのですが、サイトマップを作成するという課題に対して「結果として画面仕様書になりました」だとちょっと違うかなと思いました。

実際にサイトマップを作成する (作成するというより再整理するという表現のほうが適切だと思いますが) 状況の多くが、すでにあるものを参考にすると思うので、そういう意味では近い状況にはできたかと思いますが、であれば、課題1のサイトマップ (あらかじめ印刷されたもの) はいらなかったと思います。結果的にそれにどういう情報を付け加えれば理想のサイトマップになるのかにボクがいたグループは意見を集約できたのでよかったのですが、ほかのグループの結果を見るとあらかじめ用意されたものをなくしてゼロから書き上げていたので、論点が幅広くなってしまった印象がありました。

課題としてあがっていた「理想的なサイトマップの形と標準書式」については以下のようにまとめることができると思います。

• サイトマップの理想のカタチはワイヤーフレームと同様、自分の状況や後工程に依存する
• サイトマップの標準書式はビジュアルボキャブラリーを揃えることで標準化できる

この「自分の状況」や「後工程」にどれだけのパターンがあるのかはイシューだと思いますが、そうしたことを意識しながら日々取り組んで行くことで業界全体としても理想のカタチになっていくような気がします。

少なくても「サイトマップ」という言葉で、しかも「IA」という言葉を使わずに、これだけの参加者が集まれることや、そのことにこれだけ関心を持つ人がいること自体にパワーを感じました。

「ワイヤーフレーム (Wireframe)」という言葉を知ったのは多分2001年ごろだと思います。その当時は小さな制作会社でウェブディレクターの駆け出しだったと記憶しているのですが、「ワイヤーフレーム」「サイトストラクチャ」といった資料をいただく機会があり、当時の役割である制作・実装を踏まえて、不具合をなるべくなくなるような仕様書として理解していたと思います。そのせいで、整合性がとれてない箇所を見つけては修正する、を繰り返していたと思います。

2009年7月24日 (金)、FXBの原一浩さんがTwitter上でつぶやいた一言から開催に至ったワイヤーフレームコミュニケーション勉強会に参加しました。場所はSINAPさんのオフィスで総勢30名となかなかの大人数で大盛況でした。詳しくは、SINAPさんのサイトに原さんからのレポートも掲載していただいているようですのでそちらをご覧ください。

• 「ワイヤーフレームコミュニケーション研究会」第一回レポート – SINAPlog

研究会のトピックは以下の5つ。

• ワイヤーフレームって何ですか?
• ワイヤーフレームにデザイナーが引っ張られてしまった経験は?
• デザイナーが引っ張られないワイヤーフレームを作るにはどんな工夫が考えられるか?
• コミュニケーションとしてのワイヤーフレームとドキュメントとしてのワイヤーフレームがある?
• ワイヤーフレームの共通ガイドラインはあったほうがいいと思いますか?

原さんが作成されたスライドも公開されています。

• 第1回ワイヤーフレーム研究会のスライドをダウンロードする（PDF）

参加者について「ワイヤーフレームについて思い悩むことが多いディレクターが一番多い印象でした。デザイナーが3割くらい、発注側であるWeb担当者が1割ほどといった感じ」とあるので、実際にはウェブ制作会社のいわゆるウェブディレクターが多かったように思います。

いろいろなディスカッションをしていく中で個人的に感じたのは――

• 自分のバックグラウンド (デザイナー出身かエンジニア出身か)
• 自分のポジション (顧客に接する機会が多いのかそうでないのか)
• 自分が所属する組織 (社内で制作をしているのかそうでないのか)

といったポイントが人によりさまざまなため、参加者同士でも意見が合致せずそれぞれの主張でしかなかった印象でした。ただ、これからもこの悩みは続くと思いますし解決できる部分と解決できない部分とがあると思うので個人的に思うところを書き出してみたいと思います。

1. ドキュメントの目的や使われ方、誰のためのものかを明示的にする必要がある (IA One Sheeter参照)
2. ドキュメントの書式はできるだけ標準的な (※業界一般的に浸透している) ものを利用する

このうち1について状況が違えば、やはり話はズレますし求めているポイントも違うことになります。自分の状況があたかも相手もわかっているだろうと思ってしまうとやっぱり話がズレたままになってしまいディスカッションも消化不良になってしまいます。また、1を踏まえての2でもあるため、結論として1の前提を揃えた上でディスカッションをしないと本質的な解は得られにくいのだと思います。

ただ、個人的に言えるのはどの状況においても共通して――

• ワイヤーフレーム作成の後工程をきちんと考慮すべき (誰が行い・どのように進めるのか)

これに尽きるかと思います。

たとえば、自分がデザイナーだとして表現方法をわかりやすく顧客に説明するために必要な資料とはどういうものか。おそらくオブジェクトのクラス名や数値は不要でしょう。反対に、自分がディレクターとしてデザイナーに表現を依頼するのであれば、表現と見間違う装飾的な要素は不要でしょう。

そうして考えてみると、悩みの根本的なところはその後工程のことがわかっていないことに起因するように思います。もちろん後工程のことはわからなくて結構という意見もあるとは思いますが、結局のところ自分がやろうとしている方向性や実現性を担保するためには、実現する方法や手段を知識として身につけるということと、実現する人とのコミュニケーションが最も大事なことなのかも知れません。

「ワイヤーフレーム」についてはこれまでのエントリーでもいろいろ書いてはいますが、「ウェブサイトの設計図 ワイヤーフレームを活用しよう」にいくつかまとまっていますので、興味ある方はそちらも参照ください。

• Flickr: “iaaj”

今回は、(株) ビジネス・アーキテクツの奥さんから6月に参加されたUX Insentive (サンフランシスコ) の参加報告をしていただけることになりました。
現地でのワークショップということですので、日頃の共有方法やブレストなどで参考になることが多いかと思います。興味ある方がぜひご参加ください。

【IA Cocktail Hour Tokyo】
内容: UX Insenticve参加報告
日時: 09/04 (金) 18:30～21:00
場所: (株) ビジネス・アーキテクツ 会議室
定員: 30名～40名程度
会費: 1,000円程度 (ドリンク代)
主催: IAAJ
協力: (株) ビジネス・アーキテクツ

人数制限としては、30名～40名程度とさせていただきたいと思います。
参加表明は、直接 <entry@iaaj.org> までメールをお送りください。氏名 (できれば読みがな)、所属先、メールアドレスを記載ください。

■補足

UX Intensive
2009年6月14日～17日にサンフランシスコにて開催。
プロダクトデザイン、UI、オンラインサービスのユーザーエクスペリエンス構築のステップアップを目指す、UXプロフェッショナル向けの4日間のワークショップ形式のセミナー。1日づつテーマを分けて実施。

• 1日目: デザイン戦略
  デザインをビジネスへの関連性を明確にしていくために必要なツールを紹介。
• 2日目: デザイン調査
  最も利用して欲しいユーザーの洞察を通してデザインに役立つ情報を収集するアプローチを紹介。
• 3日目: 情報アーキテクチャ
  今回は通常のIAプロセスではなく、メタデータ、コンテンツ分析、検索、分類とサイト構成例についてのアプローチを紹介。
• 4日目: インタラクション・デザイン
  モデル化やデザインコンセプトの制作から、クイックプロタイピングまでのアプローチをテスト課題に沿って実践。

Adaptive path Inc.
米国を代表する、ユーザーエクスペリエンスをテーマにプロダクツから、ウェブサービスのデザインコンサルティングを行う会社。
「Ajax」を命名した人物としても有名なジェシー・ジェームス・ギャレット氏は、「blog」の命名に貢献したといわれるピーター・メイホールズ氏と共に創設メンバーであり、共同経営者。

■関連URL

• adaptive path >> product experience strategy and design
• [bA] Business Architects Inc.

以上、よろしくお願いします。

CSS Nite LP, Disk 7「IAスペシャル」（2009年9月12日開催）

9/12（日）に開催される「CSS Nite LP, Disk 7 (IAスペシャル)」に出演することになりました。

これまでもさまざまなIAに関してのイベントはありましたが、これほど広くこれほど大きなイベントは国内初です。詳しくはサイトをご覧いただくとして、日々の (Web構築) 業務で疑問をお持ちの方やWebに限らず勉強する機会を探っている方にはまさに最適なイベントだと思いますので、ぜひご参加ください。

• 長谷川敦士（コンセント）情報アーキテクチャの全体像〜ワークフローとケーススタディ〜
• 林千晶（ロフトワーク）プロジェクトマネジメントから見たIAの大切さ
• 佐藤伸哉（ソニー）IAの欠点〜IAの本来の目的と役目
• 坂本貴史（ネットイヤーグループ）IAワークショップ〜LPOをテーマに〜
• 小久保浩大郎（iA）実装視点からのボトムアップIA
• 長谷川恭久（could）IAからWebサイトデザインへの突破口

ちなみに、わたしが担当させてもらうのはワークショップになります。

IAワークショップ〜LPOをテーマに〜
このセッションでは、特定のWebサイトを例に、リニューアルの際に制作するランディングページの制作をワークショップ形式で取り組みます。課題設定、コンセプトモデルという名で考えられる事象をピックアップ、経験フローなどをワイヤーフレームに落とし込むまでを、IA視点で解説します。

これまでもWebSig24/7やサイバーガーデンBizなどでワークショップはさせていただくことがありましたが、今回はIAについての概要や講義のセッションがあった上で実施することになるので、どのような形がよりいいお土産 (成果) になるか考え中です。

もしご意見などあればコメントいただけるとうれしいです。

なお、mixiのコミュニティでは、すでに定員を超えるほどの参加表明が上がっていますので、参加を希望される方は、お早めにお申し込みください。

• [mixi] CSS Nite | LP7（IAスペシャル）

ということで、ぜひご参加ください。