Archive for the ‘ia’ tag
16 Card Sorting Tools for IA/UX
先日、カードソーティングのワークショップをしたこともあり、カードソーティングについて改めて興味を持ち始めています。基本的にはアイデア発想法に近いところがその理由かも知れません。
「カードソティング」という言葉より、品質管理でいう「新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
- OptimalSort
OptimalSort – online and easy cardsorting - Websort
Card Sorting with Results | WebSort.net - MindCanvas (Open Sort & TreeSort)
MindCanvas | A research service from Uzanto - xSort
xSort is a free card sorting application for Mac OS X - SynCaps
Design for Usability – Card Sorting Introduction - Card sort analysis spreadsheet
Rosenfeld Media – Card Sorting: Card sort analysis spreadsheet - CardZort
Jorge A. Toro - CardSort
CardSort – UCD Tool for Information Architecture ※<index.php> がエラー - CardSword
CardSword - WebSort
Card Sorting with Results | WebSort.net - 11. WebCAT
WebCAT: Overview - 12. uzCardsort
mozdev.org – uzilla: cardsort - 13. EZSort
IBM Ease of Use – EZSort (beta release) ※サーバーエラーのためアーカイブを参照。 - 14. Socratic Card Sort
Socratic Technologies, Inc. - 15. StickySorter
Microsoft Office Labs – StickySorter - 16. Classified
URL不明
ということで、合計16のツールがカードソーティングのツールとしてまとめることができます。
実際に「card sorting」で検索してみると、たくさんの記事があることがわかります。実際、以下のようなサマリーサイトがたくさんありました。このエントリーを書く上でも参考になりました。
最後に、Slideshareでタグ「card-sorting」での検索結果は下記から見ることができます。
その中でBenny Skogberg氏がまとめている「Card Sorting Tools」というスライドがあったのでご紹介します。
サイトマップを描いてみよう (CSS Nite LP7 Redux 03)
事前課題にあげた「サイトマップ」については、当日間近 (8/29) にあった第24回Websig24/7会議「100人で考える、理想的なサイトマップの形と標準書式」を参考にしてそこで得た知識をなるべく話そうとしました。
決して、「サイトマップ (ページ)」のことを指しているわけではありませんので、あえて「ページ」をつけています。
サイトマップとは
Webサイトに掲載する情報を組織化し、その論理的な構造をツリー図として表現した資
料。 画面遷移のフローチャートとして使用できるように情報が付加されることもある。
このブログのエントリーでも書きましたが、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)
さて、「最適なメインメニューを考えてみよう」のつづきです。
撮影: 飯田昌之
企業サイトの情報分類
ひとくちに「企業サイト」といっても昨今の企業サイトを見れば単純な会社情報だけを扱っていないことに気づきます。つまり「事業内容」が肥大化してサービス情報として大きく取り扱う傾向があります。
企業サイトと言われるほとんどが――
- その企業の情報を扱う「会社情報系」
- その企業の事業を象徴する「商品・サービス系」
とに大きく分類することができます。
例にならって課題サイトのメインメニューを「会社情報系」「商品・サービス系」に分類してみると、ほとんどの情報が収まることがわかります。
サイトマップページには「(実は) 提供側で見てほしい情報が隠されている場合がある」と書きましたが、やはりメインメニューにも提供側の意図が見え隠れしてきます。つまり、企業情報を主にしている場合には「会社情報系」を主軸に、サービス情報を主にしたければ「商品・サービス系」を主軸に分類していることがあります。
また、「企業情報サイト」「サービスサイト」というサイト単位で分けているケースもあります。ドメインから分ける場合や管轄部署を分ける場合など理由はさまざまありますが、その企業の事業範囲とサイトに掲載している情報の規模によりどこに主軸を置くかは検討が必要です。例として、ソフトバンクモバイル株式会社の企業情報サイトとサービスサイトがあります。
企業サイトにおける4+1のメニュー分解
経験則ですが、企業サイトで扱うサービス情報には相対する「サポート情報」が含まれます。それは、そのサービス情報には「これから利用する人」「すでに利用している人」が想定できるからです。
- 新規 (商品・サービス/Webサイト) 利用者向け
- 既存 (商品・サービス/Webサイト) 利用者向け
多くの企業サイトで「お問い合わせ」が目立つ位置にあるのはこの情報群を取り出しているせいです。もちろんコンバージョンを意識した「アクション」として位置づけているケースもありますが、ここでは情報の種類で説明しています。したがって、企業サイトで扱う情報のほとんどがさきほどの2つ (会社情報系・サービス系) をこの4つにさらに分解することができます。
- サービス
- サポート
- 企業情報
- ニュース
- 独自
また、「独自」な情報群としてその企業の独自性 (アイデンティティ) を象徴するような情報があれば情報の粒 (粒度) が異なっても含めておくほうがいいでしょう。例では、「防災のトビシマ」を独自な情報群として説明しました。
この「企業サイトにおける4+1のメニュー分解」に課題サイトのメインメニューを当てはめたものが下記です。
他社サイトの把握と業界標準
業界ごとにWebサイトを見ていくと、その業界・業態によりデファクトスタンダードが存在していることに気づきます。例では建設業界 (清水建設・鹿島建設・大成建設・戸田建設) でしたが製薬業界や金融業界などやはり一定のメニューに集約されています。ここで取り上げた他社の企業サイトでも「会社情報系」と「商品・サービス系」とに分けてみると明確にその企業の意志が伝わってきます。
B2Bにける商品・サービス系には必ずと言っていいほど「事例」や「実績」が取り上げられます。例で取り上げた他社サイトも4サイトのうち2サイトが「実績」がメインメニューに含まれていました。
最適なメインメニューのまとめ
今回の課題では、以下の2点が考慮されていればメインメニューの最適化という課題に対しては妥当性のある回答と考えられます。
- 商品・サービス系として「ソリューション」をまとめること
- 「お問い合わせ」つまり「サポート情報」を加えること
いかがでしたでしょうか。スライドでは、以下の情報群でまとめました。
- 技術・ソリューション: 商品・サービス系 (※1) としてまとめる
- 施工実績: B2B特有の情報として※1から取り出す
- お客様サポート: 「お問い合わせ」を含む情報として加える
- 企業情報: 採用情報を含む会社情報系 (※2) の根幹
- 株主・投資家情報: 上場企業としての重要な情報配信を※2から取り出す
- ニュース: 広報としての情報配信として※2から取り出す
最適なメインメニューの最適化として、さいごにまとめたのが下記3点です。
- 情報の共通項を見つける: グルーピングから情報整理ははじまる
- 他社との共通項を見つける: 業界標準を意識する
- 重視する方向性を決める: 企業情報にはその企業の意図が含まれている
ということで、「最適なメインメニューを考えてみよう」だけで2エントリーになってしまったのですが、週1くらいで振り返っていこうと思います。
関連エントリー
最適なメインメニューを考えてみよう (CSS Nite LP7 Redux 01)
先週開催された「CSS Nite DISK, LP 7」のワークショップを解説含めて振り返りをしてみたいと思います。
撮影: 飯田昌之
当日のスライドはSlideshareにもアップしています。「IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)」もご覧ください。
事前課題
事前課題を出したのは、当日までに気分を盛り上げる作用もありますが、どちらかというと参加者が期待されている「IA」をワークを入れて全体像をつかむには1時間内ではどうしても時間が足りなかったせいです。
これまで参加したことのあるワークショップでは、前提となる参加者の状況や役割により意見が分かれて論点がブレてしまう傾向があると感じたため、状況を決めてしまうところから考え始めました。
- 自分は30代のWebディレクターである
- 勤務先の制作会社では、内部にデザイナーやコーダーがいる
- 来週顧客に説明に持っていく資料
- その資料は、要点が書かれていればよい
- 上司 (営業) もいっしょに同行する
この状況ですと、「サイトマップ」と言ったときに想像するものは詳細なサイトマップである必要はありませんし、デザイナーではないのでデザイン的に作り込む必要もありません。時間的にもそれほどあるわけではありませんので、時間をかけて課題に取り組む必要もないことになります。
対象サイトの選定
「飛島建設」さんのウェブサイトを対象にしたのは以下3つの理由です。
- 今どき珍しいレガシーなつくりだった
- ざっと見た程度でも改善点が見つけやすかった
- 建設業界という大きな業界のため類似サイトが多く見つけやすかった
最適なメインメニューを考えてみよう
あえて「メニュー」という言葉を使ったのは「ナビゲーション」という言葉の持つ意味と分けて考えたかったからで決して言葉の定義が揺らいでいるわけではありません。また、「7つのナビゲーション」を出したのは、前のセッションの振り返りの意味があります。
まず、サイト全体を把握することからはじめると思いますが、その際には――
- メインメニュー (ナビゲーション類) を見る
- サイトマップページを見る
- 一定時間いろいろ触ってみる
をしていくことになると思います。ヒューリスティック分析やユーザビリティ調査をしたことのある方にとってみれば、もう少し細かい作業をするかも知れませんが。もちろん個別の情報を得るにはアクセス分析ツールを見ることや、プリフェッチャソフトなどでファイルを取得して物理的な情報を見るというのもあります。
さて、その中でサイトマップページには2つの側面があります。
- そのサイトで扱う情報 (ページ) の大分類がわかる (反対に上位階層だけの場合がある)
- (実は) 提供側で見てほしい情報が隠されている場合がある (階層で割り切れない場合がある)
とくに2は経験がある方も多いと思います。
課題サイトでは、メインメニューで扱っている分類とサイトマップページで扱っている大分類とでやはり違いが見つけられます。これが2にあたる部分だと推測できるのですが、この段階でメインメニューの分類とサイトマップページの分類に違いがある点を見つけられればOKです。
実体をもたない情報分類
課題サイトのサイトマップページ左上には「トップページ〜」という3つの分類があります。これも前述の2にあたる部分ではありますが、どうしても画面要素で分類しがちな点は必ずつきまといます。これら3つの分類は、実体をもたない集合体でいわゆるショートカットリンク集にあたります。つまり、実体はほかの分類として分けられているのに、画面要素での分類でも見せたいという意図 (前述の2) が理由としては考えられます。
当日は3つとも対象外として説明しましたが、実は3つめの「トップページ下部メニュー」というのは無視してはいけません。「サイトの利用規約」や「プライバシーポリシー」はサイトに必要な情報群としてまとめるケースがあります (例: サイト情報)。当日は論点をメインメニューにしたかったのでここの説明は省きました。
共通項目をまとめてグルーピングしてみよう
「KJ法」や「カードソーティング」という言葉で聞くように、情報に分類にはいろいろな方法があります。課題サイトで扱うメインメニューを考える際に、そのサイトで扱う情報構造の最上位を自分の視点でグルーピングしてみるところから考えてみました。
当日も話しましたが、事前課題で取り組まれた参加者のほとんどが画面要素に分解して考えていたこと (つまりワイヤーフレームで考えていたこと) には驚きました。あえて「メニュー」と表現したの真意は、まずは情報の分類を純粋なリストで考えてみてほしかったからです。
課題サイトを改めて見た場合、ホームページと下位階層ページのナビゲーションが違っていることに気づきます。ここで、下位階層ページのナビゲーションを、ある視点で分類 (グルーピング) したものがホームページでのナビゲーションになると思ってしまうとNGです。
例として線を引いたものがありますが、さきほどのサイトマップページの分類とホームページのメニューとで突き合わせた場合に、結局まとめきれずに「防災のトビシマ」と「Bespokeサービスソリューション」が余ってしまうことになります。したがって、この2つをグルーピングしなければ、サイトの情報分類の最上位を整理できたことにはなません。例では「サービス・ソリューション」という分類を追加しています。
少し長くなってしまったので、ここでいったん区切ります。
関連エントリー
IAスペシャルでのワークショップ (CSS Nite LP, DISK 7)
CSS Nite LP, Disk 7「IAスペシャル」（2009年9月12日開催）
先日 (9/12) 行われた「CSS Nite LP, DISK 7」は、300人を越す参加者となり予想以上に大人数かつ大きな部屋に大きなスクリーンで、これまでにはないシチュエーションでした。
前半のセッションではどちらかというと参加者が聴く姿勢になるので、わたしのセッションではできるだけ手や頭を動かせるワークショップ形式にさせていただきました。300人強でワークショップ (?!) というのははじめてで大きなチャレンジでしたのではじめはどうなることかと思っていたのですが、みなさんの協力あってカタチにすることができました。
当初、もう少し参加者と近い距離を想定していたため、その場で課題に対する質疑応答なども考えていたのですが、想定以上に部屋が大きかったこともあり (参加者が多いということもあり) かなり小刻みにタンタンと進めるような格好になりました。
撮影: 飯田昌之
結果としては、事前課題に取り組めた方と取り組めなかった方とで大きく反応が分かれましたが、伝えたかったこと (感じてほしかったこと) は、十分に伝えることができたと思っています。
ワークについては、課題の出し方・取り組み方がうまく伝え切れずに消化不良にさせてしまった点がありました。ただ、このテーマを考える上で重要な点は伝え切れたと思います。あの場で理解できなくてもあとあと「こういうことを言わんとしていたのか」と思う場面が必ず出てくると思うので、そういった場面で活かせられれば幸いです。
別途、課題についてのエントリーも書こうと思います。
ちなみに今回「IAスペシャル」だったのですが、「IA」を専門職の領域だとかある意味遠くて現実的ではないと思われてしまうことを嫌って、このセッションでは「IA」という言葉を一回も使わずに進行してみました。また、テーマに「LPO」とあるのですが、こちらもあえて「LPO」「ランディング」という言葉はいっさい使わずに、考え方や手を動かすことで中身を伝えるようにしました。
というのも、参加者が自分たちの関わっている業務に直接関係している範囲で考えてほしかったのと専門用語を使うことで「知っている」というふうに安直にとらえてほしくなかったことが理由です。手を動かすことで「知っている」のではなく「理解できている」ということを自身で感じてほしかったことが一番の理由です。
撮影: 飯田昌之
懇親会の場で安藤さんと建設業界におけるウェブでのソリューション訴求は実際にはあまり意味がないので、現実味が薄かったとご指摘もいただきました。建設会社さんを題材にした理由は、たまたま見つけたレガシーなつくりだったことと間違い探しをしていく上で説明がしやすかったのが理由で、それ以外にはありません。
反省点
アンケートのほうで皆さんからご指摘いただけことも、自戒を込めて今後の活動に活していくようしたいと思います。
- 事前課題を取り組んでもらうような促し方ができなかった。
- 課題の取り組み方とアウトプットイメージを伝えきれなかった。
- 所々早口になってしまった。
- スライドの文字が小さい部分があり遠くの方から見えにくかった。
- グループディスカッションに時間をあまり割けられなかった。
- 時間を延長してしまった。
今後の取り組み
最後にご紹介したデジタルスケープのワークショップは、下記からご覧いただけます。
今回の反省点を活かして、さらにパワーアップしてお届けしていきます。
関連エントリー
IA Cocktail Hour Tokyo (UX Insenticve参加報告) のお知らせ
IAAJでも公開しましたが、来る9月4日 (金) に、IAカクテルアワーを行いたいと思います。前回からかなり時間が空いてしまいました。前回までの活動風景は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
以上、よろしくお願いします。
フッターサイトマップのデザイン
に「Key Footer Information」として、フッターの情報として重要な6つを取り上げています。もうどのウェブサイトを見てもこれらの情報は掲載されていると思いますし、ある意味デフォルト (標準値) であるとも言えます。
フッターに置く重要な要素
- About Us Link/リンク (について)
- Contact Us Link/お問い合わせ (連絡先)
- Terms of Service/サイトの利用方法 (利用規約)
- Privacy Policy/プライバシーポリシー (個人情報の取り扱い)
- Site Map/サイトマップ
- Address and Phone Number/住所や電話番号
ただし、このうち「サイトマップ」については、単にサイトマップページへのリンクを置くこともそうですが、最近のウェブサイトでよくみかけるフッターにサイトマップそのものを掲載してしまうケースをよく見かけます。この「フッターサイトマップ (仮称)」について参考になるエントリーがあったので合わせてご紹介します。
「Benefits of Placing a Sitemap in the Footer」として、フッターにサイトマップを置くことでの価値を6つあげています。
フッターにサイトマップを置く6つの価値
- ユーザーの興味や関心を引くため (クリックや滞在時間を持続させるため)
- ユーザーが情報を見逃さないようにするため
- リンクを促進するため (重要な情報に誘導するため)
- ユーザー (読者) がすぐ次に進めるよう時間の節約になるため
- ユーザーのクリック (数?) の節約になるため
- 機能的なレイアウトデザインのため (サイトを大きく見せるため)
これと、あとはやはりSEOになるでしょうか。ひょっとしたらスパム扱いになりそうな気がしなくもないですが、全ページのフッターにサイトマップを掲載して被リンクを多く持つことはSEOとしては有効だと言われます。
ということで、いくつかの事例を取り上げた上で、Tipsとして下記図にまとめられています。
フッターサイトマップのデザインにおける3つのTips
- サイト構造に合わせて分類する
- タイトルおよびヘッドラインを使用する
- 一貫したルールでコンテンツ (リンク) を並べる
これとぜひ取り入れておきたいのが、下記でしょうか。
- パン屑リスト (経路と現在位置)
- 履歴 (最終訪問ページやそのカテゴリー)
- 目的別リンク (ファセット分類)
そのほか、たくさんの事例 (下記にリスト) と合わせて紹介されているので、参考にしてみてはどうでしょうか。
効果的なプロトタイピングとデザインプロセス
「ワイヤーフレーム」「プロトタイピング」という言葉は仕事がら慣れ親しんだものではあるのですが、意外と突き詰めて考えると奥が深いことに驚きます。
先日参加してきた「IA Summit 2009」のワークショップセッション「Integrating Effective Prototyping into Your Design Process」でFred Beecher氏が「プロトタイプは2枚以上あって相互に行き来が可能なもの」と話されていました。たしかに「ワイヤーフレーム」と言うと1枚絵のようなものを想像する人も中にはいるかも知れません。
ワイヤーフレームを絵としてとらえるのか試作品としてとらえるのかで解釈の違いが発生します。これもずっとある課題ではあるのですが、Fred Beecher氏のセッションでは「Visual (絵)」と「Functional (機能)」の2軸で整理してありましたので参考に取り上げてみます。
図内の略称は、H: High/L: Low/F: Functional/F: Fidelityです。
左下の「LVF/LFF」が一番抽象度が高くて、右上の「HVF/HFF」が最終形に近いという感じでしょうか。ほとんどのワイヤーフレームは、実はこの左下にある「LVF/LFF」のような気がします (つまりWireframe Sketches)。ただ求められるのは右上の「HVF/HFF」だったりすることもあると思います。ここの認識が関係者により違っていたらマズイので、はじめから認識の擦り合わせのために成果物サンプルは用意しておくほうがいいでしょうな。
右上: HVF/HFF (High VIsual Fidelity/Low Functional Fidelity)
・既存システムに新機能を盛り込む際のユーザーテストに使える
・一般的なユーザーとのテストに使える
・離れた開発チームとのドキュメント共有に使える
左上: HVF/LFF (High VIsual Fidelity/Low Functional Fidelity)
・ビジュアルデザイン上のユーザビリティの課題の発見に使える
・一般的なユーザーとのテストに使える
右上: LVF/HFF (High VIsual Fidelity/Low Functional Fidelity)
・遠隔によるテストに使える
・ステークホルダーとの間でUXデザインやUX開発要件 (方向性) の確認に使える
・離れた開発チームとドキュメントの共有に使える
左下: LVF/LFF (High VIsual Fidelity/Low Functional Fidelity)
・足りない機能の発見に使える
・ワークフローの問題の発見に使える
・いいUXコンセプトと、そうではないUXコンセプトの切り分けに使える
もちろん案件や提出/支給相手にもよるのでしょうけど、ボクのまわりではそれほど見た目としても機能としても求めていないような気がします。その理由は、 その後の工程で結局のところ補完 (というかカバー) していることが言えます。WF単体のクオリティ (?) が高くてもその後の工程でそれをうまく (効率よく) 受け取れないと、プロジェクト全体のクオリティは下がります。
例えば、ワイヤーフレームやプロトタイピングの専用ツールでWebデ ザイナーがクリッカブル情報をせっせとすべて埋め込んだとしても、その後のHTMLコーディングで効率よくそれが拾いだせなければ、とどのつまり二度手間 になります。二度手間である以上に、Webデザイナーが埋め込んでいる工数はかなり無駄になってしまうとも言えます。
そう考えると、そのあたりの折り合いを全体としてどうつけていくのかがポイントになります。
このセッションのスライドがすでにSlideshareにあがっていましたので詳細は下記をご覧ください。
Get Wireframing and Prototyping
Fred Beecher氏は「Axure」についてもワークショップを開いていたりするようですが、これに関係して「ワイヤーフレーム」や「プロトタイピング」に関するエントリーがあったのでご紹介します。
まず「Get Wireframing」という下記エントリーですが、すごいですね。よくまとめたなと感心してしまいます。
内容は下記のアウトラインになっているので、すべてがいいリファレンスになりますな。
「Article」などは個別に集めてたまに読む程度だったのですが、まとまっているのでいつでも参照できます。
- Techniques
- Tools
- Wireframe Examples
- Wireframing Articles of Interest
- Paper Prototyping
- Useful Wireframing Resources
- Kick Ass Books
次に「16 Design Tools for Prototyping and Wireframing」ですが、これはツールを16個あげてそれぞれをレビューしています。
と、この2つのエントリーだけでもリストアップしてみると24ものツールがあることになります。
もちろん「multifunctional applications (多機能なツール)」としてしまえば、世の中のほとんどのツールが含まれてしまうかも知れませんが。
これからツールを検討しようとしていた場合、このリストアップは参考になるのではないでしょうか。ボク自身触ったことがあるのはごくごく一部のような気がしますので時間のあるときにでも試してみたいと思います。
- Visio – Visualize, explore, and communicate complex information.
- OmniGraffle Pro – Create diagrams, process charts, quick page layouts and website mockups
- Axure RP Pro – Rapidly create wireframes, prototypes and specifications for applications and web sites.
- iRise Pro
- Pencil – Free sketching & GUI prototyping tool, can be installed as a Firefox add-on or as a standalone application.
- SmartDraw
- MockupScreens – For the Non-Designers, allows you to sketch and organise screen mockups.
- Balsamiq Mockups – Easily and quickly created rough mockups with predefined elements
- Lucid Spec
- ConceptDraw Pro
- iPlotz – Quickly sketch wireframes of Web sites and demonstrate navigation between pages
- Go Analogue
- PowerPoint or Keynote
- Adobe Fireworks
- HTML
- Adobe Flash
- Fluid IA – Agile UI Prototyping
- OverSite – Provides a menu of widgets to create wireframes, or mockups with drag and drop features.
- Justinmind – Design a wireframe and test their web usability
- EasyPrototype – Works with your existing techniques such as paper sketches, Photoshop mockups etc.
- Gliffy – Create website wireframes and share web mockups with anyone.
- Jumpchart – Online collaborative wireframe
- Lovely Charts – Diagraming app that allows you to create site maps, flowcharts, wireframes and more
- Protoshare – Collaborate online wireframe tool with real time communication and clickable wireframes.
loftwork college: プロジェクトデザインから見るIA
少し前 (2/24) になりますが、ロフトワークの「loftwork college」でWebディレクションをされている方対象に、IAについてお話をさせていただきました。場所は「loftwork Ground」というスペースでした。
ロフトワークといえば、PMBOKをベースにした「Webプロジェクトマネジメント標準」の著書である林さんが社長をつとめている会社ですが、その林さんとその友人である浅野さんから今回の話をいただきました。話の内容は、それより前にSINAPさんでお話させていただいた、いわゆるWeb構築時におけるIA的視点のお話をしました。
いつも話のはじめに出すのは「The Elements of User Experience」と「The Nine Pollars」です。そして成果物の話に進める上で「IA One Sheetes」を引き合いに出します。
成果物については、主に下記3つを取り上げて、その作成における注意点や心得のようなものをお話ししました。
- ワイヤーフレーム (レイアウトとパターン)
- サイトストラクチャ (情報構造とフローの違い)
- ユーザーエクスペリエンスフロー (メンタルモデルからサイト要件)
最後に、IAの定義とスキルについて参考文献を用いてお話ししました。
インフォメーションアーキテクトの定義としては、リチャード・ワーマン氏が1996年ごろにまとめた下記があります。
インフォメーションアーキテクツの定義
- 複雑なデータの固有のパターンをまとめ、内容を明確にする人
- 第三者が情報を得るための道筋を自分で見つけられるように、情報の構造を示す地図を作成する人
- 誰でも理解しやすように情報を提供し、それらをまとめる人
また、コアスキルとしては、「Web検定本 デザイン編 (ワークスコーポレーション)」 にある下記を引用しました。
IAのコアスキル
- デザイン実行力とデザインマネージメント力
- リーダーシップとプロジェクトマネジメント力
- ユーザー調査と分析力
- 顧客とのコミュニケーション能力と調整力
参加者の多くはWebディレクションをされている方でした。とくに、自分でもワイヤーフレームを作成するといった設計パートを担当している方やビジュアルデザイン業務は外部のパートナーに指示するという役割をする方が多かったようです。
ベテラン層と若手が入り交じった参加者でしたので、どこまで期待に応えられたかはわかりませんが、その後の懇親会では、実際の業務を踏まえての具体的な勉強会や成果物を集めてディスカッションができれば、さらにIA的視点や論理的思考が身につく機会が得られるのではないかと、非常に前向きは意見をいただくことができました。
いわゆるWeb制作会社さんにおける勉強会のニーズまたはワークショップなどは今後も積極的に取り組んでいければと思います。