その初期サイト設計は尖っているか！フルボッコ分析のススメ

「ワイヤーフレームを作る」と一言でまとめている作業、ただなんとなくやっていませんか？「ファーストビューが～」「Fの法則が～」そんな小手先のテクニックどうでもいいんですよ。それは手段であって目的ではありません。目的はあくまで誰に対して何を伝えるかであり、その目的の為にあらゆる手段を用いて情報を最適化する（ファインダビリティを向上させる）のが、情報設計者（インフォメーションアーキテクト）の仕事なのだと思っています。つまり、「誰に」や「何を」をという目的をすっ飛ばして「どうやって」という手段を軸にワイヤーフレーム作成に着手するのは全くナンセンスなのです。それではワイヤーフレームごっこであり、本当の意味でのサイト設計には成り得ません。

当ブログを始めた時に「実案件で活かせるIAテクニック」をうたっておいて少々概念的な話が多めになってしまったので、ここらで実際に私がサイト設計をする時に課題点調査からワイヤーフレームを起こすまでにやっている初期設計フローをざっくり書き連ねて見たいと思います。あくまで私がやっている事なので、世の中のインフォメーションアーキテクト達が一般的にやっている事かどうかは分からないという旨を予めおことわりしておきます。

目次

• あなたはWEBのプロフェッショナルです
• 「自分言葉」でフルボッコにしろ
• パワポなんか後でいい。軸が決まればスピード命

あなたはWEBのプロフェッショナルです

私達WEBデザイナーやWEBディレクターがサイト設計をするのはどんな時でしょう。自社コンテンツの設計でも無い限り、基本的にはクライアントからの要望書ないし指示書ありきで事を進めるのが一般的ではないでしょうか。

ここで頻繁に見かけるのは、こんな状況です。

• デザイナー「何この指示書、めちゃくちゃじゃねーか。」
• ディレクター「でもお客様がこうしてと言っているんだから（納期もあるし）、仕方ないよ。言われた通り作って。」

受注仕事をしている限り、お客様が丹精込めて作って下さった指示書ないしワイヤーフレームをないがしろにする事は出来ないというのが今のWEB業界の悪しき慣例です。本当はおかしいと思っていてもそれは相手に届かず、相手の心象も考えて、下手に口出しをするよりも良好な関係性を維持する事に全力が注がれます。結果として、お客様はあなたの事を舐めますし、あなたもお客様の言いなりという身分から脱出できなくなります。

声を大にして言いたいです。なーにが「仕方ない」だアホかと。

確かに、要望そのものはクライアント側の経営判断に基づいて作られている為、我々が口出しを出来る範疇ではありません。しかし、その表現方法であるサイト設計についてはどうでしょう。クライアントの担当者に果たしてサイト設計の能力があるでしょうか？よほど勉強熱心な担当者でも無い限り、どう足掻いても毎日毎日終電までWEB制作をしているような人間に敵うわけが無いと思いませんか？

指示書を作っている担当者はあなたよりもWEB知識やサイト設計スキルの劣る素人です。そう胸を張って言えないようであれば、WEB業界なんかで働くのは諦めた方が良いのではないでしょうか？「仕方ない」という言葉に甘えて腑抜けないでください。

「自分言葉」でフルボッコにしろ

では、私がそういう素人考えの指示書や要望書が来た時に何をやっているかというと、まず自分の視点で現状のサイト設計の問題点をボッコボコにします。

最初からワイヤーフレームを引く人も居ますが、私はまずWordやメモ帳などで現状サイトやコンテンツの問題点を箇条書きにしてフルボッコにします。褒め言葉は要りません。全身全霊を込めてフルボッコにして差し上げます。私はこれをフルボッコ分析と呼んでいます。ここで自分の視点とか言ってると「客観視点で見ないのか！」とかお説教を受けそうですが、主観/客観はコンテンツを提供する/されるの関係性であるため、受託仕事である限り普通に内容を見たり、普通にサービスを利用してみれば、普通に客観視点を得られます。何も特別なスキルは要らないのです。

これをやる事で、まず自分の中での案件に対しての軸が固まります。軸が固まれば、解決策も次々に浮かんできます。あとはそれを鮮度が落ちないうちに吐きだして、キレイにパワポなどで清書してからお客様にお送りすれば、ほら立派なサイト設計改善提案書の完成です。

フルボッコ分析で最も大切なのは、相手に見せる為の資料ではないので徹底的に自分言葉で書き殴る事です。本当はもっとズバズバ言ってやりたいのに、大切なお客様だから遠慮してしまって表現を丸めた結果生ぬるい提案書になってしまった・・・。そんな経験、ありませんか？

以前の記事でも持論を述べましたが、お客様が外部の人間に求めるのは同調やお世辞などではなく、鋭く的確な指摘なのだと思います。自分の想いを最も効率よくアウトプット出来るのは、美しい敬語などでは絶対にありません。だからこそ、自分の中で情報を整理する段階では自分言葉で書くという事がとても重要なのだと考えて、サイト設計前には必ずこのフローを行うようにしています。

パワポなんか後でいい。軸が決まればスピード命

サイト設計に必要な問題点・課題点の洗い出しが終ったら、あとはそれを形にするだけです。(案件規模によっては更に詳細なマーケティングや分析フローが入りますが、それはまた別の機会に。)ここからは自分の中に固まった軸を、なるべく鮮度が落ちないうちにアウトプットする事に全力を費やします。提案の軸が固まったから続きは明日でいいやーとか抜かすディレクターが居たら頭ひっぱたいてやってください。鉄は熱いうちに打つもんです。考えるだけで形に出来ないようでは、二流三流なのです。

スピード感のあるアウトプット手段として、私はいつも「メモ帳」を使っています。どうせあとでパワポでまとめるんだから、最初からパワポで作れば良いじゃないかと思いますか？あなたはメモ帳を舐めています。

メモ帳の良さは、その“不自由さ”にあります。windows標準のメモ帳は、なんとCtrl+Zの戻る機能で一段階しか戻れません。これにより、意識せずとも手戻りが少なくなり、どんどん書き進めるという動きが自然と身体に染み付きます。さらに、資料としてのレイアウトや体裁を全く気にしなくて良いので、純粋に頭の中身を言葉として起こすことが出来るようになります。パワポで綺麗にまとめるのなんか最後でいいのです。初期サイト設計段階では、まずメモ帳を使いましょう！

サイト設計の初期段階はスピードが命。でないと、どんどん軸がブレてきて何がしたかったのか分からなくなってきます。可能な限り、頭に浮かんだ情報はその場でアウトプットする事が大切です。ここでさらに私がオススメするのは一人で考えない事。あなたがフリーランスでも無い限り、同じ部署内に優秀な人材がゴロゴロ居るでしょう？その人達を引っ捕まえてきてさっき殴り書いたフルボッコ分析資料と今書いたラフサイト設計案を叩き台（議論の元となるプロトタイプ）にして会話をして下さい。「あーじゃないか？いやこーかもしれない・・・」なんて一人でやっていたのが馬鹿らしく思える程すぐに話がまとまる事をお約束いたします。

まとめ

• 客はあなたに指摘されたがっている
• フルボッコにする事で問題解決の「軸」が見えてくる
• 最速でアウトプットする。オススメは「メモ帳」

情報アーキテクチャは、誰に・何を・どう伝えるかを設計する一連のプロセスです。今回ご紹介したフローは、「誰に・何を」を一気に決めてしまおうという少々乱暴なやり方ではありますが、これがスっと出てくるとその後の「どうやって」を考える大事な部分が格段にスムーズに進みます。自分言葉で課題点を洗い出し、軸がブレないうちに一気にプロトタイプを作る。フルボッコ分析なんてふざけた名前を付けましたが、イケてないと感じるサイトが「何故、ダメなのか。」を一つ一つしっかり紐解いていくのは情報設計（サイト設計）のとても良いトレーニングになります。自分言葉での分析は早くて純度が高い分、視点が俯瞰的ではなくなってしまうというリスクがありますが、そこは一人で考えない事で補いましょう。

IAはソロプレイヤーではありません。情報アーキテクチャはWEB制作において最上流工程に位置するため、周りを巻き込んで社内外問わずプロジェクト全体の意識を統一する重要な仕事だと思っています。だって、各々が想定しているターゲットがふわっとしていたら、コンテンツもふわっとするじゃないですか？そんなふわふわしたモノは作りたくないですよね。だったら井戸端会議でいいので、意見をぶつけあってすり合わせた方が早いし確実。フルボッコ分析からの井戸端会議、是非一度やってみてください！意外とエキサイティングでスッキリしますよ。

ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは

目次

• ただ使いやすいだけのUIは要らない
• ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは
• 本当の意味でのユーザビリティとは

ただ使いやすいだけのUIは要らない

UI（ユーザーインターフェース）の設計をしていると、よくよくユーザビリティという言葉を耳にします。
UIやUXについて真剣に考えているあなたならご存知でしょうヤコブ・ニールセン博士によると、ユーザビリティとは

1. 学習しやすさ: システムは、ユーザがそれを使ってすぐ作業を始められるよう、簡単に学習できるようにしなければならない。
2. 効率性: システムは、一度ユーザがそれについて学習すれば、後は高い生産性を上げられるよう、効率的な使用を可能にすべきである。
3. 記憶しやすさ: システムは、不定期利用のユーザがしばらく使わなくても、再び使うときに覚え直さないで使えるよう、覚えやすくしなければならない。
4. エラー: システムはエラー発生率を低くし、ユーザがシステム使用中にエラーを起こしにくく、もしエラーが発生しても簡単に回復できるようにしなければならない。また、致命的なエラーが起こってはいけない
5. 主観的満足度: システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用できるようにしなければならない。

(出典：wikipedia)

といったような定義がされています。この中で特に学習しやすさと記憶しやすさに関連する用語としてアフォーダンスという言葉があります。

これは認知心理学に関係する言葉で、「モノの形や色自体が自らの操作方法を人間に伝えている」という考え方の事です。これをUI設計に応用する事でなんか凄く良いものが出来る気がしませんか？

実際、UIデザインの中ではこういった考え方がとても大事なのは事実ですし、UIデザインの本などを読むとそれっぽい説明文がズラズラ書いてあります。

ただ、ちょっと待ってください。アフォーダンスを軸に据えればユーザビリティが向上すると考えてUIを設計してしまうのは危険です。下の図は、J.J.ギャレット氏によるUXデザインの5階層図です。下が基礎部分で上に行くに従って下流工程という事になりますが、アフォーダンスはこのプロセスにおいてインターフェースデザインとビジュアルデザインの中間部分に位置し、最後の仕上げに意識するスパイス的な要素である為です。アフォーダンスの考え方を設計の土台に据えるのは間違っているのです。

ニールセン博士が提唱したユーザビリティでは、使いやすさの定義は「学習」から始まっています。つまり究極に使いやすいUIとは、操作方法を学習する必要のないUIであると言えます。そして、これを実現する為には、アフォーダンスの考え方が必要不可欠です。

しかし、使いやすさを極めていった結果、ユーザーから不評が相次ぐという不思議なケースをご存知でしょうか。

それは、『ニコニコ動画』の動画プレーヤー「ニコニコプレーヤー」の例です。

ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは

予め断っておくと、この場でニコニコ動画のサービスや設計思想の善し悪しについて議論するつもりはありません。UIとUXの相関性を考察するのに非常に適しているユーザーの反応事例があったので、例として挙げただけです。

ニコニコプレーヤーの変遷について詳しく知らない方の為にざっくりと説明すると、YoutubeのHTML5化などの時代の流れに影響を受けたニコニコ動画が、これまでサービス開始から（見た目やシステム上）大きな変更を加えていなかった動画プレーヤーをごっそり一新。しかし一般家庭の環境では全く使い物にならないレベルの重さと慣れない操作感でユーザーの不満が大爆発。「旧バージョンに一時的に戻す」という段階移行の為の機能にユーザーが殺到するという事態になってしまった。というものなのですが、さらに興味がある人はこのあたりから当時のユーザー反応がどういったものだったか感じ取ってみてください。

なぜニコニコプレーヤーのリニューアルは失敗してしまったのか。先程のニールセン博士のユーザビリティ定義を思い出してみましょう。「学習しやすさ」「記憶しやすさ」は申し分ありません。現代風のシンプルなデザイン、一目で操作方法をアフォーダンスするボタンの数々、おまけにマウスカーソルに合わせて情報が出たり隠れたりするインタラクティブデザイン性まであるのですから、UIの設計としては申し分無いように見えます。

では、その他の項目に着目してみるとどうでしょう。「効率性」については、サービス開始以来初めてとなる大幅なUIデザインの改修なので反発が予想されますが、時間経過と共に解決する問題なのでそこまで大きな問題の要因とはなりません。ニコニコプレーヤーリニューアル失敗の重大な問題点は「エラー」と「主観的満足度」にあります。

あるユーザーの言葉で、この問題の核心を的確に捉えた一言があります。

「私たちはニコニコ動画で動画を観たいんです 動画プレイヤーを見たいんじゃない」

先述のとおりユーザーの不満が最も大きく募ったのはその「重さ」です。システム的には正常に動画が視聴出来るのだとしても、それが利用に耐えない程の精神的苦痛を伴うようなものであれば、動いていたとしても「エラー」とするのが妥当でしょう。しかもそれが今まで出来ていた物が改修によって出来なくなったのですから、「主観的満足度」は当然のようにガタ落ちします。

私はこの問題について、最近UIとセットで語られる事の多いUX（ユーザー体験）について、プレーヤー開発者側が間違った解釈をしてしまったが為に起こってしまったのだと考えています。

まずUIとUXについてですが、語感が似ているというだけで本来セットで語るものではありません。UI（ユーザーインターフェース）とは、純粋に操作機能を司る部分の事を指し、UX（ユーザー体験）とは、過去・現在・未来を含めた体験全体の事を指します。

よく混同されがちな誤った認識の例として、UXはUIの結果として存在するというものがあります。「ユーザビリティを向上する為には、UIを操作して得られるUX（ユーザー体験）を向上すれば良い」といったように、ユーザーの操作によって生じるUXにフォーカスをしていった結果、使いやすいUIが出来上がるというような機能的合理性の考え方です。

この考え方ではUIの利用中という「現在」にしかフォーカス出来ず、それまでのUIにユーザーが慣れ親しんだ「過去」と、これからずっとこれを使い続けなければならなくなるという「未来」が無視され、欠落してしまうのです。「UXの為のUI」という考え方には、そういった問題点があるのです。

私はニコニコプレーヤーリニューアル時のUI開発者のコメントを聞きましたが、機能的合理性の追求によるユーザビリティ向上を語っており、まさにこの「UXはUIの結果として存在する」解釈によって作られたものなのだという事を確信しました。

「動画を見たい」というシンプルなユーザーの欲求を理解せずに、客観的に見て合理的な形へと変えてしまう。こういった開発者側が考えている「ユーザビリティ」と、ユーザー側が考えている「ユーザビリティ」に乖離が起こってしまった事が、ニコニコプレーヤーリニューアル失敗の最大の要因なのではないでしょうか。

本当の意味でのユーザビリティとは

「UXの為のUI」の様な機能的合理性の考え方では、過去と未来が無視されてしまってユーザビリティの中の「主観的満足度」が低下するという事を書きましたが、これは行動経済学の分野ではプロスペクト理論というもので証明されています。

プロスペクト理論とは、人間の損得に対する感じ方は参照点の在処によって異なる（の他にも色々あるのですが小難しくなるのでここでは割愛します…）という理論で、特に得の部分より損の部分を過大に捉えてしまうという特性を備えています。ニコニコプレーヤーの例で言うと、それまでのUIで「出来ていた」というのがユーザーの参照点。ユーザーは「あれに比べて今回はどうだったか」という視点でUIに対する判断を下すので、前出来ていたスムーズな動画視聴が出来なくなったという「損」に対して非常に大きなストレスを感じてしまい、結果として酷評に至ったという現象が起こったのです。

もし、あのUIが出来たばかりの新サービスの動画プレーヤーの設計であれば、恐らくあそこまで極端な批判は起こらなかったのではないかと思います。重すぎて動かなかったのは論外ですが、基本的な設計理念としては非常に優れた発想によって作り込まれたUIであったと言えます。

ただ、既存ユーザーにとっては操作性に優れているかという事よりも、前のものより使いやすいかどうかという方が重要であるという心理的な要因を無視してしまった事だけが問題でした。本当の意味でのユーザビリティとは、ニールセン博士が提唱した最後の項目「システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用できるようにしなければならない。」ここに尽きるのでは無いでしょうか。これが満たせていないのであれば、他の全ての項目が満点であっても、ユーザーにとっては「使いにくい」ものと判断されてしまうのだと思います。

まとめ

• アフォーダンスは設計の基礎ではなく、仕上げのスパイス
• UXは「点」ではなく、過去や未来を含めた「線」で満足させなくてはならない
• ユーザーは得よりも損を大きく捉える

今回は情報アーキテクチャから少し離れて、UIとUXに行動経済学の観点を混ぜてケーススタディーをしてみました。情報アーキテクチャも誰にとって使いやすくまとめるかが大事という事を以前の記事で書きましたが、UIの設計においてはその観点が更に重要になってきます。逆にUIの設計がしっかり出来るWEBクリエイターであれば、情報アーキテクチャの考え方は特別意識せずとも出来ているのだと思っています。とはいえ、情報アーキテクチャはUI設計の上流工程な訳ですから、ここをスキップしてWEBサイト・サービスの設計は成し得ません。可能であれば実案件で生のユーザーや生のビジネスニーズを感じた上でスキルを磨いていくのがベストなのだと思いますが、なかなかそういう案件は転がってないですよね・・・。転がってこないかな（ﾁﾗｯ

ナウいIAになりたいWEBクリエイターに捧ぐ、情報設計入門

知識は使う為にある

もしあなたが現役バリバリのWEB制作に関わるディレクターやデザイナーなら、情報アーキテクチャ（IA）で扱う事柄は当然の事と感じるかもしれません。
しかし、情報アーキテクチャで検索すると概念的な部分や理論的な部分にフォーカスした記事は多くヒットしますが、実践的なノウハウを扱うものがとても少ないように感じます。

もちろん概念や理論を学ぶ事も大切ですが、そんなものは使わなければただの雑学知識です。私はそれを実案件にどう活かしていくかまで踏み込んで考える事が一番大切だと思っています。
その道しるべ兼覚え書きとして、これからIAスキルを磨いていこうというWEBクリエイターの皆様と共有したいと思い立ってブログを立ち上げてみました。

今更そんな思考プロセス学ぶまでもないよと思ってるあなたも、まあちょっと暇つぶし程度に見てってくださいよ。

そういえば、情報アーキテクチャという言葉が無かった時代は、これらのフローは何と呼ばれていたのでしょう？
正直、言葉を知らなくても無意識的にやってた事ですし、私自身も意識して「あぁ、これが情報アーキテクチャか。」と思い始めたのは実は今年に入ってからだったりします。

目次

• 散らかったデスクトップをどうやって片付けますか？
• クライアントの出す要望書を鵜呑みにしてはいけない
• ヒューリスティック分析のススメ

散らかったデスクトップをどうやって片付けますか？

デスクトップ（PCを立ち上げた最初の画面）、ちゃんと片付いてますか？
インストールしたソフトのショートカットやダウンロードしたファイルが散らばってませんか？
別に散らかってるならIA失格だ帰れとは言いませんが、IAは情報を整理するプロな訳ですからこれは是非整理整頓したいですよね。

では、あなたは画面に散らばったアイコンをフォルダにまとめる時、どんな基準で分類（カテゴリ化）しますか？

• 用途別にまとめる
• 拡張子別にまとめる
• 提供元の人や場所別でまとめる
• 受け取り日付別でまとめる
• とりあえず全部1つのフォルダに放り込んでスッキリ

 ざっくり見積もるとこれくらいでしょうか。（多分もうちょっとあります。）
余談ですが、インストールしたときにデスクトップにショートカットを作る機能、そろそろ滅びませんかね・・・。

さて、同じバラバラの情報でもこれだけのパターンで分類できる事になったわけですが、何故分類の仕方に差が生まれるのでしょう？
用途別でまとめた人は、「何度も繰り返して使う事が多そうなので、使いたい！となった時にすぐ見つかるように」こうやって分類したのではないでしょうか。

提供元の人や場所別でまとめた人は、「案件ベースで物事を進めるにあたって、他の案件と混ざって見つけにくくならないように」提供元で分類したのではないでしょうか。

これら無意識的に行っている「見つかりやすくなるようにする」思考プロセスが、情報アーキテクチャの基本です。カッコよく横文字を使うと「ファインダビリティ」と言います。

分類が複数パターン出てくるのは「次にその情報にアクセスする時の自分」のイメージが異なる事によって差が生じるからです。
作業開始前の自分、作業中の自分、同じ自分なはずですが、その時のニーズによって最適な情報のまとめ方は違います。

実際の仕事でよくあるケースを例に挙げると
「新規顧客獲得に向けて導線の設計を見直したいと考えている。お問い合わせフォームからのお問い合わせをゴールと設定してコンバージョン率を上げる為の提案を下さい。」
などでしょうか。

ここでダメなディレクターは「承知しました。では、お問い合わせフォームへの導線を強化するようにナビゲーションやメニューを再設計しましょう。」などと提案するんでしょう。そしてデザイナーには「フォームへの導線ボタンを目立たせて。」くらいに噛み砕かれた情報が伝えられます。
リニューアルが失敗に終わりそうなのは何となく分かりますよね。

クライアントの出す要望書を鵜呑みにしてはいけない

先程のケースでは、その情報にアクセスする時のニーズによって最適な情報のまとめ方は違うという事を見落としています。新規顧客はお問い合わせをする為にサイトにアクセスしてきた訳ではありません。自分の利益になりそうな情報があるかどうか探しに来ているのです。
先ほどのケースでIA（情報設計者）が真っ先に行うべき事は、クライアントが「新規顧客」と呼んでいる層が、どんな情報を求めているのかを調査・分析する事です。その土台が無ければ導線の設計なんて出来るはずがないのです。

IA（情報設計者）は、情報を求めて来た人に対していち早く求める情報を提示できるように画面設計をしなければなりません。
客の出す要望書は、そういった所謂ユーザー視点が欠落した状態で求める結果だけが記されている事が殆どです。（ビジネスニーズに偏っている状態。）これを鵜呑みにしてそのまま作ってしまってはクリエイターの名折れです。

これは持論ですが、客は外部制作会社に対しては同調よりも異論・反論を求めていると思っています。だって、ハイしか言わない相手と話したってつまらないじゃないですか？そんなものにお金は支払わないと思うんですよね。イエスマンは内部に居ればいいのです。外部に求めるのは、客観的なユーザー視点なのだと思います。

ヒューリスティック分析のススメ

先程クライアントが「新規顧客」と呼んでいる層について調査・分析する。と書きましたが、そんなのマーケターじゃないんだから本分じゃないよ！と思っていませんか。
そんなことありません。むしろ明確にターゲットをイメージ出来ない状態ではディレクションもデザインも出来ませんので、我々のようなクリエイターこそ調査・分析をすべきなのです。

あなたはヒューリスティック分析というのをやった事がありますか？
WEBサイトなどの分析方法の一つですが、やり方は単純明快。共通の項目を設けて、その道の専門家が経験則に従って評価するだけです。

競合他社と比較をする際にもよく使われたりしますが、その道の専門家でも無ければ経験則と呼べるほどのベテランでもないと自覚している皆さんは、自発的にやった事が無いのではないでしょうか。

結論から述べます。ヒューリスティック分析を是非やってみてください。経験則だとか専門家だとか関係ないです。私はWEB業界に入って半年くらいの時にやりました。

ヒューリスティック分析をオススメするポイントは3つです。

• ユーザー視点とビジネス視点両方から一つのサイトを評価する事が出来る
• やった数だけ情報設計の経験値が溜まる
• 客観的な評価を下す事でクライアントが喜ぶ

何度も書きますが、クライアントの要望はビジネスニーズに偏っています。そして、それを客観視してユーザーニーズを探し出せるのは外部の人間しか居ません。
行動経済学でよく出てくる「バイアス(心理的な偏り)」という単語があります。人間の行動はどうやっても思い込みや事前知識などで偏りが生じるというものですが、クライアントが出してくる要望は専門知識が邪魔をしていて、まさにこのバイアスの塊であることがほとんどです。

我々はWEBクリエイターであり、その専門分野がクライアントと被る事はまず無いと思います。つまり、クライアント側にとっては自分たちの専門的な視点からの提案は初めから期待していないのです。
であれば、クライアントが要望書を出すという行為はこう捉えるのが妥当ではないでしょうか。

「価値を提供する側として捉えている問題と目指す成果はこうです。では価値を得る側の目線でこの目標に到達するためにはどうなっていて欲しいですか？」

平たく言うとビジネスニーズは提供した。ユーザーニーズを補強して提案してくれ。といったところでしょうか。
私の経験上、極端に的外れでない限りこういった分析資料を渡したクライアントには例外なく喜んで頂けてます。

まとめ

• 見つけやすさ（ファインダビリティ）の向上がIAに与えられた任務
• 情報アーキテクチャのキモは誰にとって使いやすくまとめるか
• 経験は関係ない。どんどん首を突っ込もう

表題に「ナウい」と付けたのには訳があります。なぜならば、本来の情報アーキテクチャとは、情報の組織化と構造化までが担当分野なので、「誰に対して」というのは既に与えられている、もしくはあまり深く考えないのです。

実案件において優秀なマーケターがタッグを組んでくれるとは限りません。なので、現代のIAにとって必要な知識として、調査・分析にもスポットを当てたかったという思いがあります。

今回はIA的な思考とは何か。クライアントが求めているものは何なのか。分析は積極的にやろう。の3本でお届けしました。情報アーキテクチャは突き詰めていくともっと理論的であり、もっと複雑で高度なスキルです。
ですが、このブログにおいては自分が理解をする為にも、出来る限り分かりやすい表現でまとめたいと考えています。

思ってる事を文章にする事で私自身の中にも考え方がしっかり定着するような気がしてますので、よろしければまたお読み頂ければと思います。

では、また。